I'm in the process of writing a set of documents to help other developers in our office localize various components of a large application. I'm using a tool called Globalizer.NET to do the donkey work and it's very good as it even lets you localize the size and position properties of controls to allow for the likely changes in length of text strings once translated. However, it occurred to me that in some cases I might need to re-size the entire form a bit, but Globalizer doesn't let you do this, and I cannot see any other way of doing this. I have even tried manually adding an entry in the language specific resource file for the form size but it doesn't make any difference.
Ultimately, once it has become a little more established, we'd consider moving to WPF which I understand makes this easier, but for now we can't for a number of reasons.
Is there any way at all to localize this property of a winform? I am beginning to suspect not, but figured I'd ask in case someone else has come up with a workaround.
Don't worry - about a moment after posting this I had a bit of a Homer moment and realised I was trying to use the wrong property - ClientSize is a perfectly localizable property!
Thanks for reading.
Steve
Related
Well, I'm a newbie. I'd like to write an app in WPF. The main purpouse will be in drawing predefined elements/objects. Input from user is mostly realized by text boxes - numbers. But I'd like to add some kind of user input into drawing itself too + zooming and moving. Next functionality will be in saving the draw for later loading and another editing (printing maybe, but it's far far away).
I can imagine something like this:
due to some user interaction I'd prefere to use of InkCanvas
i want to define my own elements/objects with some properties. But where it will be define? Some external file maybe?
the save file will be composed of XAML code only
I will study this more lately, but I want to know if my thoughts are in the right way.
Are these points correct, or completely bullshit? :)
Thanks, and sorry for English...
I don't know if this is exactly what are you looking for, but here a little list of advice to help you on reaching your goal:
First of all, if you are crating an application, you should see this before. It explain the Model-View-ViewModel pattern, which is essential when you are creating something on WPF. This can help you abount your 2nd point.
Regarding your save file, i don't know exactly what you have in mind, but it depends on what do you want to save exactly. If you want, InkCanvas have the option to export directly the work in a bitmap . If you need to store some setting, depending on your need you can work with Settings or Resources
InkCanvas seems the appropriate tool for your need. Of course you will have to build your app around this control
I'm using the WPFToolkit RichTextBox in order to allow the user to view and edit text.
One of the things I need to support is the coloring of specific words as they are being typed, as well as when loading them from an pre-existing source.
For example if the user type the word - "Hello" it should be colored in blue.
Since I'm using MVVM I would like to avoid code behind as much as possible.
So far I've been trying handling this in the ViewModel with a custom TextFormatter however it helped only when the I update the source property and when I updated the RichTextBox directly it didn't color anything as the TextFormatter's SetText wasn't even called. Only SetText was called.
I hope you guys could help me out.
Thanks!
In the end I used the solution I found in here -
http://blogs.microsoft.co.il/blogs/tamir/archive/2006/12/14/RichTextBox-syntax-highlighting.aspx
It's doing its job, but it sometimes has minor hiccups when typing fast or when holding the backspace.
So for now its good enough since my RichTextBox is relatively small.
Though if anyone knows how to fix the hiccups, it would be really great!
EDIT: I found a way to really improve the hiccups. I used a DispatcherTimer and started it on the TextChanged event, that way only after a second/half a second, it would start the coloring logic. So far it works much faster, and I didn't notice any problems when typing quickly. So for my needs of a single row with colored words, it seems like it worked!
I just found Xaml Styler and I'd like to give it a try. Can anyone share some experiences with this tool? Is it worth the try? Are there any drawbacks when using it in large teams?
Thanks!
I'm using it daily, and it's quite awesome. It's more than definitively worth a try, and I don't see any drawbacks.
Just make sure that everybody have the same settings, if you choose to divert from the default ones.
I absolutely love the XAML Styler. Though source control issues do happen. If you beautify a XAML document that can mean 1800 lines change if it was really ugly when you did it. If members of your team also have it checked out then they have to resolve 1800 lines of changes. So I recommend you be careful about when and which files you do this with in a team environment.
Trick: It beautifies the XAML page when that is the current tab and you hit [SAVE].
If you don't want the page beautified, then switch to a different tab and choose [SAVE ALL].
This is what I do when other team members have the same document checked out. If I'm the only one, then I do a normal save to make it nice, then check it in ASAP.
After using this tool for some time, I have to say that I don't recommend it because:
Attribute Definition Order Matters, and therefore the behavior might be altered when a XAML page is "beautified". The tool does not offer a setting to exclude attribute sorting. Here's more information on this problem: Silverlight XAML Attribute Definition Order Matters
Source control conflicts are actually a pain and there's no way to "force" the team members to use the tool. It would be nice for example, that the XAML files where styled when saving the file.
Hope it helps someone!
I started using this tool recently-- and I'm a big fan-- but one thing was really annoying me: it automatically formats everything whenever you hit save. I like using the green edit markup next to the line numbers in VS to keep track of where I am in big files. Whenever I hit save, it turns the whole file green.
So protip, if you turn off "Format XAML on save" in Tools>Options>XAML Styler, you can just right click on a file and hit format when you don't need your edit markup anymore.
Okay,...I've recently inherited a downright shocking Silverlight 4 application and the Xaml is worse than you could possibly imagine. I'm going through a clean up operation and I'm looking to save time if I can.
One of my problems is that I've got a bajillion Button controls; some have a Style set and some don't. I need a quick and easy way (if one exists) to remove all of the Style attributes from any Button (or whatever) that has one set. Is this possible?
I have access to VS2010, KaXaml, XamlPad and Blend 4.
Thanks in advance..
Forgot about this question so in response to Robert Claypool's question,...No, not really.
What I actually did was remove all the styles and go through the big daunting errors list one by one. I tried a little find and replace magic first but that failed miserably no matter how clever my Regex got.
No choice here but to just hand-ball it I'm afraid.
I have created a class that is simply THIS
Class UserControlBase
Inherits UserControl
End Class
Then I changed the Inherits clause in each of my UserControls designer file to
Inherits UserControlBase
I know that generally you shouldn't manually mod the designer file. But in cases like this what else can you do? Is this OK? Is there a best practice I don't know about? Is there some other way to accomplish the same end (extending UserControl) ?
I have not had issue changing the Inherits line, adding Namespacing, or adding Imports/Using statements. If you need to do any of these 3, you won't find many other ways to handle these requirements.
I change them all the time in my C# projects... often it's the easiest way to duplicate something that you've done once in the designer to a similar form and you want to do the same thing in a different form. Visual Studio is perfectly capable of reading in your changes and incorporating it into the designer. I really don't know why there is a comment saying not to edit it. My advice would be just make sure you use source control, go ahead and edit it, test it well, and if it works, great, if not you can always back out your edits.
No. It's never a good idea to modify a file that's generated.
The Designer files are pretty simple code; the only thing that you'll typically find in there to complicate matters (but only slightly) is BeginInit/EndInit calls at the top and bottom of the file--between those the code is pretty forgiving.
*That said, do not put any code in there that will only execute at Runtime. Any runtime-dependant code will fail at design-time, so trying to open your control in Design view will blow chunks. It used to give you the Red Screen of Darn, but I'm not sure what effect the IDE has notwadays--but if things blow up and the usual tricks fail to remedy them then try removing your customized sections.
Further on that note (not to scare you, but rather to hopefully head off some of the difficulties we had) the means of determining if your code is executing in Runtime or Designtime often fail if your code is not part of the currently built solution/project.
So to bring it all home, simple UI layout/winforms modifications are perfectly fine to do by hand in the designer code. Databinding and external dependencies (with the exception of calling third party control libraries) should be cautiously approached.