Dick,
I threw together a quick Var Watcher last night that puts the calling
path into a pop up menu above the vars, much like Rev's Var Watcher
does. Each item in the menu looks like this:
stack "save test"/button "Button"/handler "mouseUp"/line: 7
The label of the pop up menu is the current execution context.
Clicking the menu displays the calling path in order from last to
first in the format you see above. The format is easy to change if
you think it would look better some other way. I also thought of
making more like the transcript syntax:
line "7" of handler "mouseUp" of button "button" of stack "save
test"
Not sure which approach more clearly delineates that item as part of
the calling path.
Funtionality: I made the menu switch execution contexts upon picking
another menu item. In terms of the list of vars, upon clicking they
are editable.
What puzzles me is the fact that every one wanted the calling path
when, as far as I can tell, it's already in the Rev Var Watcher. They
call it the "execution contexts." Please tell me if I'm missing
something.
Conclusion: I'm not sure that the watcher I built would offer much
new, other than the fact that it would reside in the upper two panes
of Constellation where the props and previews sit ordinarily. I could
make the array elements editable, I suppose.
Best,
Jerry Daniels
5 Reasons 12 Top Rev Developers Use to Constellation!
http://daniels-mara.com/products/5reasons.htm
On Dec 21, 2005, at 12:52 PM, Dick Kriesel wrote:
On 12/21/05 9:30 AM, "Jerry Daniels" <[EMAIL PROTECTED]> wrote:
Assuming you could have a calling path in your debug environs, what
would it look like?
IMHO, since objects of the same type can have the same name, and
objects in
different stacks can have the same abbreviated id, we need the
calling path
to identify long ids. We need to toggle the display of the calling
path to
show objects' names and/or ids. We need to see handler names.
Since within
a script functions and commands can have the same name, and
getProps and
setProps can have the same name, we need a handler type, or a line
number.
Since one handler can invoke another from multiple lines, we need a
line
number. Since a line can have multiple statements delimited by
semicolons,
and since a statement can invoke a handler more than once, we need a
character offset within the line.
Since execution can depend on the target, not just on the calling
path, we
need to know the target (during debugging, typing "put the target"
into the
message box does not respect the executionContexts).
So it seems to me the minimum entry for each call is the long id of
me, the
character offset in the script of me, and the long id of the target. A
handler which displays the path to the scripter can determine
object names,
handler names, and handler types.
-- Dick
_______________________________________________
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
_______________________________________________
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
