Drill-down debug capabilities for class overrides

[_carl]

If I have a standard VI that's hung, I can highlight execution, and then drill into the hung VI (reentrant or not) to see what's going on:

But...if it's a class override method, I can't do this:

(There is technically an exception: If the override is not reentrant, and you guess the correct override in the popup, then you can debug it.)

This experience would be so much better if I could drill into the overrides seamlessly, without being prompted for which override to look at, and with the correct runtime instance of the override popping up.  This is the kind of thing where, on complex projects, this improved debugging could literally save me hours on some bugs.

[crossrulz]

Just to flesh this out some...

Would the solution to be to open the override of the actual class being used?  Then if that class does not override go up the hierarchy until it runs into a class that does call the override?

What about if the override has the Call Parent running?

I will state that I do like the spirit of this idea.  Kudo given.  It just needs a little more fleshing out.

My opinion:  I would say that LabVIEW should open up the override based on the actual class being used and work its way up until an override is found.  If the Call Parent is running, it can show that it is running and you can dive into that if necessary.

[_carl]

I would actually expect this to be pretty simple -- it would just open up the instance VI of the override that's being directly called by the runtime instance VI that you're currently looking at.

(Yes, that would be essentially be dictated by the rules you've stated: if class has an override, it would be that, if it doesn't it would be the nearest parent override...and then when you're in that VI, if it has a "call parent", you could then drill into that, etc... -- but all of that is really just defined by the actual LabVIEW runtime stack, and I don't think there's anything special that would need to be fleshed out there.)

One thing that might need to be fleshed out: is there still a benefit to continuing to supporting the current approach at runtime (allow implementation selection), and if so, how would a user select which behavior they preferred?

[crossrulz]

It sounds like we are on the same page.  I just wanted to make it clear the intension.

As far as your next point, for runtime debugging, I cannot think of a good reason to keep the current behavior.  The choose override window makes perfect sense and it is great for that case.

[fefepeto_kb]

@_calr and crossrulz

The reason to keep the behavior is if you want to place a breakpoint in the other override method, because you realize that you might want to debug that as well.

I know it can be opened from the project, but if I recall correctly, you cannot use the Ctrl+Shift+E in running mode, which is annoying and makes finding the VI in the project tree time consuming vs the open override dialog. (It might be a separate idea if that doesn't exist yet.)

Since this is the less frequent case, we might resolve this with the keyboard shortcut, like having Ctrl+Shift+Double Click to open the dialog, double click to open the actual instance of the VI.

(the reason for not using Ctrl+Double Click is that the Ctrl+Click is the shortcut for the Breakpoint toggle action.)