Error : Unable to cast object of type 'System.Windows.Threading.DispatcherSynchronizationContext' to type 'System.Windows.Forms.WindowsFormsSynchronizationContext'.

walkinside / sdk

Develop powerful desktop and web applications on top of Walkinside 3D engine

4 stars 4 forks source link

Error : Unable to cast object of type 'System.Windows.Threading.DispatcherSynchronizationContext' to type 'System.Windows.Forms.WindowsFormsSynchronizationContext'. #27

Closed griemens closed 7 years ago

griemens commented 7 years ago

Hi,

I am trying to upgrade my code from Walkinside 7.0 to Walkinside 10.2 and encountered the bug mentioned in the title. Basicly I am hosting a winform in side a WPF application and embed a 3D control to it. This worked perfectly in 7.0 but is broken in 10.2

I suspect in 10.2 the method WindowsFormsSynchronizationContext and this was not used in 7.0. As my Main application is a WPF application the WindowsFormsSynchronizationContext is not created, but a DispatcherSynchronizationContext' is created.

Could you confirm ? If so is there a work around ? Could future versions of Walkinside 3D control have back support for WPF ?

Thanks.

kveretennicov commented 7 years ago

It's true that Walkinside itself doesn't use WPF and so far Viewer SDK did not have WPF support in mind. Although I believe WPF plug-in (as opposed to WPF viewer) would work.

Could you add a minimal project to reproduce the issue, ideally as a GitHub repo? We will see if anything can be done.

griemens commented 7 years ago

Definitely, will add an example on github in VS2012 solution format. Working with 7.0 and compiling in 10.2.

griemens commented 7 years ago

The code is pushed to this location https://github.com/griemens/sdk/tree/master/porting/issues/WpfWITest

Looking forward to your findings.

kveretennicov commented 7 years ago

Thank you.

We were able to reproduce the issue. The fix looks simple enough to include it in the next release. Unfortunately, it cannot make it into 10.2 SP1, we are too close to the market release to make any changes.

We also discussed in general the use case of embedding Viewer SDK into custom viewer applications, like you do. This has been possible (although not entirely straightforward) since the beginning of Viewer SDK. Yet we have seen very few Viewers implemented by SDK users. This may be due to lack of interest, lack of promotion or both.

At this point, to start promoting and supporting the embedding scenario would divert our resources from the higher priority topics. So we decided to make it clear that SDK users should not expect support for it.

We will be happy, however, to hear from SDK users that they have a compelling case for embedding Viewer SDK. We will gladly revert this decision when there is enough demand.

CC @walkinside/staff @walkinside/devs

griemens commented 7 years ago

Ok understood. My cases are

a prototype Windows surface tablet support. The regular Walkinside desktop application does not provide a good user experience and walking can not use keyboard.
Integrating the 3D view into a maintenance application. Again providing a better user experience for the end user. Like avoiding to do Alt-tab between applications.

I hope that in future SDK releases by luck the embedding of the 3D control will keep working :)

Thanks, for the quick response. Gert

kveretennicov commented 7 years ago

I can say that we have some big plans to address embedding story in a well-supported way, but from a different angle. Cannot disclose more at the moment, but it's going to be interesting. We will keep your use cases in mind.

The exception that you encountered is fixed now, you can try it whenever you get your hands on a 34xx package.