I using multilanguage solution from this thread Multilanguage in WPF
But i have problem with automaticaly Resource refreshing after language was changed.
Old strings stay in old language, new is traversed propertly.
What is easiest solution to solve this problem, for example refresh all resources in application?
I've worked with localization as well. The problem with it is the changes you make in culture info while your app is running, isn't going to be shown in the UI. The values for the controls do change, but the change isn't notified to the ui of the control. For as far as i've been googling this, i haven't found a reasonable solution for offline applications. Even InitializeComponents isn't doing the trick.
The only solution, allthough i don't like that one very much, is to change the culture, then start up a batch which will close and restart the app with the chosen cultureinfo.
The reason why i don't like this is because you rely on an external file (the batch) and not all applications can just be restarted like that. But it might do the trick.
The easiest solution I've found is to simply reopen the window - if you work with MVVM all the state (or the important state anyway) is preserved in the ViewModel(s) and only the view is refreshed.
I haven't used the extension you linked to, but any of these more advanced systems should handle refresh automatically. In my case, I just used {x:Static res:ResourceName} references to the resources, and refreshed the view when the language changed. Granted, I don't allow changing the language in the more complicated screens... :)
Related
Snoop allows you to look inside the application and change element properties.
Its a great asset for developers, but can be a security issue in some cases, like when we have users who like to look in places where they shouldn't be looking. Is there a way to do something to block applications like Snoop from "snooping" your application?
And if there is no way to block it, what do you recommend to do to minimize security risks?
Snoop is a utility that allows you browse visual tree of a wpf application and view and change properties. Its very useful when you are trying to debug something and have no idea what is going on. You can find more here.
Thank you.
There actually is a way to detect whether your application is being "snooped" by the snoop program. The solution I will give is not a silver bullet, and if someone really wants to snoop your application, they'd have to modify the snoop source code (it's an open source project).
What snoop actually does is it injects an assembly into your application, and the injected assembly recursively examines your applications visual tree starting at the root. In other words, snoop actually runs inside your application. That being said, the solution is to raise an event when the snoop assembly is injected into your application.
First, you need to subscribe to the assembly-loaded event somewhere in your application (preferably the begginging):
AppDomain.CurrentDomain.AssemblyLoad += new AssemblyLoadEventHandler(CurrentDomain_AssemblyLoad);
Then, you would implement the handler somewhat like this:
void CurrentDomain_AssemblyLoad(object sender, AssemblyLoadEventArgs args)
{
if (args.LoadedAssembly.FullName.StartsWith("ManagedInjector"))
MessageBox.Show("hey you, stop snooping");//and shut down your application.
}
You would probably need to enhance this solution for real silver-bullet solution, but at least this solution will definitely stop the current latest version of snoop being run as is (without the code modified). The better solution would be to check that no external assemblies are being injected into your application.
However, Kent is still right in the fact that a utility like Snoop should not cause any security vulnerabilities since security should not be implemented at the UI level. But at least this shows you how to prevent people from "snooping" your application.
By implementing security properly. If your "security" can be thwarted with a tool like Snoop, then you're doing it wrong.
Suppose there's a command that only certain users can execute. It sounds like the only place you're enforcing this is at the UI level (by disabling the corresponding button, for example). That being the case, you're right - I could easily use Snoop to enable the button and execute the command. But you should be enforcing the security constraints on your server, or perhaps in your command execution logic if you have no server. Basically, security should be implemented as close to the thing you're trying to protect as possible. Security at the UI level is merely for convenience of the user.
Great responses for a very good question,
I want to add an example of the password that should never be saved in your datacontext, as snoop check also the datacontext of the UI, so if you use the right control PasswordBox you will find that you can’t bind the password property, that means even if you snoop the application you can’t get the password as it is not saved in any property
But we found many people who try to create a work around (helpers, behaviors, usercontrol ...) to bind the password, but they forget that snoop can get it like that
So your server should never trust your client , every time it should check the right privilege (as we can sniff the client request using Fiddler for exp then rebuild a custome request to by pass client application security)
Is it possible to stop the Unloaded, OnApplyTemplate and OnTemplateChanged from triggering when we change the default font size in Windows XP?
It's been causing us some problems and we haven't figured out a good way to handle it. If you know what other events get triggered under this situation, it would help us a lot too.
Thanks!
The short answer is no. Many of the theme-dependent properties are set up in WPF as dynamic resources, meaning that templates get re-applied, etc. so that WPF apps behave well when those theme-based resources are modified.
Maybe you should re-post your question looking for specific solutions for what's breaking when the user changes theme-based properties.
Using the Composite Application Guidance tools from Microsoft, It seems as if there is no mechanism to allow you to query your modules ViewModels and ask if any of them have unsaved data. This is a problem because, and I'm guilty of this as well, you cannot stop the application from terminating when there is unsaved data...
I had thought about creating an interface called IApplicationEvents and have an event on there called ApplicationExiting. The thought being that each module can subscribe to the event and, when fired, can send back a "Cancel=true" or "Cancel=false" to say whether or not to allow the application exiting.
Curious to find out what others may have done in this instance, and to see what possible solutions there are in the community to solve this issue.
Thx.
There are a lot of choices here.
First off, I wanted to clarify a little nomenclature... typically your Views or ViewModels contained within your Module assemblies are the things with unsaved changes, not the Module itself. The Module is responsible for instantiating any views necessary at the start and contributing back to the shell during Initialize and that's typically it, so when you attack this problem, you'll want to focus on your views/viewmodels and not the Module classes.
Options off the top of my head:
Adopt a complimentary framework like Caliburn that has support for application events like this (as well as some MDI events like ViewClosing, that kind of thing). It has builtin support for Prism (http://caliburn.codeplex.com/)
Use a composite command. Your views or viewmodels will register themselves with a composite command elsewhere (CloseCommand, which you declare statically for your application) and every open view will have its CanExecute and Execute methods fired so that you can both vote in the closing of the application and also react to it, should it happen anyway. CompositeCommands are a feature of Prism. (See: Commanding Quickstart)
I think those are probably the most elegant. There's a few more options but these live in the best harmony with existing conventions.
Hope this helps.
I've been dabbling in WPF for a couple of months now and I've managed to grasp most of what's about and why/when it's used but I'm still struggling to see the value of the PageFunction class.
Can someone give me a simple, but concrete example of when a PageFunction might be the correct tool for the job?
Mainly, it seems to be a pattern to formalize branching in task based UI.
Let's say you have a form with a checkmark for an optional feature, but this feature requires additional information which is too complicated to fit on the same page.
Using this pattern allows delegating information collection to another component.
Moreover, there is kind of a strategy pattern applied, since you could have various subsystems able to collect the same information, all of them inheriting the PageFunction(of T), so that the code actually calling those does not need to know any detail about it.
Those are just some ideas, I have not exactly looked into it.
PageFunction in a page = Dialog box in desktop application (without Page).
You can use a PageFunction every time you use a dialog box in a desktop application and that you want to develop a webnavigation-like behavior to your program.
The main thing page functions enable is implementing workflows with sub-tasks and managing the return stack.
If you just rely on page-to-page navigation, it's hard to pause the current navigation path, do something else, and then come back and continue. PageFunctions enable that through the concept of Returning and unwinding the navigation stack.
I provided some real world examples of this here: http://www.paulstovell.com/wpf-navigation
We are looking at creating a WPF UI that runs across multiple AppDomains. One of the app domains would run the application while the remaining AppDomains would host a series of user controls and logic. The idea, of course, is to sandbox these User Controls and the logic away from the main application.
Here is an example of doing this using MAF/System.AddIn. What are some of the experiences other have had with this? How does this solution handle RoutedEvents/Commands that might occur inside one user control and do these get properly serialized across AppDomains? What about WPF resources? Can they be accessed across AppDomains seamlessly?
Old question, but nonetheless: You will need to have multiple UI threads - one per AppDomain. Create them like this:
var thread = new Thread(() =>
{
var app = new Application();
app.Run();
});
thread.Name = AppDomain.CurrentDomain.FriendlyName;
thread.SetApartmentState(ApartmentState.STA);
thread.Start();
The biggest challenge is then that you cannot send FrameworkElements between AppDomains (they are not MarshalByRefObject), but you can use the FrameworkElementAdapters.ViewToContractAdapter() and ContractAdapterToView() methods to work around this limitation. See the FrameworkElementAdapters MSDN page for more details.
Then, once you have this in place, the biggest problem IMHO is that you cannot lay anything on top of the FrameworkElement from the "remote" domain (the classical "airspace problem"). See this thread for more info about this.
I answered a simular question here and edited it for WPF also, you can use an intersting property of how the compisition engine operate's to tail-coat a dispatcher Pump, into one of the rendering contexts. It's a really light weight option.
Also, I'm guessing you know about the enterprise library and unity?
There is a WPF application block so using that pattern is not too painful ;) But don't they say, no pain no gain?
There's also CAB (Composite UI Application Block), ties into unity. The WPF SDK folks have crafted a Silverlight & WPF platform. (a.k.a Prism).
Oh right, also, you asked about Resources? I prefer to load reasources manually in the Application class. One thing I've realized, say you have a ResourceDictionary in a sub-folder and you are loading up MergedDictionaries in that ResourceDictionary. So, if in your Application class, you load "my-res-dir/MergedDictionaryLoader.xaml" (by code or xaml), ALL FUTURE LOADS OF MERGEDDICTIONARIES ARE LOADED FROM "my-res-dir".
Sort of insane if you ask me, I would think that as the process current directory has not changed, you should specify "my-res-dir/foo.xaml" for all your additional directories. However this is not the case (I do not believe this is documented anywhere at least very well and should be considered a bug imho).
So remember, WPF resource dictionary loading is going to be based off of the directory from which the current XAML is in. So you specify Source="foo.xaml" from within your "my-res-dir/MergedDictionaryLoader.xaml". I've even played with the URI pack / absolute syntax, however I've never found that too be much more intuative.