Craig, You are correct. We do not require docking in our solution, but if we did, it would be difficult to use a 3rd party docking control to dock forms across UI threads.
Mike On 7/19/06, Craig Vermeer <[EMAIL PROTECTED]> wrote:
I don't have any solution suggestions, but I'm interested in a bit more info about your approach, if you don't mind. We attempted something similar (multiple threads, but I don't think multiple AppDomains) at one point, but (if I remember correctly -- it's been a while) ran into problems when trying to do Visual Studio-style docking within the UI Shell using a third-party component suite, because Windows Forms would not allow parent-child relationships between forms on different threads. Does your framework do this kind of docking for your sub-apps? If so, how did you solve it? We thought that one way to solve it would be to dig into the win32 APIs to re-parent the window, similar to the technique in this article : http://www.codeproject.com/cs/miscctrl/AppControl.asp We actually did end up using the control presented in the article for hosting of some legacy apps within our new framework. However, we ended up scrapping the idea of running native sub-components on separate threads and instead worked on training our developers to appropriately use a BackgroundWorker component within the sub-components that they wrote. Michael Gold wrote: > Thanks for all the help so far. > > To answer some questions: > > We are using multi-app domains so that each sub-application has its own > context (its own statics / its own app.config ) which allows the apps to > behave mostly as if they were stand alone .exes and also discourages > coupling between apps because they can no longer use static variables to > share state. Our original intent was to only use multi-app domains and a > single UI thread, however, WinForms makes assumptions (through the use of > statics) that all forms will be in the same AppDomain and thus some > things > break when you create a form in a second AppDomain (specifically > Tabbing). > > An interesting aside to this is that .net 2.0 is better about this, > but it > still doesn't have it right (tabbing is now reversed instead of not > working > at all). This is interesting because microsoft's own VTSA team claims > you > can run winforms PlugIns in thier own appDomain. I pointed out this > problem > to them at teched and they seemed unaware of it. They have since > confirmed > it to be an issue, but I have yet to hear of a resolution. > > Anyway, to get around the AppDomain problem we have attempted to run each > sub-application on its own UI thread within its own AppDomain. As > mentioned > originally, we've got this working pretty well, except for the debugger > issue. > > We do mark all our threads specifically as STA and we are carefull about > invoking correctly for any calls from background threads to our UI > threads. > > > At Danny's suggestion, I tried turning off FuncEval, but that does not > solve > the problem. > > Thanks for the pointers to Mike Stall's blog. I will try to contact > him or > one of the bloggers he links to directly to see if they can offer any > other > advice. > > -Mike > > On 7/19/06, Danail Grigorov <[EMAIL PROTECTED]> wrote: >> >> I observed the same behaviour with VS2003. Although I don't know if >> you've >> hit the same problem, >> in our case it, the problem turned out to be the interaction between >> 'Allow >> Property evaluation in variables window' (in Options/Debug/General) >> being >> turned on, and having a 'watch' on a property of some Control. >> I guess that forces the debugger to do a FuncEval on the property, >> from a >> different thread, which ultimately results in a windows message being >> sent >> cross-thread (we had watch on a Control.Text property which resulted in >> WM_GETTEXT) and this sometimes (because of the window manager's design >> that >> only the thread that created the window can process its messages) >> causes a >> deadlock -- which eventually forces the debugger to abort the thread the >> is >> doing FuncEval on the property - and hence the ThreadAbortException. >> >> Also, please mind, that having a watch is not the only way to hit this >> problem, it can also came from the tooltips >> that the debugger displays sometimes. >> >> As somebody already mentioned this is all explained (very well) in Mike >> Stall's blog -- especially the entries about FuncEval >> >> In short, try to turn off 'Property evaluation' and see if this helps. >> >> Danny >> ----- Original Message ----- >> From: "Michael Gold" <[EMAIL PROTECTED]> >> To: <[email protected]> >> Sent: Wednesday, July 19, 2006 3:07 AM >> Subject: [ADVANCED-DOTNET] VS2003 Debugging Issues with Multiple UI >> Threads >> >> >> > Hello, >> > >> > My team has developed an application that uses Multiple AppDomains and >> > Multiple UI threads to house somewhat related components (or >> > sub-applications) within a common UI "shell" allowing these >> components >> to >> > communicate in a loosely coupled fashion and all that other good stuff >> > (its >> > somewhat CAB like, but we think better). It works great, except we >> are >> > running into a problem with the vs2003 debugger where we set a break >> point >> > in one of the sub-applications and then close the sub-app (which >> causes >> an >> > Application.Exit in its AppDomain) and then re-open the sub-app (which >> > creates a new AppDomain and UI Thread). Soon after doing that, >> when the >> > break point is hit, the debugger will freeze for 10 seconds and then >> throw >> > a >> > first chance ThreadStopException which will cause the sub-app to >> crash. >> > The problem only seems to happen in the debugger and under very >> limited >> > testing in vs2005, we don't see the problem (unfortunately we are >> still >> > stuck in a 1.1 world for now). >> > >> > Has anyone tried anything similar or seen this behavior from the >> debugger? >> > I googled for ThreadStopException and found some chatter about the >> Watch >> > window causing this, but we still get this problem even if we hide all >> the >> > watch/locals/etc windows. >> > >> > Thanks in advance for any suggestions. >> > Mike >> > >> > =================================== >> > This list is hosted by DevelopMentor(r) http://www.develop.com >> > >> > View archives and manage your subscription(s) at >> > http://discuss.develop.com >> >> =================================== >> This list is hosted by DevelopMentor(r) http://www.develop.com >> >> View archives and manage your subscription(s) at >> http://discuss.develop.com >> > > =================================== > This list is hosted by DevelopMentor(r) http://www.develop.com > > View archives and manage your subscription(s) at > http://discuss.develop.com =================================== This list is hosted by DevelopMentor(r) 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
