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