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.
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.
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.
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.
Hi Filip.
There was really never any possibility of the image being null. If the image had been null, then you would be seeing a NullReferenceException. "Parameter Not Valid" is most likely because the image is disposed.
But everything you are seeing here is consistent with what I've been saying, which is that the caching mechanism is erroneously holding on to a disposed image and trying to re-use it because of the bug I previously mentioned. So if that's the case, it should be fixed in the bi-weekly builds I liked above.
In fact, I am pretty sure that the latest service release has been officially posted since my last post here. So you could just try that, instead.
To download the latest service release follow these steps:
View My Keys and Downloads: www.infragistics.com/.../keys-and-downloadsLog in to the Infragistics web site if you are not already logged in.Select the product you would like to download a service release for.Select the “Service Releases” tab.Select the download (e.g. Infragistics Xamarin.Forms 2015 - Service Release)
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.