Hi there
I am noticing an obscure issue with the new version of the UltraWinDock 10.2.20102.1004 that did not occur in previous versions.
We are using an UltraDockManager in an MDI child form. The UItraDockManager is managing a number of docked panes including a DockableGroupPane/TabGroup on the form. The panes on the DockableGroupPane are quite complex in the number of controls they maintain. When focus moves to/from controls owned by panes within the DockableGroupPane to/from controls outside of the DockableGroupPane we are noticing that the controls are being moved around within the TabGroup i.e. drawing slowly. They end up in the correct position but you can see them moving and being redrawn. This movement occurs if I programmatically move focus i.e. calling Control.Focus() on some control or by user interaction with the form.
I provided an event handler for the Control.Move event for one of the System.Windows.Forms.Panel controls that was visibly drawing slowly and that handler is being hit on many occasions. It looks to me from the call stack that it is coming from a new method in current version of UltraWinDock. The protected override void VerifyChildElements(ControlUIElementBase , bool ) method in the WindowDockingAreaUIElement class in Infragistics.Win.UltraWinDock.
Now the thing is that this issue is only noticeable in this one implementation we have of the UltraWinDock i.e. in other mdi child forms we have no problem but they are also less complex.
I have also tried to replicate the problem in a test app with no luck and the app which does display the issue contains considerable proprietary code which prevents me from providing it to you.
I have tried using events on the controls to suspend/resume drawing but am having little luck in a practical solution sense.
I release that not giving you a sample with the problem makes it somewhat harder to diagnose but I am will to assist in any way.
Could you give me any tips on how to further diagnose further or workaround this problem?
Regards
Geoff
Hi,
It is hard for me to determine what might cause the issue without a sample or steps how to reproduce it. On this base I could suggest you to check what is the difference in the settings of the forms, which components may cause the slow down. Is it possible that the reason is in any changes made in your system configuration, e.g. resolution, video cards, IDE, OS and etc? If there is no way to provide me with sample illustrating the issue, please try to make a video (via CamStudio) and attach it zipped here.
I am looking forward to your response.
Regards,
Stefaniya
Let me know if you still experience the issue, and if so please provide me with more details.
- Stefaniya
Hi all,
I have logged this behavior in our system and will inform you both immediately when there is a resolution.
This issue may seem "fixed" in the current release, but it isn't.
Using build 10.2.20102.1064, the flicker has gone away but my child panels that are docked within the dock manager are not receiving layout event notifications from the parent window.
I tried a workaround, by setting the width property of the child panel to match the width of the parent window on the panel layout events, and that worked. However, the full "dock" behavior was not emulated by changing a simple width property.
Manually reverting the project to build 10.1.20101.1007 resolves the issue completely. No more flicker and the layout events are triggered properly.
Help?
William
Have you tested with the latest service release for 10.2 which is 2058.
Let me know if you notice movements with it.
The latest service release I see in the "My Downloads" section is 10.2.2064
The "movements" are not occurring in this release.
Short story: it isn't flickering but it isn't right.
Long story:
The child panels (with dock properties) do not receive layout updates.
Specifically, if a panel is docked in a WinDock area, and you drag that dock to be a floating window, the dock panel resizes, and the child panel still has the height/width from before the float.
If you then manually resize the WinDock area, as a floating window, the subsequent resize events do cause the docked child panel to resize..
In my first set of tests, calling Refresh and Invalidate in the parent panel layout event did not fix the behavior. I could read the width of the parent panel and change the width of the child panel with code, but it did not update the docked window behavior properly.
If you upload a small sample representing the described by you behavior, I will be glad to research it.
I have found your case (CAS-53577-61VJ7D ). I will research this further and will update you there.
I already sent this sample file as an attachment to a support ticket.
If you drag the panels around (float them) you will notice that docking values are refreshed one action behind the parent panel properties.
If you touch the splitter control, the child panels fill and dock correctly.