On Dec 24, 2003, at 2:03 AM, Richard Gaskin wrote:


Thomas J McGrath III wrote:

I may have found a possible issue.

Maybe the "72" is too short or because it has no alpha letters or is
only a number is why it corrupted????

Is Rev reporting it as corrupted when you try to open it? If not, what specific behavior is happening?
No, but application browser stops working (I used 4wstackbrowser (thank you) to find out 72 & 72i were even created) and REV will not quit. The stack itself will not quit. The stack will not open any of it's own substacks. Some next and previous buttons stop working. I have to force quit at least 2 times before it even quits. And if I restart/reinstall REV and open that stack it is still there including the app browser problems.

I assume it is corrupted but I don't know for sure.

I just used my back up and ran the same button script but this time I did not name the fifteenth clone "72" instead I named it "72i" and it did not corrupt. Also I was able to continue on and get the other 30 substacks cloned. SO I would assume the naming might have something to do with it, maybe. Also, this time I closed the application browser before all of this cloning. So that may contribute to this.

I wasn't able to reproduce corruption, but I did learn something about
syntax. As with other objects, apparently stacks can be referred to by
number. So when you refer to a stack 72 without telling it of which
mainstack, it seems to look for the 72nd substack among open stack files.


Try this test:
Make a fresh stack with one button and one scrolling field, and put this in
the button script:


on mouseUp
  put empty into fld 1
  repeat with i = 1 to 100
    if there is not a stack i then
      put i &cr after fld 1
    else put i & tab& the long name of stack i &cr after fld 1
  end repeat
end mouseUp

I got very different different results testing this in MC and in Rev. In
Rev it lists only the 14 substacks of license.rev, but in MC after listing
the four stacks in mchome.mc it then went on to list the fifth through last
(64th) stack in mctools.mc.


I'd be interested in learning what rules govern which stacks are included
when referring to them by number without specifying a mainstack, but at
least we have a consistent rule to follow to avoid this: using purely
numeric names risks being confused with ordinal references on all objects,
including stacks.
This is what I think is happening, but again I'm not sure.

Unless you experienced true corruption, I would imagine you might be able to
restore expected behavior to your stack with a script that walks through and
resets the name of each substack to something not purely numeric. In my
tests here I was able to do it with this:


on mouseup
   put "MyMainStackName" into tMainStack  --< your main stack name
   get the substacks of stack tMainStack
   repeat with i = 1 to the number of lines of it
      if the short name of stack i of stack tMainStack is a number then
         set the name of stack i of stack tMainStack to (i&"xxxx")
      end if
   end repeat
end mouseup

I was not able to script a delete stack "72" even after opening in a reinstalled version of REV. But I was trying it with this stack open and from the message window. I will try your fix on it and see.


As for the Quit item not responding, it seems a bug in the IDE. I have yet
to pin down a recipe, but I have had circumstances where Quit doesn't
respond, and checking the pendingMessages reveals that the Rev script editor
has a timer message queued. I can't imagine why the script editor would
require a timer, and even odder that I didn't have the script editor open at
the time. I tried cancelling the message, but to no avail: after doing so
I still couldn't quit so I re-checked the pendingMessages and found the same
message had been sent back into the queue with a new ID.


Bad news: I had to force quit.
Good news: It seemed to have no persistent affect on the Rev IDE or my own
stack file. After restarting the app and running my repair script above, it
all went swimmingly. I hope it works out the same for you.

One thing I see is that REV does not seem to be fouled up using my backup project and in fact since I reinstalled REV I notice it works better. (command S actually pops up the saving window click to continue ( before only selecting save in the menu would pop up the click to continue window and not command S) and other little things seem to work like they did when I first installed REV)


Richard, again thank you for responding and for your patience.

Tom

--
 Richard Gaskin
 Fourth World Media Corporation
 ___________________________________________________________
 [EMAIL PROTECTED]       http://www.FourthWorld.com
 Tel: 323-225-3717                       AIM: FourthWorldInc

_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution



Macintosh PowerBook G-4 OSX 10.3.1, OS 9.2.2, 1.25 GHz, 512MB RAM, Rev 2.1.2



Advanced Media Group Thomas J McGrath III • 2003 • [EMAIL PROTECTED] 220 Drake Road, Bethel Park, PA 15102



_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Reply via email to