debugger anomaly updated

Jon jbondy at sover.net
Wed Jul 13 17:49:35 EDT 2005


Sounds like a great suggsetion, Alex! If the output were in text form 
(or XML?), you could even edit it if there were problems (like non 
printable characters in names, etc).  A simple (ha!) import/export stack 
for stacks!

:)

Jon


Alex Tweedly wrote:

> Timothy Miller wrote:
>
>> The debugger anomaly in my stacks has been discussed on the list over 
>> the past few days. In brief, the debugger will debug a stack script, 
>> but not a background script. In a bg script, the script window does 
>> open, but the script window remains behind the others and the script 
>> does not pause.
>>
>> I can force a pause and bring the script window to the front by 
>> deliberately placing an error in the bg script. When the script 
>> pauses and the error window opens, I click on the "debug" button on 
>> the error window. When the script window opens, the debug buttons in 
>> the script window are absent, and the debug menu items are dimmed 
>> out. As far as I can tell, the script won't resume. All I can to is 
>> remove the bad line and save.
>>
>> When scripts are moved from the bg script to the stack script, the 
>> debugger works normally.
>>
>> Further testing reveals -- tentatively -- that this anomaly only 
>> appears in my stacks whose original ancestors were created in an 
>> early version of hyperCard, possibly 1.0. Unfortunately, I have about 
>> five of them, fairly large, complex, and very important.
>>
>> My stacks that were originally created in recent versions of 
>> hyperCard, or Rev, do not have this anomaly.
>>
> Would it be at all possible to write a stack that would "export" 
> another stack to some textual format, and then another which would 
> "import" it again (i.e. into a new clean stack)?
>
> I know the general problem is hard - but I also know that my own 
> stacks tend to follow certain patterns (combination of me getting in a 
> rut, and the fact that I only know about 10% of what Rev can do), so 
> it *might* be feasible to write such a tool that would work for my 
> stacks.
>
> You probably wouldn't want to write a *product* to do that - but you 
> might be able to write *tool* to do it.
>



More information about the use-livecode mailing list