Resizing grouped text boxes causes preview window error

I was trying to resize three grouped text boxes, and the preview window began behaving oddly.  It first caused all objects to disappear from the preview, leaving behind only the slide master (with the beige gradient).  With a second attempt, the preview displayed the huge red X as seen in the attached screenshot.  (The grey blocks in the image are to obscure confidential information.)  Of the three text boxes, two used built-in animations and one used a custom motion path.

Undoing all the way back to the initial grouping of the objects does not restore the preview.  Neither does switching between slides or scenes (although I note the preview window resizes in response to the presence/absence of the right scrollbar).  Slide/scene/project previews work, but the preview window is still an X upon closing the preview.  Timeline previews display the slide atop the X, and the X is left when the preview has ended.  The recent preview issue involving Adobe Flash was completely resolved with the release of the ActiveX version 20.0.0.270, so I'm inclined to believe this is unrelated.

I've saved to a new filename, but I'm hesitant to restart the program or reboot without more information for fear of losing considerable changes made in this one scene.  Is this a known issue?

6 Replies
C. L. Norman

Neither does switching between slides or scenes (although I note the preview window resizes in response to the presence/absence of the right scrollbar).

Here's another interesting observation: with this error occurring, the scroll bars actually become the correct size when zooming to 400%.  (Normally, a switch to 400% zoom causes them to become the full width of their drag areas, and they only redraw correctly when you click on one of them or the preview window.)  I don't know if that's useful for troubleshooting, but it is curious.

Ashley Terwilliger-Pollard

Hi CL,

Thanks for reaching out here and providing so much detail. The red X that you're seeing typically indicates an element of corruption within the file. File corruption is unpredictable, and there's no straightforward way to determine what causes it. Common causes are environmental (disk errors, power outages, improper shutdowns), viruses, failed Windows updates, and even file size (i.e., very large files have a higher risk of corrupting).

Consider these preventative measures to protect your project files:
 
1) Save and publish projects on your local hard drive. Working on a network drive or external USB drive can cause erratic behavior due to latency.
 
2) Save incrementally. If your app has an AutoRecovery feature, take advantage of it. If not, save a new version of your project every hour or so with a new file name each time. If a file becomes corrupt, you'll still have a working version available.
 
3) Install Dropbox. Snapshots of changes in your local Dropbox folder are kept for 30 days. If a file is damaged or deleted, you can restore a previous snapshot: https://www.dropbox.com/help/11/en.
 
4) Don't leave the app open and unattended for long periods of time. Some users have reported file corruption after leaving their apps open overnight. It's possible that a malware scan or disk backup could run because the machine is idle, making your app vulnerable to crashing. 
 
I'm not sure I"m entirely clear on the scroll bar and the zoom element though, so if you'd like us to take a look at the file we'd be happy to. Since you mentioned confidential information you may want to send it along to our Support engineers directly, and please reference this thread so that they're aware of the steps you've already worked through and where the status stands. 
C. L. Norman

Hi, Ashley!  I think I can rule out a number of factors here.  The file size is 235 MB, and while there appears to be no established maximum .story size is, your post about maximum file size would seem to imply that the size is well within a "workable" range with consideration to my system specs.  We have a rather good IT department (and my history includes IT work), so I find environmental causes fairly unlikely.

I do work on files locally, backing them up manually to an external drive at the end of each work day.  Each day I rename the local file with a new "version number", so that I'm working on a new file each day and leaving behind backups as I go.  Saves are probably not as frequent as they should be, given the exaggerated time we experience for some saves, but this one was only fifteen minutes or so before the issue arose.  AutoRecovery is on and set to 10 minutes, and I've recovered the .tmp file.  I'll be looking into the AutoRecovery option shortly, but I fear any corruption would be present there as well.  (An option to utilize multiple AutoRecovery files, in a "first-in, first-out" method, would be a nice thought for future Storyline updates/versions.)  I do have a Dropbox account, but it's mostly used for making large files available to remote staff.

I shut down my computer at the end of the day via the menu, and cold boot in the morning.  When there is a rare need to leave my computer on overnight (such as when our IT folks need to tinker), I make sure all applications are closed and file backups completed before logging off.  I could see this affecting an open instance of SL2, but not a closed file or one of the backups.

I'll see if I can't get a screen recording reproducing the issue for you to examine.  And I'll also send information about the scroll bar issue to the Support engineers for them to look at. 

Ashley Terwilliger-Pollard

Thanks CL - if only everyone could be this detailed! ;-) 

With corruption issues like that, we've found the causes above to be the most commonly identified causes - so I start there to double check, before running you through too many other unnecessary steps. If you've got the file and were able to recover it, our Support engineers are also happy to take a look at that and see if there is anything else they could spot - it may be something added into the file that caused the corruption? If you want to send along to them here and anything you've found out in terms of recreating the issue, please also share the link to this forum thread and let them know the steps we've already discussed checking (or else they'll likely start there too - easiest typically being the solution and all) and then let me know the case number and I can follow along as well. 

C. L. Norman

A followup to this—I checked the original file, the new file I saved to immediately following the odd behavior, and the recovered .tmp file, and all seem to be working just fine.  No sign of corruption.

But in checking these files, I have been able to come up with steps to reproduce the behavior reliably:

• Select two or more existing text boxes.  (In my situation, three text boxes using Entrance Animations with default Entry options: one with Fade, one with Swivel, and one with Bounce.)

• Click the Drawing Tools Format menu.

• Select Arrange > Group > Group.

• Under Size, click the arrow buttons to adjust the pixel Width.  The first click produces a pixel width of 0 with all objects disappearing from the preview (leaving only the master slide visible), and any further clicks produce the red X as noted.  This condition remains until the file and application are closed and reopened.

As far as I can tell from my files, the issue does not corrupt the file being worked on.  Of possible note is that the height of the text boxes is not the same, confirmed by the Size > Height field going blank when they are grouped.  Also of possible note is that all slide items except for the three text boxes were hidden (for easier access to redraw handles).  I'll submit a screen recording of it to the Support engineers, if you'd like.