You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Oct 16, 2020. It is now read-only.
Repository navigation
This repository was 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
Not sure if this is a single bug, or multiple related bugs.
Create a new WinForms application and open the designer for MainForm.cs
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).
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.
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.
Activity
dgrunwald commentedon Aug 10, 2014
ComponentDispatcher.ThreadIdleis 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.
Fix part of #525
fix icsharpcode#525: WinForms designer does not properly jump to code…