I am currently working on an enterprise WPF application and I am experiencing some issues with static resources: globally defined styles and converters.
The application works this way:
There is a shared host WPF application that is used as host for components developed by different teams (it's a PRISM application and MEF is used for importing plugins)
Each team can add plugins by creating new dlls, but cannot modify other teams' dlls
No changes can be made to the host application
My team is in charge of few plugins and we need to add more functionalities but we are wondering what is the best way to solve our problem.
In a simple (standard?) WPF application, we would have styles defined in the App.xaml file and all the xaml UserControls or Windows would be able to link to them at design time easily and of course at runtime.
But now, while I managed to get the styles to work during runtime, I cannot have them working at design time and it is causing two major issues:
I cannot see how things would look like in the IDE
When I reference a converter the IDE complains but I have no way to know how wether it will work at runtime or not.
How do I get StaticResources to be imported and, at the same time, work in my IDE?
If not possible, what other strategies can I adopt to overcome these issues?
If I understand you correctly you want to use your "Design" tab in Visual Studio to see style changes and check the look and feel of your WPF application.
If that is the case, I will disappoint you but I haven't met any WPF developer yet using the 'Design' instead of 'XAML' view to make changes etc. in more advanced applications. Unfortunately the "Design" view has many flaws, doesn't display the Views properly, has problem with static resources converter and what is more it is always resource hungry.
The way we are working with WPF applications is building them and inspecting the problems and changes using a Snoop utility to investigate the application, binding errors, style problems, etc. I have never seen a way to use the build in "Design" view without many flaws, hacks and performance issues.
What is more, you should write a fake host application so that you will be able to run your plugins without the need of running the main app (if that is a problem for you)
Related
Here's the situation:
We have an existing .NET executable that contains an application using WPF components (dialogs and forms). This executable was created using Gupta Team Developer 6.1, but I'm not sure that is relevant to my question. We'd like to re-use some of these forms in a C#-application, but this is proving difficult.
When we include the external components, either in XAML or by instantiating them in code, they look OK (i.e. fields, buttons, layout etc.), but the event wiring seems to be missing. Nothing happens when pressing buttons and tables/grids are empty.
I've read previous articles on this site on using external WPF components, but they all mention external assemblies compiled as control libraries. Are we trying to do something that's not really possible?
P.S As an experiment we've tried to instantiate the App-object from the executable directly and this brings up a fully functional version of the entire application (well, duh), but we'd really like to be able to pick and choose from the individual forms/dialogs.
I have a WPF executable and I wish to make provisions to it, so that later,
someone from outside might modify or add another window or page
using dll totally separate from my solution.
For short, I wish to make my wpf windows or pages pluggable. How do I do this?
Prism's support modular, on-demand-loading of modules and other parts of your application, in it's core.
you can use MEF framework to make pluggable modules (windows and pages), as it's fully integrated with Prism.
You can find examples and more information in the following resources:
http://www.codeproject.com/Articles/188054/An-Introduction-to-Managed-Extensibility-Framework
http://www.codeproject.com/Articles/37579/Managed-Extensibility-Framework-Part-2
http://www.codeproject.com/Articles/432069/Simple-MEF-Application-for-Beginners
http://www.codeproject.com/Articles/232868/MEF-Features-with-Examples
I have a silverlight application with several menu buttons, each of which opens up a user control in a center "work space" area. It works fine. Now what I'd like to do is make some more user controls, compile them into a dll, and through say, a configuration file, have the silverlight app add a new menu button and make it make one of those new controls appear. The difficult part is, I'd like to be able to do this without recompiling the silverlight app. I'd like another developer to be able to make a user control that does some things, compile it into a dll, and drop it into the silverlight directory with some changes to a config file to get the main app to load it in. Is there a way I could do this?
Since noone else has replied yet:
What you want to do is reflect classes form a third-party dll at runtime. This is possibly too big a subject for SO, and all I can really recommend is looking up examples of it, and maybe the msdn section on it.
You'll also want to look up serialization and deserialization in C# and silverlight (this question might be a good start).
Sorry I can't be more help than that, but hopefully someone more experienced will weigh in with a useful article or some such.
Good luck :)
Out of curiousity, is it possible to have 2 application layouts without having to have 2 projects?
Like one layout for desktop/laptops. And then one layout for tablets?
I know winforms only has 1 designer file, and that probably answers my question, but I was curious if i really just needed to re-create a whole new program for a tablet layout, even though it would have all the same functionality as the desktop, with all the same controls, just look slightly different.
I'd put the core functionality in a library assembly (DLL), and write two UI applications that reference the same core assembly.
You can write your own custom LayoutEngine which handles the layout. This way you leave all layout oriented task to your engine and can focus on code.
Here's an article on Microsoft on how to do this (with sample source):
http://msdn.microsoft.com/en-us/library/ms973821.aspx
From the article:
All Windows Forms controls provide a Layout event, along with a host
of other notifications, which enables the writing of a complex layout
code. To facilitate writing reusable layout engines, we can provide a
basic framework.
i wonder if there is a simple solution to change language of a wpf application during runtime. i used locbaml to globalize all the resources. Setting the Current Thread's UICulture in the App-constructor works fine, but when i try to chang it a little bit later, i doesn't reflect the changes anymore.
This was actually quite easy with winforms, but i have no clue how to solve the same problem with wpf.
any ideas?
regards
j.
No.
Once you load an assembly and it is bound to your application, you can not change classes in mid-work. You could create a bootstrapper assembly that loads the current language and when you change the language you close and re-open your application automatically, but I doubt that's what you want or need.
What I did on one of my projects was create a globalized application framework using converters, etc. You can see some of the problems I ran into here and especially this post which shows how it looked. HTH if you decide to go the same way as I did.