We are using the Dock Manager's PaneDeactivate event to run processes that must occur before the user can continue working on the next pane they have selected.
What I am finding is that when a dialog box is launched from the active pane the PaneDeactive event is firing, which I guess makes sense, however this means that the code we expect to run when switching panes is firing when we have not actually switched to another pane.
I was hoping to find an event such as the TabSelecting event which is raised by the Tabbed MDI Manager, which allows me to determine which tab I am leaving and which tab I am selecting, but there is no such event on the Dock Manager.
When the PaneDeactivate event fires, how can I establish that no other pane is actually about to be activated? In my scenario I have just opened a dialog box and will be returning to the tab that has just deactivated and so need to be able to prevent execution of the code that is only required when switching from one pane to another?
Thanks in advance,
Jim.
We are running v13.1.20131.2040 btw
Hello Jim,
You are correct. When a dialog box is launched from the active pane the PaneDeactive event is firing. What is the important detail here is PaneDeactive event is fired after dilog box is closed. This allows you by overriding OnActivated event of your Main form to set the active pane dialog box was launched from to become active again. To achieve this you need to save the last active control in Main form Deactivate event and to restore it in OnActivate event.
Please find a sample solution implementing above described procedure.
Please let me know if this is what you are looking for or if I am missing something.
Hi Milko,
Thank you for taking the time to reply to my question.
Your suggestion sounds entirely sensible, however, in our implementation the PaneDeactivate event is firing while the dialog is still open. Having noticed that I had the same problem when activating another application I put together a sample solution to demonstrate the behavior but when I added a dialog call I could not replicate the problem. My conclusion is that something else in our solution is causing the event to fire.
In the meantime I seem to have found an acceptable solution to both problems. When the PaneDeactivate event fires I am checking if the form can focus; with a dialog open it cannot. I am also checking to see if the application is activated. When the main form cannot focus or when the application is not activated I simply bypass the code we execute when switching panes.
I would welcome your further input if you can see a problem with this approach, otherwise thanks again for your time and effort.
Regards, Jim.
I am just checking about the progress of this issue. Let me know if you need my further assistance on it.
Thank you for using Infragistics Components.
Sincerely,
Milko
Developer Support Engineer
Infragistics
www.infragistics.com/support
Hello ,
PaneDeactivate event should occur before dialog to be shown , this is the expected event chain. If this event doesn’t occur before showing of the dialog, I assume that somewhere in your code you have something like:
ultraDockManager1.ActivePane = somePane;
and after then calling Show method of your Dialog form. This could explain, why the events occur in different order in your application.
About the workaround you’ve found, if the dialog form is shown then CanFocus property of the caller will be false until dialog was closed. So if this works for you and your application always will flows this pattern (PaneDeactivate to occurs when the dialog is shown), I do not see obvious reason not to use it.
Thank you for using Infragistics components.