Comment on editing front scripts

MisterX b.xavier at
Sat Feb 12 02:41:08 EST 2005

we do have to look at the scope we need.

Debugging, variables, script editor, error display (and relevance to error
or compilation problems), etc... 

And there is the hierarchy of problems when a function calls one which has a
mistake as you pointed out before (an old problem!)... 

Part of this problem is the lack of threading in the engine imoho. Different
threads that dont interfere or block the others would be quite helpful! It
would require a few "trys" and catches more but it would solidify things
further. HyperCard has a separate code running to do debugging and script
editing and surely that helped a lot more than having an all in one script
environment that does the IDE operations and debugging at the same time. 

As I've said before the IDE interferes a lot, and the issue comes back again
and again in one form or the other... 

If it helps, here's some rules and logic operation schemes from XOS:

For one, I keep track of who locks and unlocks what and in what order (FIFO
If one operations blocks the other, there's either a debug breakpoint with
data report (customizable report of who did what when with what data) or
there is an overrule of a lock (uninplemented yet). 

One intersting adventure I had is this:

You know the errordisplay is GM broken each time an error occurs (where's
that revOnline update i wonder). But the RevVariableWatcher uses a
resizestack handler. I tried to improve the RVW because of it's totally
annoying resizing inneficient design and adding Rev's GM features was total
chaos in the engine! I had to restore an virgin copy of the RVW to continue!

So, separation of tasks via threading (for non-data-returning handlers)
would be cool and a solution to Rev's error-handling erratic display... 

As soon as my mom leaves, I'll start working on the GM for XOS now that the
XOS Language engine is near finished.

It's hard to develop an IDE, that's for sure! But all together it's that
much easier!


> -----Original Message-----
> From: use-revolution-bounces at 
> [mailto:use-revolution-bounces at] On Behalf Of 
> Richard Gaskin
> Sent: Saturday, February 12, 2005 07:36
> To: How to use Revolution
> Subject: Re: Comment on editing front scripts
> MisterX wrote:
>  >>>>On Feb 11, 2005, at 10:52 AM, Richard Gaskin wrote:
>  >>>>
>  >>>>> This reminds me of an annoyance:  as noted in the docs 
> somewhere,  >>>>> sometimes script errors in frontscripts or 
> backscripts are not  >>>>> reported properly as such, instead 
> pointing to the non-inserted  >>>>> script that called it.
>  >>>>>
>  >>>>> Why is that, and how hard would it be to fix?
>  >>>>
>  >>>> Ahhh...Now if we could have reliable script errors in  
> >>>> every instance, life would be much easier.
>  >>>
>  >>> It may not be much of a bullet-point, but for myself I'd 
>  >>> prefer to see an overhaul of error handling above any  
> >>> other feature currently in queue.
>  >>
>  >> I have 5 votes waiting to add to that if you'll point me  
> >> to the request.
>  >
>  > You can add your votes to bugzillas 2347, 2344, 2320, 
> 2351, 1638,  > etc...
> Those cosmetic issues would be helpful, but I was thinking 
> less about the UI than what's going on under the hood with the engine.
> I don't mind taking an evening to make my own error dialog (I 
> have to anyway to get something suitable for including with 
> my app), and if the error handling was revamped it would only 
> be a few lines anyway.
> But getting to a simple, robust, and thorough reporting 
> mechanism may be a bit of engine work.
> I've posted a message to the improve-rev list to see if we 
> can get a spec together to propose....
> --
>   Richard Gaskin
>   Fourth World Media Corporation
>   ___________________________________________________________
>   Ambassador at
> _______________________________________________
> use-revolution mailing list
> use-revolution at

More information about the Use-livecode mailing list