On 6 Apr 2006, at 23:53, J. Landman Gay wrote:
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.
I just tried it and this isn't how it works on my system. I open a
script, click in a few places but don't enter any data. The apply
button is disabled and if I hit the close button in the window title
bar is close ok.
When the spurious "Do you want to save?" dialog log appears, I've
noticed that when I only the Script in question the Apply button is
enabled straight away. At first I thought it was something to do with
having text selected when the script was saved, but I just tried that
and it worked. But, today, it must have happened at least 10 times.
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.)
Point noted, thanks.
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.
I had it happen about 2 hours ago, I have no idea why it happened,
but once it loses it mind like this, the only way out is to quit and
start again. I can't reproduce it at will, when it does happen it's
hard to know what to report. Today I'd being doing the same thing
over and over in a "test" stack, trying something out. I was writing
a little code and then testing it using buttons to execute pieces of
the code and then looking at the variable window. It was easy to tell
what had happened this time and get out of it by copying both scripts
into a text window, quitting RunRev and then pasting back the real
script, if it happens when there are a lot of scripts open it's not
so easy to tell what has happened and then you can lose code.
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.
Yes, that's when I've seen it too mostly, but today it happened with
a small 3 control script and no libraries. I put a breakpoint in the
mouseUp handler of a button and it just wouldn't breakpoint. One
thing I have noticed is that if you insert an "answer" command just
before the breakpoint command and OK the dialog, it breakpoint's ok.
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.
If I reported every glitch, I'd spend all day in BZ and no time
actually do some work. That said, I am guilty as charged, I haven't
entered any of the above bugs in the database, since they are *so*
obvious that I really can't see the point. If they need the database
to notice that the colorization doesn't work 100% then we are all in
serious trouble!
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.
Then they must be really patient people is all I can say. If I had to
live with just of those minor bugs but had the source code so I could
fix it, then I'd do in my spare time if necessary. It's like living
with a squeeky door for 2 years and not bothering to get out the oil
can!
All the Best
Dave
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
