I'm working on an old project that supports Windows Forms.
This project contains some ResourceManager for the support of a few localizations. The idea is that you call ResourceManager["SomeResource"] instead of Resource.SomeResource and it returns you a localized string.
And these localized strings are used in the code of the initialization of the form. For example, you have Form1, and in Form1.Design.cs there is some code like this:
Label label1 = new Label();
label1.Text = ResourceManager["SomeResource"];
So the label will be created with an already localized string in the Text.
And we need to add the functionality of changing the UI language without reloading the Form.
We can just set the every Text property of every controls again. But it's a lot of code, the form contains a lot of controls.
We can call the Form.InitializeComponents(), this method will recreate all controls with new localized strings, but in some cases, it works slowly because it reloads some big data again.
Is there some other way to refresh all UI controls and get the new localized strings? Do Windows Forms support some mechanism like Binding in the WPF to create the "connection" between the Text properties and localized resources?
I think that you can achieve this by use of Invalidate() either on the form itself or on a container control that your other controls may be encompassed by.
I need to enhance one legacy WinForms app to support the inheritance of the TextRenderingHint setting in the app forms.
For simplicity, let's suppose that we have a main form with the TextRenderingHint property of the System.Drawing.Text.TextRenderingHint type. This property specifies the text quality in the main form and must be inherited in dialog forms called from this main form. The text in the main form is drawn using Graphics.DrawString method, and there is no problem to support various settings of the main form's TextRenderingHint property (in fact, it is simply assigned to Graphics.TextRenderingHint before drawing text with Graphics.DrawString).
The problem is that the interface of one of the dialogs is based on the WinForms ToolStrip component and I need to redefine text drawing in its items to support the TextRenderingHint setting of the main form.
After searching the Internet and analyzing the source code of the ToolStripRenderer class in a reflector app, I came to the conclusion that the best way to implement what I need is to use a custom ToolStrip renderer with the redefined OnRenderItemText method.
I found the following code in the default implementation of the OnRenderItemText method in the ToolStripRenderer class (see the full code at the bottom of my question):
graphics2.TextRenderingHint = TextRenderingHint.AntiAlias
TextRenderer.DrawText(graphics2, text, textFont, New Rectangle(Point.Empty, size), color, textFormat)
, which gave me an idea that I could try to solve my problem with this simple implementation of OnRenderItemText in a class derived from ToolStripRenderer:
Protected Overrides Sub OnRenderItemText(e As ToolStripItemTextRenderEventArgs)
e.Graphics.TextRenderingHint = _MainFormTextRenderingHint
MyBase.OnRenderItemText(e)
End Sub
My idea is based on the fact that if we do not use vertical text in ToolStrip items (we don't), the basic OnRenderItemText method "just" calls TextRenderer.DrawText and theoretically my idea could work. Unfortunately, in practice this works only for the TextRenderingHint.ClearTypeGridFit option - at least, on my dev pc.
The only viable idea I see now is complete rewriting of OnRenderItemText and using Graphics.DrawString inside. Am I right? Are there other solutions to my problem?
UPDATE #1. I encountered a problem trying to reimplement OnRenderItemText based on Graphics.DrawString. It seems, it's impossible to convert text format flags passed to TextRenderer.DrawText (the TextFormatFlags enumeration) to the StringFormatClass parameter Graphics.DrawString expects...
UPDATE #2. The default implementation of the OnRenderItemText method in the ToolStripRenderer class is the following:
I am writing a program that overlay's a toolbar onto another applications window. I am able to iterate through the MDI child windows and even access all the controls via PInvoke. The one thing I am trying to figure out is how to get the controls actual Name property.
I am able to see the name of the field using Hawkeye but I cannot figure out how it is getting the control name.
One thought is that it may be injecting something into the target application and running something like Control.FromHandle but I am not 100% sure.
Thanks for any help.
Unfortunately, the Name property of a control is a property of the .Net object that creates the window not of the control window itself. There is no way to get this value using the window handle - PInvoke or otherwise - from outside of the process.
You would need to do some variation on what Hawkeye appears to do. Attach to the process, examine the object hierarchy and/or inject code dynamically using the CLR Debugging API.
I have an MVVM application. In one of the ViewModels is the 'FindFilesCommand' which populates an ObservableCollection. I then implement a 'RemoveFilesCommand' in the same ViewModel. This command then brings up a window to get some more user input.
Where/what is the best way to do this whilst keeping with the MVVM paradigm? Somehow
doing:
new WhateverWindow( ).Show( )
in the ViewModel seems wrong.
Cheers,
Steve
I personally look at this scenario as one where the main window view model wants to surface a task for the end user to complete.
It should be responsible for creating the task, and initializing it. The view should be responsible for creating and showing the child window, and using the task as the newly instantiated window's view model.
The task can be canceled or committed. It raises a notification when it is completed.
The window uses the notification to close itself. The parent view model uses the notification to do additional work once the task has committed if there is followup work.
I believe this is as close to the natural/intuitive thing people do with their code-behind approach, but refactored to split the UI-independent concerns into a view model, without introducing additional conceptual overhead such as services etc.
I have an implementation of this for Silverlight. See http://www.nikhilk.net/ViewModel-Dialogs-Task-Pattern.aspx for more details... I'd love to hear comments/further suggestions on this.
In the Southridge realty example of Jaime Rodriguez and Karl Shifflet, they are creating the window in the viewmodel, more specifically in the execute part of a bound command:
protected void OnShowDetails ( object param )
{
// DetailsWindow window = new DetailsWindow();
ListingDetailsWindow window = new ListingDetailsWindow();
window.DataContext = new ListingDetailsViewModel ( param as Listing, this.CurrentProfile ) ;
ViewManager.Current.ShowWindow(window, true);
}
Here is the link:
http://blogs.msdn.com/jaimer/archive/2009/02/10/m-v-vm-training-day-sample-application-and-decks.aspx
I guess thats not of a big problem. After all, the Viewmodel acts as the 'glue' between the view and the business layer/data layer, so imho it's normal to be coupled to the View (UI)...
Onyx (http://www.codeplex.com/wpfonyx) will provide a fairly nice solution for this. As an example, look at the ICommonDialogProvider service, which can be used from a ViewModel like this:
ICommonFileDialogProvider provider = this.View.GetService<ICommonDialogProvider>();
IOpenFileDialog openDialog = provider.CreateOpenFileDialog();
// configure the IOpenFileDialog here... removed for brevity
openDialog.ShowDialog();
This is very similar to using the concrete OpenFileDialog, but is fully testable. The amount of decoupling you really need would be an implementation detail for you. For instance, in your case you may want a service that entirely hides the fact that you are using a dialog. Something along the lines of:
public interface IRemoveFiles
{
string[] GetFilesToRemove();
}
IRemoveFiles removeFiles = this.View.GetService<IRemoveFiles>();
string[] files = removeFiles.GetFilesToRemove();
You then have to ensure the View has an implementation for the IRemoveFiles service, for which there's several options available to you.
Onyx isn't ready for release yet, but the code is fully working and usable at the very least as a reference point. I hope to release stabilize the V1 interface very shortly, and will release as soon as we have decent documentation and samples.
I have run into this issue with MVVM as well. My first thought is to try to find a way to not use the dialog. Using WPF it is a lot easier to come up with a slicker way to do things than with a dialog.
When that is not possible, the best option seems to be to have the ViewModel call a Shared class to get the info from the user. The ViewModel should be completely unaware that a dialog is being shown.
So, as a simple example, if you needed the user to confirm a deletion, the ViewModel could call DialogHelper.ConfirmDeletion(), which would return a boolean of whether the user said yes or no. The actual showing of the dialog would be done in the Helper class.
For more advanced dialogs, returning lots of data, the helper method should return an object with all the info from the dialog in it.
I agree it is not the smoothest fit with the rest of MVVM, but I haven't found any better examples yet.
I'd have to say, Services are the way to go here.
The service interface provides a way of returning the data. Then the actual implementation of that service can show a dialog or whatever to get the information needed in the interface.
That way to test this you can mock the service interface in your tests, and the ViewModel is none the wiser. As far as the ViewModel is concerned, it asked a service for some information and it received what it needed.
What we are doing is somethng like that, what is described here:
http://www.codeproject.com/KB/WPF/DialogBehavior.aspx?msg=3439968#xx3439968xx
The ViewModel has a property that is called ConfirmDeletionViewModel. As soon as I set the Property the Behavior opens the dialog (modal or not) and uses the ConfirmDeletionViewModel. In addition I am passing a delegate that is executed when the user wants to close the dialog. This is basically a delegate that sets the ConfirmDeletionViewModel property to null.
For Dialogs of this sort. I define it as a nested class of the FindFilesCommand. If the basic dialog used among many commands I define it in a module accessible to those commands and have the command configure the dialog accordingly.
The command objects are enough to show how the dialog is interacting with the rest of the software. In my own software the Command objects reside in their own libraries so dialog are hidden from the rest of the system.
To do anything fancier is overkill in my opinion. In addition trying to keep it at the highest level often involving creating a lot of extra interfaces and registration methods. It is a lot of coding for little gain.
Like with any framework slavish devotion will lead you down some strange alleyways. You need to use judgment to see if there are other techniques to use when you get a bad code smell. Again in my opinion dialogs should be tightly bound and defined next to the command that use them. That way five years later I can come back to that section of the code and see everything that command is dealing with.
Again in the few instances that a dialog is useful to multiple commands I define it in a module common to all of them. However in my software maybe 1 out of 20 dialogs is like this. The main exception being the file open/save dialog. If a dialog is used by dozens of commands then I would go the full route of defining a interface, creating a form to implement that interface and registering that form.
If Localization for international use is important to your application you will need to make sure you account for that with this scheme as all the forms are not in one module.
I have a windows forms application with controls like textbox, combobox, datagridview etc.
These controls allow a user to use the clipboad, i.e. cut/copy and paste text. It is also possible to delete text (which is not related to the clipboard).
My application has a menubar with an Edit item containing Cut/Copy/Paste/Delete items, and a toolbar with these items as well. How can I enable/disable these items properly depending in the state of the control having the focus?
I am looking for a generic way, i.e. I look for an implementation I do once, and can reuse for the future independent of the controls my application will use.
There is no generic interface or set of methods for getting cut/copy/paste information from a windows forms control.
I suggest your best approach would be to create a wrapper class for each type of control. Then when you want to update the menu state you get the current control with focus and create the appropriate wrapper for it. Then you ask that wrapper for the state information you need. That way you only need to create a wrapper implementation for each type of control you use. Bit of a pain to start with but other time you only need to add the new controls you come across.
Clipboard information is much easier as you can ask the Clipboard singleton if it has data inside and what type it is. Then again you still need to ask the target control if it can accept that type of information so there is still extra work needs doing.
Create an array for each enable/disable group. Add the controls to the array (of course it has to be of the correct type such as Object or Any, etc. depends on the programming language you are using).
Then to enable, disable just loop through the array and invoke the enable/disable method or function for each control. Again, depending on the language you may need to cast back.