count on it not disappearing or
changing enough to cause damage.
By removing the offending paragraph in the executionContexts
dictionary entry, RunRev would effectively be making a commitment to
including descriptions of any changes to the value in the engine
revision report for new versions
, so changing it is
likely to break everything. I rather count on it not disappearing or
changing enough to cause damage.
By removing the offending paragraph in the executionContexts
dictionary entry, RunRev would effectively be making a commitment to
including descriptions of any changes
On Sep 24, 2010, at 5:14 PM, Mark Wieder wrote:
...
By removing the offending paragraph in the executionContexts
dictionary entry, RunRev would effectively be making a commitment to
including descriptions of any changes to the value in the engine
revision report for new versions. Or at least
like to know. Or am I missing something?
Can you handle the traceError message instead (put this into a
frontscript)?
on traceError pHandlerName, pLineNumber, pCharOffset, pErrorInfo, pObjectID,
pErrorType
answer got traceError
put executionContexts= the executionContexts cr after msg
Someone please educate me...
My current understanding of the debugContext is this: it provides access
to any context listed in the executionContexts and to no other contexts.
To access a context other than the current one, you set the debugContext
to the number of the line
I should have said - I'm assuming the standalone environment in all this.
Phil
Phil Davis wrote:
Someone please educate me...
My current understanding of the debugContext is this: it provides
access to any context listed in the executionContexts and to no other
contexts. To access
Phil-
I'm out of town at the moment without access to my notes or code, but
I believe you're correct about this. To my recollection the traceError
and errorDialog messages are mutually exclusive (one happening when
debug mode is on and the other when it's off) and the errorDialog
message doesn't
Thanks Mark.
Mark Wieder wrote:
Phil-
I'm out of town at the moment without access to my notes or code, but
I believe you're correct about this. To my recollection the traceError
and errorDialog messages are mutually exclusive (one happening when
debug mode is on and the other when it's off)
I do not really understand Dar Scott's
As a product Revolution does NOT have
executionContexts except maybe as a reserved word of
some sort. This is not an underdocumented feature of
the product. I did not buy executioncontexts.
I bought 2 varieties of Runtime Revolution and the
both contain
The point here is surely a practical one.
RR have built executionContexts into the language for their own
purposes, having written the IDE in transcript/revolution (eating
their own haggis, as they put it), and presumably they needed it for
some aspect of writing an IDE.
Assuming
Richmond,
by poking around the IDE source you'll find lots of little gems,
specially functions and code that can teach you how to do many things
but having access to the inner bowels of the RunRev IDE does not
means that this is something you can rely on. The executionContexts
is one
Mark Weider . . .
Just tried to find executionContexts in the
documentation for DC 2.6.1 and RRMedia 2.7.2 and found
nothing.
then made a quick stack to see executionContexts in
action, and there they were
Ho Hum
I wonder why there seems to be some resistance to
documenting these things
On Oct 14, 2006, at 12:46 PM, Richmond Mathewson wrote:
Just tried to find executionContexts in the
documentation for DC 2.6.1 and RRMedia 2.7.2 and found
nothing.
...
I wonder why there seems to be some resistance to
documenting these things?
I try to refrain from insisting somebody
On 12/17/05 9:50 AM, Ken Ray [EMAIL PROTECTED] wrote:
On 12/17/05 3:14 AM, Dick Kriesel [EMAIL PROTECTED] wrote:
Your answer left me a hope that maybe we were just a BZ away from being able
to use the executionContexts in a standalone, so I decided to search BZ
before asking about
On 12/19/05 4:00 PM, Dick Kriesel [EMAIL PROTECTED] wrote:
Thanks for asking, Ken. My answer is neither: I'm concerned because of the
following message from Scott Raney, which leads me to think there may be
some disqualifying problem in the design or implementation of the
executionContexts
Your answer left me a hope that maybe we were just a BZ away from being able
to use the executionContexts in a standalone, so I decided to search BZ
before asking about that possibility. The result was a surprise, so here's
another question:
Would you please comment on the resolutions of BZ 724
On 12/17/05 3:14 AM, Dick Kriesel [EMAIL PROTECTED] wrote:
Your answer left me a hope that maybe we were just a BZ away from being able
to use the executionContexts in a standalone, so I decided to search BZ
before asking about that possibility.
Dick, are you saying that you can't use
Dick Kriesel wrote:
Your answer left me a hope that maybe we were just a BZ away from being able
to use the executionContexts in a standalone, so I decided to search BZ
before asking about that possibility. The result was a surprise, so here's
another question:
Would you please comment
18 matches
Mail list logo
