Skip navigation
Sandra Rosen
Currently Being Moderated

Project Freezes on Mac

Jun 7, 2012 12:04 PM

Tags: #lingo #director

Thanks to everyone who posted an answer about making files invisible. I appreciate the help. I have one more challenge. I have created a project that calls for .mov files (among other things) to run within it. Everything works great on PCs, but on MACs, there is a specific sequence of 3 buttons that end users can push that makes the program freeze, leaving the following .mov file on the screen and none of the buttons working.

The problem starts when people call up an .mov file using a certain button on the screen, and then press 2 other buttons in a specific sequence. The first of these buttons just takes the user to another activity and the second of these 2 buttons calls up a different .mov file.  Once the second .mov file is called, the program will play the video and then freeze.  It does not matter which .mov files are called up (several choices), the problem is the same. Any other sequence of buttons following viewing the original .mov file causes no problems. I cannot find the lingo error causing this, and the program runs perfectly on PCs. If you are interested in looking at a puzzling challenge, would you let me know and I will send you the .dir and related files?  I feel like I am staring at a simple solution and just can't see it.

 
Replies
  • Currently Being Moderated
    Jun 7, 2012 6:31 PM   in reply to Sandra Rosen

    It could be an issue with the MOVs. Do they play OK outside of Director? I would try switch the MOVs with otehr ones to see if the error still happens.

     

    Dean

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 8, 2012 9:52 PM   in reply to Sandra Rosen

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 10, 2012 11:37 PM   in reply to Sandra Rosen

    Sorry, haven't looked at your file as I don't have a Mac to test on, but have you tried 'the stageColor = the stageColor' trick to force a complete screen refresh on frames that might contain artifacts?

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 14, 2012 9:55 PM   in reply to Sandra Rosen

    Sandra,
    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'.

     

    dot syntax
    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.

     

    Dean

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 15, 2012 8:37 PM   in reply to Sandra Rosen

    Hi Sandra,

     

    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

     

    Replace

      set the movieRate of sprite 44 to 0

    with

      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

     

    on enterFrame

    the stageColor = the stageColor

    end

     

     

    Other things to improve your code. A behavior like:

    on exitFrame

      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"

      else

        set the memberNum of sprite 46 to the number of member "pause_up"

      end if

    end

     

     

    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”)

    or verbose

    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

    on mouseUp

      sprit(44).movieRate = 0

      sprite(46).member = member(“play_up”)

    end

     

     

    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

    on beginSprite

      sprit(44).movieRate = 1

      sprite(46).member = member(“pause_up”)

    end

     

     

    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"

        end if

     
    Can be replaced with: 

      case numberOfTries of

        0: go to "EC1"

        1: go to "1E1"

        2: go to "1E2" 

        3: go to "1E2"

      end case

     

     

    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.

    Dean

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 18, 2012 7:04 PM   in reply to Sandra Rosen

    Hi Sandra,
    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 26, 2012 4:51 PM   in reply to Sandra Rosen

    Hi Sandra,
    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.
    Dean

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 26, 2012 5:10 PM   in reply to Sandra Rosen

    Glad to hear that Sandy. I guess you can now tag this thread as 'Answered' Dean

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points