Joan VANDERWEYST
Top achievements
Rank 1
Rank 1
Joan VANDERWEYST
asked on 07 Jun 2017, 03:14 PM
We're trying to
upgrade our applcations to version 2017 R2 (from 2016 R2) and we are unable to
get the dialog boxes from the radRichTextBox control to appear (font and
paragraph). When we try to open those dialogs explicitly in code we get
exceptions thrown. While tracking down the problems we found that you've
introduced many compile time checks for WPF in your code (#if WPF) which are
causing the problems.
The assumption in your code that checking for WPF at compile time is enough is incorrect in cases (like ours) that have applications that mix both WinForms and WPF in the same application. The ability to mix is a core feature provided by Microsoft to provide the ability to support and enhance legacy WinForms applications with WPF functionality.
The error we're experiencing is in the method DialogHelper.CheckApplicationTheme. When the code attempts to access the Application object it is failing because we don't have a WPF Application object - we have a WInForms object. That results in the Application.Current value being null which causes an exception.
We've been using your WPF controls for years and haven't had this problem with previous versions and this is a major problem for us. Microsoft has supported mixing WPF, WInForms and even C++ in one application for years and we have used that ability extensively in our applications. Until now your controls have supported that functionality too.
Do you have a recommended method for supporting mixed application types like we have?
Would rebuilding your WPF source code with the WPF compile flag turned off help us or will there be side effects to that?
The assumption in your code that checking for WPF at compile time is enough is incorrect in cases (like ours) that have applications that mix both WinForms and WPF in the same application. The ability to mix is a core feature provided by Microsoft to provide the ability to support and enhance legacy WinForms applications with WPF functionality.
The error we're experiencing is in the method DialogHelper.CheckApplicationTheme. When the code attempts to access the Application object it is failing because we don't have a WPF Application object - we have a WInForms object. That results in the Application.Current value being null which causes an exception.
We've been using your WPF controls for years and haven't had this problem with previous versions and this is a major problem for us. Microsoft has supported mixing WPF, WInForms and even C++ in one application for years and we have used that ability extensively in our applications. Until now your controls have supported that functionality too.
Do you have a recommended method for supporting mixed application types like we have?
Would rebuilding your WPF source code with the WPF compile flag turned off help us or will there be side effects to that?
1 Answer, 1 is accepted
0
Hello,
We have reproduced the issue and it is a bug. I have logged it and you can vote for it and track its status in our Feedback portal here. I have also updated your Telerik points for reporting that.
There is no appropriate workaround that we could find, since creating in code a System.Windows.Applicaiton solved the issue only when a dialog is opened initially and after that is it not visible. Another approach to working around the issue is to use noXAML assemblies and implicit styles, but I could guess that your application uses XAML-included assemblies and migrating to Implicit styles might not be an option.
However, there is a solution that we have found and it should be included in the upcoming service pack shortly.
Regards,
Martin
Progress Telerik
We have reproduced the issue and it is a bug. I have logged it and you can vote for it and track its status in our Feedback portal here. I have also updated your Telerik points for reporting that.
There is no appropriate workaround that we could find, since creating in code a System.Windows.Applicaiton solved the issue only when a dialog is opened initially and after that is it not visible. Another approach to working around the issue is to use noXAML assemblies and implicit styles, but I could guess that your application uses XAML-included assemblies and migrating to Implicit styles might not be an option.
However, there is a solution that we have found and it should be included in the upcoming service pack shortly.
Regards,
Martin
Progress Telerik
Want to extend the target reach of your WPF applications, leveraging iOS, Android, and UWP? Try UI for Xamarin, a suite of polished and feature-rich components for the Xamarin framework, which allow you to write beautiful native mobile apps using a single shared C# codebase.