Hello,
I am using the latest 2020.1 components in a winforms application on a windows 10 machine.
When I close a form, some callback is triggered which as far as I can tell is/was not set up by my code that causes the 'parameter is not valid' exception. What is strange is this is not consistently reproducible. Opening the app fresh and performing the exact same steps multiple times results in this exception maybe 1/4 times.
I cannot provide the source because the solution is proprietary and far to large to share, however from the stack trace, none of my code is involved so I'm not sure that my code would help in any way:
at System.Drawing.Image.get_Width() at System.Drawing.Image.get_Size() at Infragistics.Win.ImageAndTextUIElement.PositionChildElements() at Infragistics.Win.UIElement.VerifyChildElements(ControlUIElementBase controlElement, Boolean recursive) at Infragistics.Win.UIElement.VerifyChildElements(ControlUIElementBase controlElement, Boolean recursive) at Infragistics.Win.UIElement.VerifyChildElements(ControlUIElementBase controlElement, Boolean recursive) at Infragistics.Win.UIElement.VerifyChildElements(ControlUIElementBase controlElement, Boolean recursive) at Infragistics.Win.UIElement.VerifyChildElements(ControlUIElementBase controlElement, Boolean recursive) at Infragistics.Win.UIElement.DrawHelper(Graphics graphics, Rectangle invalidRectangle, Boolean doubleBuffer, AlphaBlendMode alphaBlendMode, Boolean clipText, Boolean forceDrawAsFocused, Boolean preventAlphaBlendGraphics, Nullable`1 zoomFactor) at Infragistics.Win.ControlUIElementBase.Draw(Graphics graphics, Rectangle invalidRectangle, Boolean doubleBuffer, AlphaBlendMode alphaBlendMode, Size elementSize, Boolean preventAlphaBlendGraphics) at Infragistics.Win.ControlUIElementBase.Draw(Graphics graphics, Rectangle invalidRectangle, Boolean doubleBuffer, AlphaBlendMode alphaBlendMode) at Infragistics.Win.UltraControlBase.OnPaint(PaintEventArgs pe) at Infragistics.Win.UltraWinToolbars.UltraToolbarsDockArea.OnPaint(PaintEventArgs pe) at System.Windows.Forms.Control.PaintWithErrorHandling(PaintEventArgs e, Int16 layer) at System.Windows.Forms.Control.WmPaint(Message& m) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
When this exception happens, all my tools (file menu and quicklaunch toolbars) are replaced with a giant red 'X'.
If this is a bug in the components, is there a way to work around this?
Hello
Red crosses are generally issues with threading, as they occur during the paint event of the controls. It is most common for them to be accompanied by a null reference exception.
Parameter is not valid usually comes from a bitmap that is 0 bytes, so my best guess is that you have an empty image you try to set at this point, but since its on another thread, most of the time the operation is concluded and there is no exception, while at more load heavy times it will trigger.
Alternatively, you might be disposing of the object too soon, which will result in the same exception.
While this is the common case, it is possible that there can be an issue within our controls and in order to test and investigate, we need at least steps to reproduce this to test it on our end.
Sincerely,Tihomir TonevAssociate Software DeveloperInfragistics
So 2 things:
1) The closing of the form does not run any toolbar related code (disposing or setting anything)
2) Prior to upgrading to 2020.1 (from 7.3) this issue did not happen.
We have already had to work around a bug with STAThreadWarningSuspended, so my gut says this is a component issue. We have priority support for winforms components so I will reach out via support ticket to arrange a way to debug this.
So after many hours wrestling with Visual Studio just to get it to break where the exception actually happens here is what I found:
1) The image is not null but 'invalid'. I don't know how that's possible but there it is.
So when I first saw this I thought maybe something in my code was changing an image and got interrupted by some threading that I have no control over.
So since I was using a factory pattern to create tools via code, I decided to rip all that out and use the graphical designer to build all my menues (since that's what all the other forms in the system do and they don't seem to have a problem crashing the toolbar). As far as I can tell, the way all my tools are registered is the same as other forms.
Next, since the exception occurred at:Infragistics.Win.ImageAndTextUIElement.PositionChildElementsat this line: Size scaleSize = provider.GetScaledImageSize(this);I decided to see what provider.Control.Name was.
It turns out it is the Top Dock Panel. Other than registering a new toolbar with the toolbarmanager, I don't touch the dockpanel at all in that Form so I have no clue how to debug this further. As far as I can tell, when the form closes, something happens during disposal that corrupts the draw area of the top DockPanel.I will try using the service release, hopefully it is an msi and I can use the update utility, otherwise this will be a long process to manually update all the references.
Unfortunately applying the 2020.1.87 service release did not fix the issue.
I have now applied service release 104. Problem persists. I also noted in my previous message that the provider.Control.Name was the UltraToolbarsDockArea Top Dock area. I added an event handler to the PropertyChanged event of the Top UltraToolbarsDockArea instance to try and detect any changes that may be coming from my code prior to closing the form. The propertychanged event does not fire prior to the error. So either it is not my code that is causing this, or there is something being changed indirectly somehow that does not trigger a change event.
Yeah, I wouldn't really expect PropertyChanged to fire here. First off, that would only apply to the properties of the DockArea, which are largely irrelevant here since the DockArea itself is essentially just managed by the ToolbarsManager and doesn't really maintain a lot of it's own properties. Also, the issue here is likely not a public property change, but an image in memory that is getting disposed somewhere. It's unfortunate that the latest SR did not help. I thought there was a really good chance it would. Just to clarify, this is the SR that was released on 11/4, right?
The only way forward I can see here is for you to provide us with some kind of sample that demonstrates the issue so we can debug it. There's really just no other way for us to determine what image is having a problem and why it's getting disposed.
So I finally gave up and merged my latest work back down to a branch which was using the 7.3 components. After opening and closing the problematic forms about 50 times, no crashing toolbar.
I then removed 2020.1, installed 2016 volume 2, in the hopes that maybe this version would work (it's the oldest version that we have a license for) as it still has the UltraGridFilterUIProvider which is what we really need the new components for and no luck... this version also blows up the UltraToolbarsDockArea. So for now we will have to stay with the 7.3 components until we can find the time to disassemble our application to find out what exactly is causing this.
Hello Filip,
We would like to thank you for using our components, and please do get back to us when you have had the time to break this down into smaller fractions of code that we can review on our end and test further.
I hope to hear back from you soon, as well as that our future endeavours will bring positive results.