No, nothing funky. It was quite a while ago so I can't remember the exact code, but I'm fairly certain I was just using ICommands in my VMs and binding buttons to these.
I did add some log messages to confirm that I was talking to the API on the same thread that the host app invoked my add-in on. The issue is something to do with the host application and how it hosts the runtime. As soon as you get another thread involved, even if it's just doing a simple sleep loop, everything else becomes unstable. On Fri, Aug 19, 2011 at 2:01 PM, Grant Molloy <[email protected]> wrote: > Hi Matt, > > Ok.. > So WPF has 2 threads, first for Rendering (which is pretty well hidden), > and the other to update the UI, perform code, etc. > You haven't hooked into the first Rendering thread with any funky code have > you? > How are you interacting with the API? > ie. Just on say the Click event of a button, or SelectedIndexChanged of a > combobox or list, or are you using other events too? > > Grant > > On Fri, Aug 19, 2011 at 9:25 AM, Matt Siebert <[email protected]> wrote: > >> No, it was WPF's default 2 thread model. >> >> I originally noticed the flakiness under certain circumstances. I tested >> some other non-WPF scenarios where I created an extra thread that didn't in >> any way interact with the host app's API, but this still resulted in the API >> calls on the main thread becoming unreliable (i.e. weird exceptions being >> thrown intermittently, method calls not returning). >> >> Ultimately, I just couldn't trust it for running a production application. >> >> On Thu, Aug 18, 2011 at 10:03 PM, Grant Molloy <[email protected]>wrote: >> >>> You say that the API becomes "flaky" when the add-ins use multiple >>> threads.. >>> Have you coded the use of extra threading within your WPF component or >>> are you referring to the default 2 threads of a standard WPF application? >>> Is it flaky all the time, or under certain circumstances, or certain >>> method calls / events / etc? >>> >>> >>> On Thu, Aug 18, 2011 at 4:25 PM, Matt Siebert <[email protected]>wrote: >>> >>>> Our product is an "add-in" for a native 3rd party CAD application that >>>> hosts the .NET runtime and loads add-ins like ours into it's process. >>>> >>>> Ultimately this does not work well with WPF's threading model. The CAD >>>> application's API becomes very flaky when add-ins use multiple threads. >>>> The >>>> solution at the time was to pull most of our code and GUI out into another >>>> process which involved developing a small service layer to ferry data from >>>> one process to the other. This also meant that we could use .NET 4 instead >>>> of being stuck with .NET 3.5 (and it's WPF text clarity issues) since the >>>> CAD application did not support .NET 4 at the time. >>>> >>>> I'm now concerned about the effort involved in maintaining this service >>>> layer and expanding it as we develop new products that cover more of the >>>> host application's API, and the additional logic for handling some of the >>>> more advanced interaction scenarios across the service boundary. >>>> >>>> If we were to use WinForms instead then we could dramatically simplify >>>> the code base and future development. >>>> >>>> >>>> On Thu, Aug 18, 2011 at 3:18 PM, Jake Ginnivan < >>>> [email protected]> wrote: >>>> >>>>> +1 would be very interested to know what constraints would cause you to >>>>> choose winforms over wpf..**** >>>>> >>>>> ** ** >>>>> >>>>> *From:* [email protected] [mailto: >>>>> [email protected]] *On Behalf Of *Grant Molloy >>>>> *Sent:* Thursday, 18 August 2011 1:05 PM >>>>> *To:* ozDotNet >>>>> *Subject:* Re: Good looking WinForms apps**** >>>>> >>>>> ** ** >>>>> >>>>> I think that you should also explain in more detail the "constraints" >>>>> of the situation which are causing you extra work and why this has made >>>>> you >>>>> believe that WPF is not the correct choice.**** >>>>> >>>>> ** ** >>>>> >>>>> Grant**** >>>>> >>>>> On Thu, Aug 18, 2011 at 2:33 PM, Matt Siebert <[email protected]> >>>>> wrote:**** >>>>> >>>>> Hi folks,**** >>>>> >>>>> ** ** >>>>> >>>>> Can anyone point out some particularly good looking WinForms apps? >>>>> Screenshots will do, a working app I could show someone would be better. >>>>> **** >>>>> >>>>> ** ** >>>>> >>>>> This is a bit of a strange request so I should probably explain a >>>>> little...**** >>>>> >>>>> ** ** >>>>> >>>>> We've built a product using WPF but we have lots of constraints imposed >>>>> by the environment we're coding for. This has caused a lot of extra work >>>>> with more to come. As such, I don't think WPF is the right choice and I'm >>>>> trying to convince my manager that it's worth considering switching to >>>>> WinForms which is much better suited to this environment. He's not a >>>>> developer and is fairly visually oriented, and he's worried that if we >>>>> were >>>>> to use WinForms then we may not be able to produce a good GUI / UX. I've >>>>> assured him that this isn't the case but some good examples would help. >>>>> **** >>>>> >>>>> ** ** >>>>> >>>>> Cheers.**** >>>>> >>>>> ** ** >>>>> >>>> >>>> >>> >> >
