In the Visual Basic 6.0 IDE, it was possible to break a running program that is sitting idle (waiting for an event on the UI thread) then hit F8 (single step). After that, any click, mouse-over, or other event that led to code would cause the debugger to break on the next line of code to execute, which would be the first line of code in the event handler. For example, if you showed a data-entry form with an OK button on it, you could break that form when idle, hit F8, then click the OK button. The debugger then would highlight the first line of code in the cmdOK_Click event handler.
Is there a way to do the above in Visual Studio 2017 with a C# Winforms project? I have seen similar posts on SO that instruct to break all (Ctrl-Alt-Break) then hit F11 (step into) then click a button on the form. But that isn't working. When I hit F11, the program goes back into running mode and events are processed without causing the IDE to break and show the first line to execute after the event.
Note that in the VB6 IDE when you break a program then hit F8 any event that fires afterwards and leads to an event handler will cause the IDE to break. I am looking for similar behavior for the VS 2017 IDE and a C# Winforms program.
Note: Please don't suggest to go into every even handler and set a breakpoint on the first line of code--consider that a complex program might contain thousands of event handlers, so setting breakpoints within each is not a practical (or elegant) solution.
Both F10 (Step Over) and F11 (Step Into) provide the desired behavior, but only if Enable Just My Code option is on:
Related
TL;DR:
I need to use both sendmessage and sendinput in order to get into an old function/event in a program that I can't re-build. While in there, I can't release the virtual mouse click using any of the methods I used to get in there in the first place - they're ignored.
Any other way to trigger the mousedown event - one where I could also release the mouse click might work.
I am writing a program that has to interact with a black-boxed old piece of software written in VB6 long long ago.
My program has to be able to send mouse clicks, specifically mousedown and mouseup events to the old program.
Here's the tricky part...
The mousedown event in the old program uses:
While GetAsyncKeyState(1)
Wend
to wait for the user to release the mouse.
Currently, in order to get the event to trigger, I need to use:
SendMessage(control_handle, WM_LBUTTONDOWN, 0, 0);
Input.type = INPUT_MOUSE;
Input.mi.dwFlags = MOUSEEVENTF_LEFTDOWN;
SendInput(1,&Input,sizeof(INPUT));
This does trigger the event (using just sendmessage does NOT trigger a necessary branch inside the event because that branch is entered with a GetAsyncKeyState(1) test as well), but issuing any combination of the following does NOT release the mouse click:
SendMessage(control_handle, WM_LBUTTONUP, 0, 0)
Input.type = INPUT_MOUSE;
Input.mi.dwFlags = MOUSEEVENTF_LEFTUP;
SendInput(1,&Input,sizeof(INPUT));
The code just keeps repeating in the while/wend part, it never gets out. The release code is being sent, but GetAsyncKeyState(1) isn't recognizing it as a mouse release. SUPER weird that GetAsyncKeyState(1) recognizes the function as a mouse down event, but GetAsyncKeyState(1) won't recognize as a mouse up.
What I've tested:
Clicking the real mouse elsewhere on the screen does release the
function.
Removing the sendmessage call, and using just the sendinput function
(and manually positioning the mouse over the object that needs
clicking) DOES work to release the loop.
I can't rely on the user not messing with the mouse while this is
doing its thing, so I'm hesitant to have the code virtually move the
mouse over the button to be clicked.
I've tried the deprecated mouse_event function as well, same exact
behavior.
Timing is critical. There can't be substantial delays between the trigger is issued and when it happens. Think keyboard-response speed.
I wrote a very simple VB6 program to simulate the while/GetAsyncKeyState(1)/wend loop to test this out on, and the behavior is the same - so I can be confident there isn't something weird in the old program that is causing this to happen.
Thank you very much for reading and helping!
In case this ever comes up for anyone else ever.... Using postmessage instead of sendmessage allows the program to continue on. Makes sense, really..
From a production application, we notice that our WPF buttons fire the ICommand.Execute method twice on fast double click.
Now, on every Command, the application is covered with a full-screen spinner animation, preventing any further interaction with the application.
This github repo contains a minimalistic repro of the issue. Note that:
when the Button's Command fires, the "IsBusy" flag is set to true
as a consequence, the BusyIndicator overlay will be shown
as a consequence, the Button cannot be pressed again until after 300ms
However, especially on slow computers, when fast double-clicking (really fast, like gaming fast that is), it is possible to fire the command twice without the BusyIndicator blocking the second call (this can be seen if the output shows 2 'click' lines right after one another).
This is unexpected behavior to me, as the IsBusy flag is set to true right away on the UI thread.
How come a second click is able to pass through?
I would expect the IsBusy Binding to show the overlay on the UI thread, blocking any further interaction?
The github sample also contains 2 workarounds:
using the ICommand.CanExecute to block the Execute handler
using the PreviewMouseDown to prevent double clicks
I'm trying to understand what the issue is.
What work-around would you prefer?
Diagnosis
This is only my guess and not a solid and confirmed info, but it seems that when you click the mouse button, the hit-testing is done immediately, but all the mouse related events are only scheduled to be raised (using the Dispatcher I presume). The important thing is that the control that is clicked is determined at the time the click occurred, and not after the previous click has been completely handled (including all UI changes that potentially follow).
So in your case, even if the first click results in showing the BusyIndicator covering (and thus blocking) the Button, if you manage to click for the second time before the BusyIndicator is actually shown (and that does not happen immediately), the click event on the Button will be scheduled to be raised (which will happen after the BusyIndicator is shown), causing the command to be executed again even though at that point the BusyIndicator will possibly be blocking the Button.
Solution
If your goal is to prevent command execution while the previous one is still executing the obvious choice is to make the Command.CanExecute result depend on the state of the IsBusy flag. Moreover, I wouldn't even call it a workaround, but a proper design.
What you're facing here is a clear-cut example of why you shouldn't make your business logic rely on UI. Firstly, because rendering strongly depends on the machine's processing power, and secondly because covering a button with another control by far does not guarantee the button cannot be "clicked" (using for example UI Automation framework).
I've got a Windows form with a ZedGraphControl, and for some reason whenever I rebuild it in Visual Studio while the gui builder is open, the control randomly resizes itself & changes its position. Here's a screen capture showing the behavior:
http://screencast.com/t/WxrLngp1VLf
*If I rebuild it a second time immediately after, it moves & resizes once again (in other words, it moves over & grows each and every time I build).
*I am not touching this control anywhere in my code; I just dropped it in the dialog and rebuilt.
*It behaves the same way in VS2008 and VS2013.
*If the gui builder is not opened when I build, it always remains as it should.
*I tried adding it within a panel (in case it was doing something weird based on properties of the container), but it behaves the same.
I'm totally stumped, and this makes it very cumbersome to work on the dialog - anytime I have to build I have to close the gui builder, build, then reopen it (otherwise, I have to keep manually moving the graph control back to where it was supposed to be)...
...Figured it out about 15 minutes after posting (d'oh!). The solution was to change the parent form's AutoScaleMode from None to Dpi. Looks like a bug in ZedGraph!
I've seen I have a problem with several users that use to double-click in buttons.
I have several buttons bound to commands that launch many actions.
For example there are two windows that communicate between them through a mediator so when I click "close the other window", the bound command sends a "CloseTheOtherWindowMessage". The problem is that when a user makes double click it tries to close the window a second time and, as expected, it crashes.
I've tried to set the window BusyIndicator as IsBusy when I press the button but my finger is quicker than MVVM and it still let me double-click before it starts showing the BusyIndicator.
I've found many examples of how to only admit double click in MVVM using interaction.Behaviors but I want just the opposite. Is there any example or other good and general solution for this problem?
Why is it "as expected" when it crashes? A crash should never be "as expected".
Your finger shouldn't be "quicker than MVVM". The Dispatcher thread always acts deterministically and sequentially. Do you use a multi-threaded approach?
In the command's Execute method or handler, raise its CanExecuteChanged event, and the binding engine will immediately call CanExecute(...). Make it so that this method will return false the second time. Maybe use a timer, or, better yet, you can logically determine by your view model state alone that the action is not possible right now (i.e. because IsOtherStuffAvailable is currently false).
I have the following line in my Window stanza in the XAML file:
Closing="Window_Closing"
I originally thought that the web page here assured me that this event fires when you use the big X close method, Alt-F4 or close from the system menu yet that doesn't appear to be the case since my breakpoint on the Window_Closing() function isn't being hit.
It does hit the breakpoint when I do the File, Exit method of exiting so that's working okay.
Re-reading that linked page leads me to believe that it may not trigger the closing event.
My questions are:
How do you catch the three methods listed in order to detect if your file is dirty and needs saving? I have all the 'dirty' and file saving code done, I just need to know how to trap the events.
Can you stop the exit from taking place with that method (as you can by intercepting the closing event)? In other words, if the user says they don't want to exit because the accidentally used Alt-F4 on the wrong window, can it be done?
According to the documentation page for the Closing event:
If a session ends because a user logs
off or shuts down, Closing is not
raised; handle SessionEnding to
implement code that cancels
application closure.
Therefore you'll want to make sure you handle the SessionEnding event as well as the Closing event. The SessionEnding event could be used to automatically save the current state to a temporary file that will be loaded again the next time the application starts. But if you do want to prompt the user, you can do so with a modal dialog box in SessionEnding but they will likely see the Windows screen that warns about unresponsive applications, giving them the chance to kill the process without responding to your dialog.
Try the Closed event instead: Closed="Window_Closing"