Replies
There is a ThemeManagerWindow created internally by our code and the expectation is that this would be created on the UI thread only so if it is being created on a MTA worker thread, we would need to determine why. I would recommend that you use WinDbg to determine why the ThemeManagerWindow is created on an MTA worker thread as well as check if any controls are having their handle created on the MTA worker thread in your application.
To do this you can set a conditional break point in the System.Windows.Forms.Control.CreateHandle as well as the private static Infragistics.Win.XPThemes.InitializeThemeSupport method to log the call stack and continue execution if the method was called on a thread other than the UI thread. You can use the following steps to do this.
1. Store the address of the UI thread:
r $t0 = $tid
2. Find the JITTED Code Address of the CreateHandle and InitializeThemeSupport methods:
.loadby sos.dll clr !name2ee * System.Windows.Forms.Control.CreateHandle !name2ee * Infragistics.Win.XPThemes.InitializeThemeSupport
3. Add a conditional break point that will log the call stack and continue if called from another thread other than the UI thread for each method:
bp JITTED_ADDRESS_CREATEHANDLE_FROM_PREVIOUS_STEP ".if (@$t0!=$tid) {.printf \"\nControl.CreateHandle detected on Worker thread at: %p\", $tid;.echo;!clrstack;.echo=================;gc}"
bp JITTED_ADDRESS_INITIALIZETHEMESUPPORT_FROM_PREVIOUS_STEP ".if (@$t0!=$tid) {.printf \"\nXPThemes.InitializeThemeSupport detected on Worker thread at: %p\", $tid;.echo;!clrstack;.echo=================;gc}"
This should give you the call stack where either of these are being called on a thread other than the UI thread and you can use this information to determine how to address the issue in your application. If you believe that there is an issue in our logic, please attach a sample that reproduces the issue that I can use for debugging and I will be happy to take a look.
It is possible that you could also workaround the issue in your application by accessing a static property off of XPThemes such as FrameBorderSize before any threading code in your application as this would also cause the creation of the ThemeManagerWindow since the InitializeThemeSupport method that creates it is called from the static constructor. Note that even if this works to work around the issue there may be code in your application accessing the controls from a MTA worker thread which isn't supported.
Note that I also reviewed the history of the XPThemes class and see that we did make a fix for an application hanging in 2015 where an application was creating multiple STA threads and if you are doing that you will want to test your application with 2015 Volume 2 or newer. As that is about five years newer than what you are using now, I would recommend testing with the latest (2017 Volume 2).
Let me know if you have any questions.
This is caused by a bug that was fixed in 2013 and it is recommended that you upgrade to 2013 Volume 2 or newer to get the fix.
Thank you for the call stack. I reviewed the MonthViewSingleAccessibleObjectBase.GetFocused method and found that we did fix this stack overflow in August of 2013. You are correct that it has to do with accessibility and the specific bug that was logged happened when starting the Narrator. As far as what could be different between the two machines, maybe different accessibility features are being used on the two machines. Maybe the Accessibility Tools for Windows page can help you identify what features might be in use that cause this on one machine and not another.
Your best options are to continue to use the workaround that you already are or upgrade to any volume 2013 Volume 2 or newer.
To get the designers to work you will need to install the version of the controls that you are using.
Sylvain,
Thank you for posting your workaround.
If you have a sample with steps to reproduce, we could look into the issue further to see if there is something that we should fix in the controls. If you are unable to reproduce it with a sample, the full call stack would allow us to at least review the code involved in the loop to see if we can identify anything obvious.
It would also help to know the exact version that is being used if you don't have a sample that reproduces the issue.
John,
2011 Volume 2 was released before Windows 10 was available so it wasn't tested for use on Windows 10 and it is recommended that you upgrade to a current version of the windows forms toolset if you need to support Windows 10. There were changes to Windows 10 accessibility that could be impacting the issue and it might even be reproducible in Windows 7 using accessibility tools.
Note that we also only support our toolset for three years from release so 2011 Volume 2 is no longer supported. If you are able to provide us a sample that reproduces the exception we will be happy to look at it if it is still reproduced in the latest volume of Ultimate UI for Windows Forms. If it is already addressed there our suggestion will be to upgrade the version that you are using.
If you aren't able to provide a sample and upgrading your application to use the latest volume of Ultimate UI for Windows Forms doesn't resolve the issue, please provide the full call stack that is repeated from the call stack as that might help us identify what might be happening.
Let me know if you have any questions with this matter.
Praveen,
If you have access to the source code of ShapedButton, then it would be recommended that you upgrade the Infragistics assemblies referenced by that library to match what you are referencing in your application. Alternatively, you can add a reference back to the Infragistics2.Win.Mics.v11.2.dll and its dependencies to your application and set the alias on the reference to something so that they aren't part of the global namespace so the C# compiler is able to continue to use the newer assemblies for the code that you are writing in your application.
For more details refer to the following:
Let me know if you have any questions with this matter.