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.**** >>>> >>>> ** ** >>>> >>> >>> >> >
