Debugging is often a process of elimination. My suggesion for testing:
First, make a duplicate of your entire set of files for a test. Then in this test set of files.
- Delete all the MOVs from the Director movies. Then run the application through the set of step that causes the problems.
Q. Does the application still freeze?
If no, then you know that the MOVs are creating some issue.
If yes, you can eliminate the videos as the problem.Then you'd need to see what else is happening around the time the application freezes.
Dean, thanks for the idea, but the problem remains. I invite you (and anyone else) to try and see if you can find the problem by looking at the files themselves. The link to the project is https://www.dropbox.com/s/qy2m1f69s1ju4mp/DirectorProjectBug.zip. I have thinned it out so that only the related casts and MOVs are listed. I really, really appreciate the help!!
I realize that I should give a bit more information to anyone who wants to take on the challenge. Again, I have posted a link to the files at https://www.dropbox.com/s/qy2m1f69s1ju4mp/DirectorProjectBug.zip. To experience the problem, just open up menu.dir and first click anywhere on the splash screen, then follow the instructions on the next screen to choose a "category", "Technique", "Skill". (I have thinned out the casts to only have 1 of each be available) The program will then have you choose a numbered "challenge" after which you will click on a "play" button to see video #1. Then, click on the "Return to Error Choices" button. Click on any of the three answer choices, then hit the button "View Consequence Video" and watch video #2. This is where the problem begins. If, after watching video #2 (or any part of it), you click any button except a numbered challenge button, the program works fine. If , however, you next click on the button for a different numbered challenge, the program will work in so far as it will let you see video#1 for the next challenge, but as soon as you click on the "Return to error choices" button, the program freezes (the video#1 for the next challenge remains on the screen and blocks the text that should show up at that frame). The problem only occurs on MACS, not on PCs, and it is consistent across MAC leopard and lion, and across any combination of challenges. Can anyone solve the mystery? Thank you!
I downloaded your files but am having problems follwoing your instrauctions to get to the crash. Is the 'View Consequence Video' button you refer to just the play button? If you can give steps of what buttons to clieck that always result in a freeze, that will be helpful. Leave out, if you do this it will work if you do this and then this.... That part just makes teh instructions harder to follow.
Looking at your code, I see you are using an older Lingo syntax. Someof that simplified like:
Your verbose sytax:
set the movieRate of sprite 44 to 0
You can drop 'set' and use = for 'to'.
sprite(44).movieRate = 0
I see you change the visibility of your video sprite. I tend to move a sprite off stage rather than changing teh sprite visibility. So, you could have something like:
sprite(44).locH = sprite(44).locH + 800
Don't think the above would be the cause of the crash though.
Thanks for the ideas, Dean. You are right, my first explanation was not clear. You have to get somewhat into the program to find the crash:
1. Open up menu.dir and first click anywhere on the splash screen, then choose a "Category", "Technique", "Skill".
2. Choose a numbered "challenge"
3. Click on the play button and watch all or part of the video
4. Click on "Return to error choices"
5. Choose any of the 3 choices on the next screen
6. Click on "Check answer"
7. Click on "View Consequence video" and watch all or part of it.
8. Click on a different numbered challenge in the keypad on the upper left side of the stage
9. Click on the play button again and watch all or part of the next video.
10. Click on "Return to error choices". At this point, the video should disappear from the screen and you should see 3 choices on the screen. But, instead, the last video freezes and remains on the screen.
As a note, if after viewing the consequence video, you then click any button other than a new numbered challenge, there is no problem.
Not on a Mac today so can’t test the steps and see the problem directly. However, will offer some suggestions.
It sounds like the video is just staying on screen rather than actually crashing your application. Can you test this by the change I mentioned before. Instead of making the video sprite invisible, can you move it off stage as I suggested as follows
set the movieRate of sprite 44 to 0
sprite(44).locH = sprite(44).locH + 8000
or verbose syntax if you prefer
the locH of sprite 44 = (the locH of sprite 44) + 800
Next, Sean’s suggestion is a good one. Where idd you add the statement he suggested? I would suggest you add the following to your frame behaviors in the frame following on from a video
the stageColor = the stageColor
Other things to improve your code. A behavior like:
go to the frame
if the movieRate of sprite 44 = 0 then
set the memberNum of sprite 46 to the number of member "play_up"
set the memberNum of sprite 46 to the number of member "pause_up"
could be improved in a number of ways.
1. If you are including code that is making adjustments to sprites, have that before the ‘go to the frame’ line.
2. memberNum is dated Lingo instead just use ‘member’:
sprite(46).member = member(“play_up”)
the member of sprite 46 = member("play_up")
3. I’m not sure why the change of members is in the frame behaviour. It could be linked to any button that takes you out of the video sequence. So, you may have a behaviour as follows:
-- pause video and change buttons
sprit(44).movieRate = 0
sprite(46).member = member(“play_up”)
You could have a separate behaviour that starts the video. It could be attached to the video sprite and could be:
-- play video at start
sprit(44).movieRate = 1
sprite(46).member = member(“pause_up”)
I suggest you try separate different elements of behaviors. For the ‘Return to Error Choices’ script, you have code to switch cast members (highlight the sprite on rollover) as well as the mouseup instructions. I’d suggest you use the ‘Rollover Member Change’ behaviour in the Behavior Library – Animation > Interactive category. That will mean the same behavior can used for all sprites without having to hard code individual buttons. Will be much more efficient. I’d also suggest you add the ‘Rollover Cursor Change’ behaviour, also in Behavior Library – Animation > Interactive category. Remember, you can have multiple behaviors attached to a single sprite. So, having individual behaviors for different types of things, it makes your code management more efficient and will help in locating bugs too.
Last code suggestion – look at the use of case Lingo which be used over if then when appropriate. For example:
if numberOfTries = 0 then
go to "EC1"
else if numberOfTries = 1 then
go to "1E1"
else if numberOfTries = 2 then
go to "1E2"
else if numberOfTries = 3 then
go to "1E2"
Can be replaced with:
case numberOfTries of
0: go to "EC1"
1: go to "1E1"
2: go to "1E2"
3: go to "1E2"
In the above example, besides being more efficient to write, it’s also more efficient to execute.
Has been longish reply. Hope it's been helpful.
Your suggestions are great. Thank you! I am making the lingo changes you recommended. I have found one way to solve the problem (although it introduces another). By putting sprite(44).locH = sprite(44).locH + 8000 into the script "Conseq01/", "Conseq02/", and "Conseq03/", the original problem disappears - but as one would expect, the video that should be visible when clicking on "View Consequence Video" is not visible when it should be. Does this help narrow it down?
I am still working on making the lingo changes you recommended. If they solve the original problem, I will let you know. Also, to answer your question, I put Sean's line right under mouseup on each of the scripts that can be called up after pressing "View consequence video" (CV1, CV2,CV3, EC1,EC2,EC3,CC1,CC2,CC3).
I really appreciate all of the help!!
Yes, looks like it has found the problem. Sounds like the issue was the stage was not being redrawn/refreshed when the video was 'turned off'. My suggestion was to move the video off screen instead of setting the sprite's visibility to 0. That has appeared to get the stage redrawn without the video. To get the video back to the correct location, you'd need something like:
sprite(44).locH = 400 -- where 400 is the fixed x location
So, you 'd set the locH to 400 (or whatever the position should be) to replace current code of 'set the visible of sprite 46 to 1' and set it to '+800' when you currently set the visible property to 0.
For the stagecolour thing, I think it did not work because it was in the wrong script. Having it in the mouseUp event meant it did not execute at the right time. Better to have it in the frame script where the screen needs to be redrawn which is after you have clicked and jumped to the new frame. Hope that makes sense.
Thanks, Dean. Your idea about moving the video off of the screen worked perfectly in the small version of the project that I used for the test. When I tried to apply it to the larger project, a lot of other errors started occurring (e.g., the video stopped being visible at all and the play button stopped working). I suspect that I have some conflicting scripts that were not included in the sample I posted because they were not involved in that specific problem. I will spend the next few days trying to figure out what happened and let you know. But, I have a good feeling that your idea will solve the issue. Thanks!
Sorry I haven't replied sooner. Was meaning to.
Has anything changed since your last post? I don't think the issue is because your file is too large. Debugging is often a process of elimination. In your case, if the problem is in the main file but not in the 'small' version, it would be worth removing elements until the problem disappears. It may be just one 'thing' is causing the problem, and finding that thing will help resolve the issue compeletely.