Have followed your suggestion and the main form now at least remains responsive, however a consequential issue is...
exceptionSystem.Threading.ThreadStateException: Could not instantiate ActiveX control '8856f961-340a-11d0-a96b-00c04fd705a2' because the current thread is not in a single-threaded apartment. at System.Windows.Forms.Control.MarshaledInvoke(Control caller, Delegate method, Object[] args, Boolean synchronous) at System.Windows.Forms.Control.Invoke(Delegate method, Object[] args) at AbsoluteSystems.Interact.RunTime.ChannelIO.PresentationService.CioPresentati onManager.SetupSessionViews(String sessionType, String sessionId) in S:\RunTime\ChannelIO\Src\CioPresentationService\CioPresentationManager.cs:li ne 1074 I believe that the MS web browser control I am using has a thread affinity for the main STA thread, so am not sure how to address this new issue i.e. how do I find the correct thread to create the browser control on. >From my understanding of COM, a process can support multiple STAs but only one MTA, so it does not (or does it???) neccessarily follow that STA based components would load themselves into the main STA thread in the initial AppDomain. Prior to this attempt to integrate the presentation service into our product, I have been using message queues to receive events on the listener thread, session threads were subsequently spawned which raised their own dialogs, presumably on the session thread and there were no UI issues, so... I would think its safe to assume that STA based COM components are not neccessarily loaded into the main STA thread. Can anyone provide a reference which addresses this issue - it might provide further insight into the above problem. regards -----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] Behalf Of James Bishop Sent: 12 April 2005 17:13 To: [email protected] Subject: Re: [ADVANCED-DOTNET] UI thread problems Are you using any COM objects? I'm no expert, but AFAIK a COM object that uses a single threaded apartment would load itself into your applications STA thread, which might block the UI? If so, it may help if you change the [STAThread] attribute on your main method to [MTAThread]. (also some .net framework classes use COM underneath, maybe the message queuing classes do?) HTH, James. > -----Original Message----- > From: Unmoderated discussion of advanced .NET topics. [mailto:ADVANCED- > [EMAIL PROTECTED] On Behalf Of Ross Diesel > Sent: 12 April 2005 08:32 > To: [email protected] > Subject: [ADVANCED-DOTNET] UI thread problems > > Hi > > I'm struggling with what appears to be deadlock/UI thread marshall > failure. > > The main application thread creates a UI synchronization object (UiSync) > on > startup and thereafter spawns a background thread (listener - not a pooled > thread) which is given access to UiSync. > > UiSync supports ISynchronizeInvoke by inheriting from > System.Windows.Forms.Form. > > The background thread uses the UiSync object to create and launch a > modeless > form. In the case of our product though, both the main form and the newly > launched form cease to respond to user input. In various other test > harnesses both the test harness application form and the UiSync launched > form remain responsive to user input. In the case of product the listener > thread remains responsive to message queue receives. > > Further, in the case of our product, we are spawning session threads from > our background thread on receipt of certain messages. These session > threads > are responsable for invoking UI functionality (web browser control > creation > and parenting) using the UiSync object. When the backgrond thread receives > and processes the first start session request, the UiSync.Invoke is > executed > and the application deadlocks and all ui is frozen. > > I have developed a number of test harness varying in complexity (wrt the > background processing) but these test harnesses all fail to reproduce the > deadlock/marshalling problem in our product when UiSync.Invoke is > executed. > UiSync.InvokeRequired is checked (and returns true) prior to execution of > the Invoke in the test harnesses and the product. > > Pausing the VS debugger and examining the process threads provides no > thread > status clues. > > Any suggestions as to the probable cause or to more sophisticated > tools/techniques for debugging this kind of problem would be most > appreciated. > > regards > > =================================== > This list is hosted by DevelopMentorR http://www.develop.com > > View archives and manage your subscription(s) at > http://discuss.develop.com =================================== This list is hosted by DevelopMentor. http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor� http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
