Hi all! I have this strange problem with the UltraTabControl in a production environment.
- The famous red cross... I know this is a thread related issue, but I don't find the cause. We have a central menu application from which all programs are loaded in a new threads:
Thread thread2 = new Thread(() => { Form2 f2 = new Form2(); Application.Run(f2); }); thread2.SetApartmentState(AppartmentState.STA); thread2.Start();
Once the sub-program is launched, there is no interaction between the menu and this program.
- This error occurs approximately once in the week and only by ONE user.
- At the moment the error occurs, the user is not working in the application. So it crashes when the program is in an inactive/idle state.
- We had a simular problem (red cross) earlier with the UltraStatusBar, but in that case all the users were affected. Removing the date- and time-panel from the UltraWinStatusBar resolved the problem.
Can someone give me a hint where I have to search to solve this issue? @Mike Saltzman, you perhaps? (Fan of your posts!) This is the exact error and stacktrace.
Error: Index was outside the bounds of the array.
Stack: at System.Collections.Generic.HashSet`1.SetCapacity(Int32 newSize, Boolean forceNewHashCodes) at System.Collections.Generic.HashSet`1.AddIfNotPresent(T value) at Infragistics.Win.Notifications.NotificationUIElement.AddNotificationUIElementIfPossible(UIElement parent, INotificationBadgeProvider notificationProvider) at Infragistics.Win.UIElement.VerifyChildElements(ControlUIElementBase controlElement, Boolean recursive) at Infragistics.Win.UIElement.DrawElement(UIElementDrawParams& defaultDrawParams) at Infragistics.Win.UIElement.DrawChildElements(UIElementDrawParams& drawParams) at Infragistics.Win.UIElement.DrawElement(UIElementDrawParams& defaultDrawParams) at Infragistics.Win.UIElement.DrawChildElements(UIElementDrawParams& drawParams) at Infragistics.Win.UIElement.DrawElement(UIElementDrawParams& defaultDrawParams) at Infragistics.Win.UIElement.DrawChildElements(UIElementDrawParams& drawParams) at Infragistics.Win.UIElement.DrawElement(UIElementDrawParams& defaultDrawParams) 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 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.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
The screen shot you posted here is very small and I can't make out much. So... that's an UtraTabControl with the tabs aligned to the left? Not an UltraTabStrip? The exception message indicate that it's blowing up when trying to show a notification badge - so presumably you are a applying NotificationBadges on a tab to let the user know there's something new on that tab. Are you absolutely certain that nothing on the background thread could possibly affect that? That would seem to be a perfect way to get into trouble if your background thread is making some kind of change that would cause a NotificationBadge to be shown on the tab. Working with background threads and UI controls can be extremely tricky. The interaction is not always obvious. For example, if the user tries to mouse over the tab and that tab repaints and that operation tries to access something on the background thread, that could easily cause the problem you are seeing here. Of the background thread interacts with any objects referenced by the UI Thread, same thing.
Hi Mike! Sorry for the small image, I include a bigger one. It is indeed a tabcontrol with the tabs aligned to the left. I have implemented two filters: the draw filter (to remove the focus when selected) and the creation filter (to right align - euhm on the bottom - the last tab).NavigationTabControl.DrawFilter = New NoFocusRectDrawFilter() NavigationTabControl.CreationFilter = New RightTabAlignCreationFilter()We don't apply any NotificationBadge. To be 100% sure I searched the source code for "notification" and for "badge" but no results. Do I have to search on something else?
I know that background threads can be tricky, but we only work with UI threads: we start all our application (application.run) in a different thread. There's no interaction between the threads - at least not intended. We are doing this for years without known issues. We recently migrated to 19.2 version and then the redcross error appeared. We found a workaround for the major one (the statusbar), but the one on the tabcontrol remained. At this moment the application is used by +-20 users, but before we roll out to all our customers, we want to be sure that this issue is solved. It's very strange that this occurs only by one user because the program is running on a central server (via remote desktop).
I took another look at the code and noticed something I missed before. I am pretty sure this is, in fact, something we might be able to correct on our end. I've asked Mike D. to write this up as a bug in our system so we can investigate further and hopefully provide you with a fix.
Mike, thanks for digging into the code, very much appreciated! A fix would be wonderful news because this issue is blocking us from deploying our application to all our customers, and the clock is ticking... How can I follow up the state of this bug? Do you possible have any timing for me: days, week, month...?
Things are a bit tight right now, as we are working to get the v21.1 release out. But I would think we could probably get this fixed and into a bi-weekly build by the beginning of next month.
Ok, we're looking foward to it! Will this become a bug-fix on our version (19.2.20192.302) or on the latest version? And if you guys manage to fix it, can you give us more details about the condition/cause of the problem? I've been searching for it for an eternity. ;-) A big thank you!
Hi Eddy,
Just FYI, now that I know what the issue is, I am able to reproduce the exception pretty reliably.
The key is that you need to force the UltraTabControl on one form to paint while another form is in the process or displaying another UltraTabControl - which is therefore painting at the same time.
I thought you might find this useful, once you get a fix, since it will allow you to verify that the fix is working.
To get the Exception, run the attached sample and click the button. This launches 20 forms with UltraTabControls, each on it's own thread. That, in itself, will not be enough. What you have to do it work it out so that the mouse ends up over a Tab (that is, the tabs on the left side where the text is) AS another form is in the process of dislpaying. That way, you end up with two tab controls painting at the same time and they both hit the HashSet at once.
So click the button and them mouse your mouse up and down the screen in the general vicinity of where the tabs are, and I can get the Exception almost every time.
WindowsFormsApp3.zip
Great. Glad to hear it.
I was pretty sure I nailed it. :)
Hi Mike! Just to keep you posted: we recently updated to version 21.1 and since then (fingers crossed) the error hasn't occured yet! #heroofthemonth
Yes. That was a typo in my previous post where I wrote "v21.2." I meant "v21.1".
I'm pretty sure the fix has been available in the latest bi-weekly builds of 20.1 and 20.2, also. Developer Support was supposed to send you a notification.
Just to be sure, I just tested out my sample with our latest 21.1 build and I am not getting the exception. So I am pretty confident that this is fixed.
Hi Mike, just to be 100% sure, the 2021 Vol 01 version of this week contains this threading-bugfix?
It's really up to you. The fix will be made in v20.1 and up. So you could get v20.1 or v20.2, or even wait for v21.2 if you like. For v20.1 or v20.2, you will need to get the latest bi-weekly build in order to get the fix, in addition to the base install. Once a fix is released, that is. :)