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.
Hi Filip,The STAThreadWarningSuspended issue is completely unrelated to this one. The stack trace you have here indicates that the exception is occurring when the code is trying to access the Width property of an Image. So that usually means that the Image object is exposed. The potential reasons for why that happens are:
1) Someone disposed it. 2) Your application is using multiple threads and it's trying to access that Image object at the wrong time because you are not properly marshalling data across threads. 3) There's an error somewhere in the code that is referencing the wrong image somehow. Is your application also using the UltraWinGrid? We recently fixes a similar issue where the UltraWinGrid had a problem with caching certain images where it would try to re-use an image which had already been disposed. And the caching mechanism is shared between the grid and the toolbars, so it's conceivable this is actually a bug in the WinGrid that has already been fixed. If that is the case, then updating to the latest Service Release should fix this issue.
The form is a mdiChild of a parent form with toolbars. The child form has an UltraGrid yes. But the toolbar on the parent form is what is crashing. The applications is very large and mostly not multi-threaded though I can't say for sure if there is or is not some worker process somewhere in the code. The issue it does not always happen. Sometimes the form closes fine, other times it causes the toolbar to crash. More importantly this did not happen in the 7.3 components so if it is a threading issue, there is no easy way for me to debug this without access to infragistics code so I can put a breakpoint on the code that is failing to inspect what image it is trying to set the width of. I would like to set up a remote debugging session on this please let me know how we can arrange 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.