Mark Schonewille wrote:
Once in a while, you may run into a less-than-obvious problem, while
programming in Revolution. In these cases, you might see an error
message of the form (the code may consist of many lines):
91,7,11,Example
568,7,1,Click Me
which means:
Type: Chunk (can't find stack)
Object name: Button
Line:(row 7 col 11)
Hint: Example
Type: start (can't find object)
Object name: Button
Line:(row 7 col 1)
Hint: Click Me
If you have no idea what causes the error, it may be useful to be able
to parse the error.
Unfortunately, the engine lies.
Or more politely, it uses a mysterious logic. ;)
The error info passed with the errorDialog message might appear to be a
straightforward set of four-item lines, with two exceptions:
1. Usually the first two lines have only three items.
2. Every third line after those is junk (or is using some mysterious
logic that eludes me).
The example below was generated by a test stack I built a couple days
ago while updating my own custom Execution Error dialog. In that test
stack I have a button with a mouseUp handler that calls "DoSomething",
which is defined in the card script and in turn calls "doSomethingElse",
which is defined in the stack script which calls "DoX", which is also in
the stack script and is simply:
on DoX
get 1+x
end DoX
Since "x" isn't defined it generates an error, and having all those
handlers calling one another gives me error data that looks like this
(the line numbers at the front of each line aren't part of the error
info, added by me here for clarity):
1 395,8,7
2 223,8,1
3 241,8,1,DoX
4 353,0,0,stack "/Applications/MetaCard/_testers/error_test.rev"
5 573,3,1,DoX
6 241,3,1,DoSomethingElse
7 353,0,0,stack "/Applications/MetaCard/_testers/error_test.rev"
8 573,4,1,doSomethingElse
9 241,4,1,DoSomething
10 353,0,0,card id 1002 of stack
"/Applications/MetaCard/_testers/error_test.rev"
11 573,8,1,DoSomething
12 241,8,1,mouseUp
13 353,0,0,button id 1003 of card id 1002 of stack
"/Applications/MetaCard/_testers/error_test.rev"
The first two lines, while lacking an object reference, contain useful
stuff. For example, line 1 refers to error #395, which is: "Operators
+: error in right operand" -- describing the error exactly. The second
item in that line refers to the script line which failed, and the third
item is the character offset to the erroneous token. So far so good.
In line 2 we have a reference to this error message, a more general
explanation of the issue: "get: error in expression". Again,
appropriate and helpful, and the second and third items accurately refer
to the script line and character offset of the offending statement.
Line 3 gives us the name of the handler which failed, with error
description 241 being simply "Handler: error in statement".
Line 4 gives us the errorObject, the long ID of the object which
contains the failing statement. Error description #353 is simply "Object
Name:", and apparently that line is used only to convey the failing
object. Because that line is used only to convey the error object, it
doesn't contain script line and character offsets. Again, so far so good.
Then we get to line 5, which is FUBAR.
This line refers to error #573, which has this description: "Handler:
can't find handler". That's not exactly true, since all handlers called
are defined and in the message path. If we were to parse the lines of
the error info as though they were all meaningful (as I used to do
before revising my Execution Error dialog the other day), one might
think that somehow a handler is either undefined or fell out of the
message path. Since I use a lot of libraries and backscripts, this
approach turned out to be a time-wasting hunt for red herrings.
I've since revised my errorDialog handler to skip any line immediately
following the one starting with "353,", since the offsets and handler
name there are redundant anyway and the error number inaccurately
describes what's happening.
The good news is that once you skip such lines, you'll wind up with a
rather tidy and useful collection of data describing the full calling
chain that led to the error.
If anyone know why the engine generates that line immediately following
the one with the error object, and can find it useful, I'd love to learn.
The next question one might have is "Where did you get that list of
error descriptions?"
It's hard to get to in the Rev IDE, but you'll find it in a custom
property named cErrorsList of stack "revErrorReport" of mainstack
"revStandaloneSettings". (In MetaCard they're in a hidden field named
"Messages" in the "Execution Error" stack).
The property contents are simply a return-delimited list, in which each
line number corresponds to the error number which is the first item in
each line of the argument passed with the errorDialog message.
> If you would like to build this feature into your own stacks, Economy-
> x-Talk has a shareware library available that will allow you to do so.
> This library can be downloaded at
<http://economy-x-talk.com/developer.html>
Unless you have a lot of time on your hands to be mucking around with
this stuff, I would recommend using Mark's library. It'll keep you from
pulling your hair out, and save you as much time as hair.
I've had the pleasure of hiring Mark to write some code for one of the
products I manage, and I'm looking forward to using him again. He
writes solid code, well commented (but not distractingly over-commented)
and in a readable style, and his turnaround time is as excellent as his
rate. If you need a pinch-hitter on your project, or are looking for a
useful library, I can't recommend Mark's work strongly enough.
--
Richard Gaskin
Fourth World Media Corporation
___________________________________________________________
[EMAIL PROTECTED] http://www.FourthWorld.com
_______________________________________________
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
