Debugging and the execution path

[Jerry Daniels]

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" <jerry at daniels-mara.com> 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
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>