In my MDI application, the following is being fired off which is causing the child form to appear again in the MDI. At the point of catching VisibleChanged in the child form, I can see Visible has been set to True at this point.
Appears to stem from UltraWinEditors.TextEditorControlBase.LayoutToolStripOwningOverflow()
Any idea how I can switch this off? What is it doing?
> myForm.myForm_VisibleChanged(object sender, System.EventArgs e) Line 4362 C# System.Windows.Forms.dll!System.Windows.Forms.Control.OnVisibleChanged(System.EventArgs e) + 0x1d8 bytes System.Windows.Forms.dll!System.Windows.Forms.Form.OnVisibleChanged(System.EventArgs e) + 0x6d bytes System.Windows.Forms.dll!System.Windows.Forms.Control.WmShowWindow(ref System.Windows.Forms.Message m) + 0x193 bytes System.Windows.Forms.dll!System.Windows.Forms.Control.WndProc(ref System.Windows.Forms.Message m) + 0x39b bytes System.Windows.Forms.dll!System.Windows.Forms.Form.WndProc(ref System.Windows.Forms.Message m) + 0x18b bytes System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DebuggableCallback(System.IntPtr hWnd, int msg, System.IntPtr wparam, System.IntPtr lparam) + 0x14c bytes [Native to Managed Transition] [Managed to Native Transition] System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.CreateHandle(System.Windows.Forms.CreateParams cp) + 0x479 bytes System.Windows.Forms.dll!System.Windows.Forms.Control.CreateHandle() + 0x28f bytes System.Windows.Forms.dll!System.Windows.Forms.Form.CreateHandle() + 0x296 bytes System.Windows.Forms.dll!System.Windows.Forms.Control.Handle.get() + 0x68 bytes System.Windows.Forms.dll!System.Windows.Forms.Control.RectangleToClient(System.Drawing.Rectangle r) + 0xba bytes System.Windows.Forms.dll!System.Windows.Forms.ScrollableControl.ScrollToControl(System.Windows.Forms.Control activeControl) + 0x148 bytes System.Windows.Forms.dll!System.Windows.Forms.ScrollableControl.ScrollControlIntoView(System.Windows.Forms.Control activeControl) + 0xd9 bytes System.Windows.Forms.dll!System.Windows.Forms.ContainerControl.ScrollActiveControlIntoView() + 0x42 bytes System.Windows.Forms.dll!System.Windows.Forms.ScrollableControl.OnLayout(System.Windows.Forms.LayoutEventArgs levent) + 0x48 bytes System.Windows.Forms.dll!System.Windows.Forms.Form.OnLayout(System.Windows.Forms.LayoutEventArgs levent) + 0x3c bytes System.Windows.Forms.dll!System.Windows.Forms.Control.PerformLayout(System.Windows.Forms.LayoutEventArgs args) + 0x162 bytes System.Windows.Forms.dll!System.Windows.Forms.Control.PerformLayout(System.Windows.Forms.LayoutEventArgs args) + 0x317 bytes System.Windows.Forms.dll!System.Windows.Forms.Control.PerformLayout() + 0x19 bytes Infragistics4.Win.UltraWinEditors.v13.1.dll!Infragistics.Win.UltraWinEditors.TextEditorControlBase.LayoutToolStripOwningOverflow() + 0x124 bytes System.Windows.Forms.dll!System.Windows.Forms.Control.InvokeMarshaledCallbackHelper(object obj) + 0xef bytes mscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0x285 bytes mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0x9 bytes mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) + 0x57 bytes System.Windows.Forms.dll!System.Windows.Forms.Control.InvokeMarshaledCallback(System.Windows.Forms.Control.ThreadMethodEntry tme) + 0x113 bytes System.Windows.Forms.dll!System.Windows.Forms.Control.InvokeMarshaledCallbacks() + 0x10c bytes System.Windows.Forms.dll!System.Windows.Forms.Control.WndProc(ref System.Windows.Forms.Message m) + 0x2aa bytes System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.Callback(System.IntPtr hWnd, int msg, System.IntPtr wparam, System.IntPtr lparam) + 0x15a bytes System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DefWndProc(ref System.Windows.Forms.Message m) + 0x220 bytes Infragistics4.Win.UltraWinEditors.v13.1.dll!Infragistics.Win.UltraWinEditors.TextEditorControlBase.TextEditorControlBaseNativeWindow.WndProc(ref System.Windows.Forms.Message msg) + 0x880 bytes System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.Callback(System.IntPtr hWnd, int msg, System.IntPtr wparam, System.IntPtr lparam) + 0x15a bytes System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DefWndProc(ref System.Windows.Forms.Message m) + 0x220 bytes Infragistics4.Win.v13.1.dll!Infragistics.Win.UltraWinEditors.EditorButtonControlBase.EditorButtonControlBaseNativeWindow.WndProc(ref System.Windows.Forms.Message msg) + 0x7f bytes System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.Callback(System.IntPtr hWnd, int msg, System.IntPtr wparam, System.IntPtr lparam) + 0x15a bytes System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DefWndProc(ref System.Windows.Forms.Message m) + 0x220 bytes Infragistics4.Win.v13.1.dll!Infragistics.Win.UIAutomation.UiaProviderControlNativeWindow.WndProc(ref System.Windows.Forms.Message msg) + 0x9b bytes System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DebuggableCallback(System.IntPtr hWnd, int msg, System.IntPtr wparam, System.IntPtr lparam) + 0x14c bytes [Native to Managed Transition] [Managed to Native Transition] System.Windows.Forms.dll!System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(System.IntPtr dwComponentID, int reason, int pvLoopData) + 0x681 bytes System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(int reason, System.Windows.Forms.ApplicationContext context) + 0x57c bytes System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoop(int reason, System.Windows.Forms.ApplicationContext context) + 0x6f bytes CMS.exe!CMS.CMSControl.main(String() args) Line 601 + 0x9 bytes Basic [Native to Managed Transition] [Managed to Native Transition] Microsoft.VisualStudio.HostingProcess.Utilities.dll!Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() + 0x5a bytes mscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0x285 bytes mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0x9 bytes mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) + 0x57 bytes mscorlib.dll!System.Threading.ThreadHelper.ThreadStart() + 0x51 bytes [Native to Managed Transition]
Hi Andrew,
I will be happy to assist you with your inquiry.
In order for us to properly isolate the cause of this issue, we will need to reproduce this behavior in our environment. May I ask if you can provide me with a sample with steps to reproduce? If this is not possible, can you provide me with more details about you application that I can use to create a sample which mimics your app?
It is my understanding that you are using build .2040.
I am looking forward to hearing from you.
Hi Jose,
Sorry I can't provide you with this at the moment.
Can you check your code base to see why this LayoutToolStripOwningOverflow() event is firing? If I can at least turn this behavious off I can keep my client happy. Can you also find out when this event was added, as a recent bug was fixed for me in the latest hotfix which resolved toolstrip overflow not working correctly.
Thanks,
Andrew
Currently trying to put in a hack in the VisibleChanged event in my base form.
The MDI is in the process of loading Child B. Child B has a toolstrip, the PerformLayout() method appears to get fired in Infragistics.Win.UltraWinEditors.TextEditorContractBase.LayoutToolStripOwningOverflow() which fires off the events and sets Visible = True on Child A. Just looking to see if I can stop overflow on the toolstrip in Child B which would stop Child A loading. Still needs looking in to though.
// MD 11/10/09 - TFS23562 #region LayoutToolStripOwningOverflow private void LayoutToolStripOwningOverflow() { ToolStripOverflow overflow = Utilities.GetParent( this ) as ToolStripOverflow; if ( overflow == null ) return; // Unfortunately, there seems to be no way to get at the owning ToolStip from the ToolStripOverflow, so we are forced to // used reflection to work around this issue with the ToolStrip class. tryP { ReflectionPermission perm = new ReflectionPermission( ReflectionPermissionFlag.MemberAccess ); // VC 02/11/2010 Security Assert exception update //perm.Assert(); //if (Utilities.CanAssert) perm.Assert(); const BindingFlags bindingFlags = BindingFlags.NonPublic | BindingFlags.Instance; PropertyInfo property = typeof( ToolStripOverflow ).GetProperty( "ParentToolStrip", bindingFlags ); if ( property == null ) { Debug.Fail( "The ToolStripOverflow.ParentToolStrip property has been removed. Update the fix for TFS23562" ); return; } ToolStrip toolStrip = property.GetValue( overflow, bindingFlags, null, null, CultureInfo.CurrentCulture ) as ToolStrip; if ( toolStrip == null ) { Debug.Fail( "The ToolStrip is not valid. Update the fix for TFS23562" ); return; } // here toolStrip.PerformLayout(); } catch ( System.Security.SecurityException ) { } } #endregion LayoutToolStripOwningOverflow
I've found a workaround.
It wasn't Child B's toolstrip firing off the events, it was actually Child A's toolstrip (the child I am leaving / set visble = false).
Setting Toolstrip.CanOverFlow = False on Child A stops the event firing and re-showing the child, for now at least.
Hello Andrew,
It is my understanding that you have resolved this issue by setting the CanOverFlow for Child A's Toolstrip to false.
Please let me know if we can be of further assistance regarding this matter.
Hello Jose,
This is a work around, not a fix.
I imagine somebody still needs to investigate what's going on here? I shouldn't have to turn off a property on a toolstip to stop child forms randomly reappearing in my MDI application.
I will be happy to look into this further.
May I ask if you can provide me with the exact steps you used to reproduce this behavior in your application?
Thank you for your response. I discussed this issue with our engineers, and they believe the issue is occuring because the handle for the UltraTextEditor is being created.
However, without being able to reproduce the issue, we are unable to determine the ultimate cause of the issue. I've modified the sample Jose provided earlier to more closely match what I believe you're doing. I'd like you to look at the sample and compare it with the project you're having the issue with, and then modify my sample to match what your project is doing.
I can't provide you with this unfortunately so we are at a stale mate.
Did you ever find out the information regarding the following?
"Can you check your code base to see why this LayoutToolStripOwningOverflow() is firing" ?
By setting the CanOverflow = False I imagine just stops the above event from being called.
The stack trace doesn't provide the information needed for us to properly reproduce this behavior. Reproduction of the behavior you've described is crucial in order for us to isolate the cause of this issue and provide you with a solution. There may be a reason why the toolStrip.PerformLayout() method is call in this scenario, but without reproducing your issue, we may not be able to provide a proper fix to prevent this issue from occurring in the future.
Is it possible for you to alter the sample attached in my previous message so that it reproduces the behavior instead?
I'm using versing 13.1.20131.2040 and it's still an issue since nothing has changed here.
I can't send a sample as it's in our main job system.
I was hoping that the stack trace would give some indication in to what is going on.
Regards,
May I ask if you are still encountering this issue?
I have attached the sample project I used to test this. Please test this project on your PC; whether or not it works correctly may help indicate the nature of this problem.
If the project does not work correctly, this indicates either a problem possibly specific to your environment, or a difference in the DLL versions we are using. My test was performed using version 13.1.20131.2060 in NetAdvantage for Windows Forms 13.1.
If the project does show the product feature working correctly, this indicates a possible problem in the code of your application. It will help if you can provide a small, isolated sample application that demonstrates the behavior you are seeing.
Or, if this sample project is not an accurate demonstration of what you're trying to do, please feel free to modify it and send it back, or send a small sample project of your own if you have one.
Please let me know if I can provide any further assistance.