Skip to content
This repository has been archived by the owner on Oct 16, 2020. It is now read-only.

WinForms designer does not properly jump to code when double-clicking a control or event. #525

Closed
dgrunwald opened this issue Aug 9, 2014 · 1 comment

Comments

@dgrunwald
Copy link
Member

Not sure if this is a single bug, or multiple related bugs.

  1. Create a new WinForms application and open the designer for MainForm.cs
  2. Add a new button to the form and double-click it.
    Expected result: SD switches to the code editor and places the caret in the newly created event handler method.
    Actual result: SD switches to the code editor, but places the caret at (1,1).
  3. Switch back to the designer, then double-click the button again.
    Expected result: SD switches to the code editor and places the caret in the existing event handler method.
    Actual result: SD does not switch to the code editor. However, on certain actions, such as moving the mouse outside the design surface, or selecting a different WinForms control, SD suddenly performs the switch.
    Repeating step 3 multiple times, it seems that the caret is placed correctly on every second attempt, and placed at (1,1) otherwise.

These problems also occur when creating an event handler from the property pad. In that case, moving the mouse outside of the property pad will suddenly cause SD to switch to the source code.

I possible cause might be that the WinForms Application.Idle event only fires when the mouse is over a WPF control. We had trouble with WinForms Application.Idle not firing earlier (in SD 4.x), see http://stackoverflow.com/questions/2344398/application-idle-event-not-firing-in-wpf-application

@dgrunwald dgrunwald added this to the 5.0 RC milestone Aug 9, 2014
@dgrunwald dgrunwald self-assigned this Aug 10, 2014
@dgrunwald
Copy link
Member Author

ComponentDispatcher.ThreadIdle is indeed not firing correctly when the user interacts with a WinForms control. This also affects SD 4.x, but there we seem to be using some timer that has the side effect of triggering the Idle event every 500ms, so this bug isn't too visible in 4.x.
In SD 5.0, we got rid of several timers and use change events instead, so Idle no longer fires regularly.

dgrunwald added a commit that referenced this issue Aug 10, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant