[Ticket#: 2006040510000641] Re: [OT] Articles to read

J. Landman Gay jacque at hyperactivesw.com
Thu Apr 6 18:53:38 EDT 2006


David Burgun wrote:

> Just look at the Script Editor! There are at least 10 bugs that I  come 
> across every day, and for 2+ years???!!!!

Did you put them into bugzilla? If you didn't, the team won't always 
know there is a problem.

> 
> For instance, straight off the top of my head:
> 
> 1.  I open a script and do nothing to the script, I then close the  
> script and it gives me the "Do you want to save?" dialog.

I'm not sure this is really a bug. It is more a by-product of one of the 
features. Revolution saves not only your script, but also the location 
of the insertion point so that the next time you open the script it will 
  scroll automatically to where you were last working. This is a nice 
feature. So, if you close the script editor without clicking anywhere, 
you won't get the "save" warning. If you do click, it marks the script 
as dirty, stores the current cursor location, and asks if you want to 
save it.

Once you understand what's happening, it may not seem so terrible any more.

> 2.  The script colorization doesn't work consistently.
> 3.  Sometimes the script editor/debugger loses it's mind and when you  
> click on the error it opens the *same* script in another window. If  you 
> then edit this window and close it, then notice that the other  window 
> is still open and close that one, you lose your changes!
> 4.  The debugger sometimes just plain refuses to breakpoint, even  when 
> you insert a "breakpoint" command into the script.
> 5.  The Menu Builder tool is really flakey.

These are mostly valid and I've also seen some of them. I can't comment 
on colorization because I abhor it and always turn it off. (It also 
increases the size of your stack on disk because Rev must store a 
duplicate htmltext copy.) I've seen the double script window problem 
only a couple of times, but it needs to be reported. If you have a stack 
that reproduces the problem, I hope you will submit it so it can be 
fixed. I've never had any trouble at all with the menu builder, but if 
you can define the problem more concisely than "flakey" the team can 
look at it. It has always worked okay for me.

Number 4, refusing to break, happens only under very particular 
circumstances. I've been able to reproduce it twice, reported it twice, 
and both times it was immediately fixed. In each case, it was a problem 
with a library or a backscript -- once with libURL and another time with 
the way the IDE was parsing file paths. I think it happens when a 
library is in use in a stack that is not open -- or when a backscript 
has been inserted -- and the library has a bug. The debugger will not 
trace into that script. The engine has two choices at this point; the 
first is to go into an infinite loop (that's what the MetaCard IDE does) 
and the other choice is to simply not break at all. Rev does not break 
at all. This is infinitely superior to a loop that you can't get out of. 
When I used to hit this problem in the MetaCard IDE I had to force-quit 
without the opportunity to save my work.

Careful debugging of your own library scripts can help, if that is where 
the problem is. If the problem is with one of the backscripts or 
libraries that Rev employs, then *report it.* I just did a couple of 
searches in Bugzilla, and did not find any bug reports submitted under 
either your name or email address. You can't expect fixes to things that 
aren't in the bug database.

Note also that the team uses Rev and all its features daily to develop 
Rev's IDE, among other things. Therefore, if you are having a problem it 
is likely localized to either your setup or your work style. They need 
to know. For example, one reason my copy of the debugger would not break 
was because of a file path issue that existed only on my hard drive. No 
one else could reproduce it; I finally figured it out when I changed the 
name of a folder. Then I reported it.

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com



More information about the use-livecode mailing list