Corruption of stack using clone

[Richard Gaskin]

Thomas J McGrath III wrote:

> I may have found a possible issue.
> 
> I seem to have corrupted a whole new stack using SCRIPTED cloning. I
> put a button and a filed on a card of my main stack here is the code:
> 
> on mouseUp
> clone stack "61i" -- existing substack
> put it into mynewone
> set the mainStack of stack mynewone to "UnityCD" -- mainstack
> put field "newname" into mynewname -- field where new name can be
> entered by me
> set the label of stack mynewone to mynewname
> set the name of stack mynewone to mynewname
> end mouseUp
> 
> The "61i" is a sort of code for section 6 item 1 sub item i. So I have
> "31i" and "31ii" and "42iv" etc. The problem happened again when I got
> to "72" Notice there is no "i". the system is now hung and will not
> quit and will not act correctly. The application browser will not show
> the substack "72" and I tried after this a "72i" and it was created but
> will not show up in application browser.
> 
> 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?
 
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.

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



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.

-- 
 Richard Gaskin 
 Fourth World Media Corporation
 ___________________________________________________________
 Ambassador at FourthWorld.com       http://www.FourthWorld.com
 Tel: 323-225-3717                       AIM: FourthWorldInc