On 21 Apr 2004, at 18:00, [EMAIL PROTECTED] wrote:
Message: 2
Date: Tue, 20 Apr 2004 21:23:40 -0500
From: J. Landman Gay [EMAIL PROTECTED]
Subject: Re: erroneous error codes
To: Discussions on Metacard [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii
Oops, small correction:
on errorDialog which
if length(which) 5 then put line -5 to -1 of which into which
### the change
set the executionerror of card 1 of stack Execution Error to which
modeless Execution Error
send refresh to card 1 of stack Execution Error
end errorDialog
HTH,
On 4/22/04 9:57 AM, Wouter wrote:
Some observations which may be of some help:
Using an error producing button the
Object: property is not an integer
Object: value is not boolean (true or false)
errormessage is produced every time one opens and closes a scripteditor
(just opening and closing,
On 4/22/04 11:08 AM, Wouter wrote:
Oops, small correction:
on errorDialog which
if length(which) 5 then put line -5 to -1 of which into which
### the change
set the executionerror of card 1 of stack Execution Error to which
modeless Execution Error
send refresh to card 1 of stack
I wrote:
I'll try it too, though I don't think it changes the guts of the
execution error stack's card script. That script takes the same
parameters and chops off all but the last 100 lines
I misspoke here. The MC script chops off all lines after the first 100.
If the real error codes are at
snip
The main change here is to use line -4 to -1 of the error codes if the
first line has a target object that is 0. See if this works and let me
know. As I said, I don't think this is a perfect fix, but it seems to
be
on the right track.
Why the 4 last lines? If metacard is reporting the
Wouter wrote:
To put the change in the refresh handler is better though. But I was and
still am testing when the errordialog of the execution error stack
itself is called. Up to now it is never.
I believe that handler is only called when the stack is included in a
standalone and you have the
erroneous error codes
Richard Gaskin ambassador at fourthworld.com
Thu Apr 22 16:19:57 EDT 2004
snip
Should we consider replacing the execution error dialog?
The current version is not especially helpful in development, and is
arguably too ugly to use in standalones.
It should be possible to
Wouter wrote:
Should we consider replacing the execution error dialog?
The current version is not especially helpful in development, and is
arguably too ugly to use in standalones.
It should be possible to create an error dialog that is useful for both
us developers and our users, and is more
On 4/22/04 5:11 PM, Wouter wrote:
snip
The main change here is to use line -4 to -1 of the error codes if the
first line has a target object that is 0. See if this works and let me
know. As I said, I don't think this is a perfect fix, but it seems to be
on the right track.
Why the 4 last lines?
On Mon, 19 Apr 2004, Richard Gaskin [EMAIL PROTECTED] wrote:
(snip)
Verified. This may be the result of changes to the Rev error dialog to
accomodate changes in the engine. I have requested a summary of engine
error-handling changes from Tuv; it's not yet arrived, but he may just
be busy.
I tried debugging the erroroneous error codes tonight. It's hard because
you can't use the debugger to do it -- everything goes wonky if you try.
Instead, I inserted bits of script that put variable values in the
message box.
I don't see anything wrong with any of the scripts. It looks to me
J. Landman Gay wrote:
I tried debugging the erroroneous error codes tonight. It's hard because
you can't use the debugger to do it -- everything goes wonky if you try.
Instead, I inserted bits of script that put variable values in the
message box.
I don't see anything wrong with any of the
Yesterday I had written:
Errordialog is indeed defined in the engine (make a textsearch of the
engine with a word processor), which means that contrary to what
Jacqueline quoted from Tuviah (see above) there must have been changes
with respect to error codes in the engine.
After a second
Wilhelm Sanke wrote:
Yesterday I had written:
Errordialog is indeed defined in the engine (make a textsearch of the
engine with a word processor), which means that contrary to what
Jacqueline quoted from Tuviah (see above) there must have been changes
with respect to error codes in the engine.
On Thu, 15 Apr 2004 J. Landman Gay [EMAIL PROTECTED] wrote:
(snip)
Using the older engine does not produce this issue, but Tuv tells
me the
error codes have not changed. Obviously something has, so if any
of you
have some insight it'll help save some time in getting this addressed.
I get
J. Landman Gay wrote:
On 4/15/04 10:31 AM, Richard Gaskin wrote:
When using MC 2.6 (Rev 2.3 engine) all errors are first reported as
Not an integer, and only when I dismiss the error dialog and repeat
the action that caused error do I get the proper error string.
1. Are you folks seeing the
Hi Richard,
When using MC 2.6 (Rev 2.3 engine) all errors are first reported as
Not an integer,
and only when I dismiss the error dialog and repeat the action that
caused error do I get the proper error string.
1. Are you folks seeing the same thing?
Yes, this seems to be the only error i see
On 4/15/04 10:31 AM, Richard Gaskin wrote:
When using MC 2.6 (Rev 2.3 engine) all errors are first reported as Not
an integer, and only when I dismiss the error dialog and repeat the
action that caused error do I get the proper error string.
1. Are you folks seeing the same thing?
2. Have any
Could it be that the error is actually rooted in the error dialog,
which is reading some sort of property or global too soon, and then
*cough* it gets the fresh one the second time?
On 4/15/04 10:31 AM, Richard Gaskin wrote:
When using MC 2.6 (Rev 2.3 engine) all errors are first reported as
20 matches
Mail list logo
