Description Neale Upstone 2009-10-08 06:31:53 EDT

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)
Build Identifier: 3.5.0

Imagine that you're stepping through some code (could be Java via JNI/JNA, or C/C++) that manipulates windows on the desktop, or manages multiple desktops (in my case it's because I'm using Win32's CreateDesktop/SwitchDesktop features to create a 'kiosk mode').


Reproducible: Always

Steps to Reproduce:

Because your IDE present on the default desktop, any interaction with the IDE:
a) requires that desktop to be the visible one
b) requires your IDE to have input focus

This causes the following problems:
1) Switching to the IDE to continue or step changes teh state of the desktop
2) If you have created another desktop and switched to it, then hit a breakpoint, you're stuffed if there is deliberately no way of switching back (i.e. kiosk mode).

The solution could have two elements the first one being 'required' the second, more complex one, a 'nice to have':
1) Create a 'breakpoint timeout' feature which is triggered when stopped at a breakpoint.  After the timeout (configurable, say 10 seconds), a dialog pops up, saying "Auto continue enabled - press cancel within 5 seconds to abort".  If this isn't aborted, then all further breakpoints get automatically auto continued.

2) Now the complex bit. Why not just disable breakpoints before the first continue above?  Well, it's because those breakpoints are areas where you'd want to know what's going on, but may not be able to interact with the IDE at those points.  The nice to have here would be to be able to review the process state at each of those breakpoints (i.e. a mini-replay function).  Naturally the scope of what is recorded at each of those points would have to be constrained.