On Jan 22, 2008 11:15 PM, Andrei Sobolev <
andrei.sobolev@xxxxxxxxx> wrote:
Hi Jae,
> hello all -
>
> quick question, i was wondering why the toggle class/global variable
> actions were implemented by changing the preference value (which
> causes the engine to re-update the stack frame using the new settings)
> instead of just filtering the results out of the view.
Because it could be very slow to get all variables.
yeah, i thought about that after the fact - i guess either way it's a trade off.
> i'm working on adding the support for language/project specific
> debugging engine options and it seems the implementation would be
> simpler (and allow more of it to exist in the core dltk) if the
> results could be filtered instead of flipping the preference value. it
> would also be a lot simpler if the engine settings only applied to the
> next launch, instead of one that was potentially already in progress.
> since the 'break on first line' and 'enable logging' only apply to
> launch, i would think that would apply to the other options as well.
> it would also save multiple round trips to the engine if the user
> wanted to flip things on and off.
>
> thoughts?
Yes, you are right, some options are used only in launch.
I suppose we could move some them from generic dltk settings to launch
configurations ("break on first line" for example).
i think leaving those options as part of the preferences is fine, although if you think that would be a better place for it (enabling of logging might be good there too), i'll relocate them there.
as for toggling filtering the variables, how can i get a reference to the ScriptDebugElement for the item that is currently being debugged from within the IViewDelegateAction? or some other object that will allow me to determine the IProject that is currently associated with the current item being debugged.
