Corruption of stack using clone

[Thomas J McGrath III]

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
>  ___________________________________________________________
>  Ambassador at FourthWorld.com       http://www.FourthWorld.com
>  Tel: 323-225-3717                       AIM: FourthWorldInc
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> 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 •	3mcgrath at adelphia.net
220 Drake Road, Bethel Park, PA 15102