For some reason Visual Studio winforms designer time to time applies dull changes to form designer files and respective resx.
Most annoying so far:
changes to order of controls declarations/initialization
changes to some control sizes (most notably menu items widths)
changes to serialized images embedded into resources (...wait, what???)
Those changes doesn't affect form/user control functionality or it look, but they create lot of noise in source control, making merges almost impossible, or require error prone manual fixing to eliminate all changes that actually change noting, just until next change to designer.
Any ideas how to prevent studio from it?
Please try to have your control locked using the right button, then select "Lock controls" on your Form/UserControl.
Unfortunately, there is no way to separate "useful" changes in generated code from "pollution" that come from a control designer bug or internal working.
If the lock control feature does not work for whatever reasons, there is not much that we can do, except those horrible hacks:
Once your form is created and finished, move your generated code (InitializeComponent method and declarations) out of the .designer.cs. Visual Studio will not touch it anymore. The drawback is that you will no longer have visual support.
Having the .designer.cs file flagged as read only will prevent Visual Studio attempting to change it. It might cause Visual Studio control designer hiccups sometimes, but it will leave your .designer.cs intact.
There is another way that consist in not using the designer at all. This leads to a new way to embrace winforms programming, because you will provide the code to initialize controls with their properties and events.
It is not as huge and ugly as it seems to be: using reusable patterns and OO features could be very pleasant, and some well aligned methods calls are better that some horrible code hidden in a .designer.cs file.
Of course there will be no visual support, but you can cheat it by adding your control to an empty container in design mode to see how it looks like.
As far as I understand, you have edited .designer.cs file. From one point it is OK, I guess we all do that. However, there is clearly notification there 'file is auto-generated, do not change it'. So Visual Studio puts you a warning that if you edit it things may not go always well. It is like that by design. And while those auto-changes might not make trouble to your app, they do sometimes (e.g. setting width and height to the control that should change its width and height contextually, and that is always necessary if you have multi-language app).
So if you don't like garbage, you don't use designer, because it creates garbage, that's how it works. Or you start with it and at some point decide to never open it again and then do your cleaning.
Or you go WPF, it meets your requirements, and it is about time to make WinForms legacy, at some point support for it will surely end.
Related
Hi this might seem like a dumb question, but I was looking for a little feedback. I am designer working with a development team on a WPF application. We installed Expression Blend 4. I new to WPF/Silverlight, but I have jumped right in and I think it's great.
However, I did notice that xaml code that can get generated when using Expression Blend can sometimes be overly obnoxious. For example, I created a Control Template for a button with Blend and the markup was like 100 lines of code. Then I created my own control template that was only 20 lines or so and it did exactly the same thing. I did the same thing for a listview and wow, that amount of code that was generated for a ListView template was RIDICULOUS. So again, I created my own styles and templates and the result was A LOT less xaml code.
The app we are creating is going to be pretty big I guess, so my question is, is it that much of a concern for performance if I were to simply create all design/interface elements using blend GUI, even though the generated code can be a lot more extensive? I can see how using Blend tools for design can make things a lot easier, but just like when designing websites, I have never used design view in Dreamweaver because the code that gets generated is pure crap.
Any insight would be greatly appreciated.
Thanks a lot
Personally i would only use any designer for drafting and real-time display of the visual representation of my hand-written code. The generated code may not be horrible but once you need to go into it to do something manually you will have a hard time finding everything you need if you did not write it yourself. Also Blend slices things up quite a lot (create resource & reference it) while i like to nest things in place if they are only used once (i do not know if the code generator could be adjusted in that regard).
It should not be performace concern that the templates are big, if you just copy the default ones used they are quite huge themselves and it's not really an issue.
I'm guessing the control template you generated for the button didn't actually do the exact same thing as the default one which you copied in Blend. You may think it did, but I'm guessing it was missing something. For example, did your template handle all 9 visual states that are used by a button? If you had only 20 lines of XAML, probably not. And yes, the ListView control template is quite large because it's quite a complicated control under the covers.
In general, I wouldn't worry about generating large control templates. It's going to happen. The runtime handles this quite well, in general. Unlike Dreamweaver, Blend generally gives you pretty good code. Performance only becomes an issue if you misuse resource dictionaries by doing something ill-advised such as setting the build action to embedded resource in visual studio. (I believe this creates a loose XAML file which must be parsed and compiled at runtime instead of compile time.)
The key to maintaining your sanity is organization. Just like with a website, you need to come up with an organization scheme for how you're going to store your control templates.
I'm using the Visual Studio 2010 WPF designer to lay out a window, and the Reset Layout function is proving very useful whenever I move something around as the designer defaults to specifying widths, heights, and massive margins to get it into whichever exact position I have dropped it in, making the automatic layout features of WPF almost useless unless I get rid of those specifications.
At the moment I am accessing this function by right-clicking on the control in question, selecting Reset Layout from the context menu, and then selecting All. As I'm not using any of the other options in here, and I'm using it a lot, I wanted a hotkey, but that's where I'm getting stuck.
I've looked in the Options->Keyboard window, but if there's a command for it there then I can't find it because it's not named unambiguously enough (I've searched for commands including Layout, and commands including Reset, and there's a few that -might- be it, but probably aren't right). I have searched the internet for any hint of a list of designer hotkeys, but what I have found is very limited, and never covered adding new ones.
Does anyone know what this command is called so that I can bind it using the Visual Studio keyboard hotkeys menu? Is it even available?
Alternatively, maybe I'm going about this wrong - is there a way of clearing the layout of a control when moving it around or dropping one from the toolbar that's quicker than putting it roughly where you want and using Reset Layout via the context menu? I could just edit the XAML directly, but I have a lot of controls to move around and I find it slower than using the menu.
Thanks
You can record a temporary macro, then view the code in the Macros IDE, which gives you the command names.
Unfortunately, these commands don't seem to be part of the VS command framework because they are not recorded. They must be internal to the XAML designer.
I've been developing with WPF for many months now. It's a great framework and I'm able to do fancy, elegant stuff that would have been a lot more difficult with WinForms.
However, I do have the feeling that for normal "line of business" type of applications without any special UI requirements, it still takes me longer to code the UI in XAML than it did to drag-and-drop it in WinForms.
For example, in WinForms, I would just drop an additional label and an additional textbox on the form and arrange everything (using the helper lines) until it looks nice. In WPF, I'd start by factoring out the properties of the existing label and textbox into a style, so I can reuse them; think about the most suitable layout element, maybe refactor some dockpanels/stackpanels into a grid (or vice versa); try different values for the margins etc. Although I have a lot of experience in WPF, it still takes a long time.
I know that I could just forget about "clean XAML" and use the GUI designer in Visual Studio 2008 (which just absolutely positions everything inside a huge grid), but I fear that I would lose a lot of the advantages that XAML offers by doing that.
Have you experienced something similar? If yes, what did you do to speed up everyday WPF development?
What I do to speed up everyday WPF development:
Ignore look and feel for as long as I can. Ideally, tweaking alignments and margins and defining styles is the very last thing I do.
Use the DockPanel before using a Grid, and a Grid before using a StackPanel.
When using the Grid, star-size everything. I'll come back and fix this later, but during prototyping, having a clear idea of how many rows and columns the Grid actually has is enormously helpful.
Prototype in Kaxaml, finish in Expression Blend, test in Visual Studio. Figuring out a methodology for this has taken a lot of time, and it's still very much a work in progress. But Kaxaml is great for quickly seeing how a XAML prototype will behave, and Blend is great for working out the visuals and encapsulating things into user controls and styles.
When using Blend, don't create layouts in the artboard, create them in the object outline. When I'm first developing a WPF UI, the hierarchy of objects is a hundred times more important than how it looks on the screen. I'm still learning to do this, and it seems possible that once I get good enough at it I won't need to prototype in Kaxaml anymore.
Work on the smallest thing possible. This requires a lot of discipline. I've got a nice big complex XAML file, and I decide that I need to edit the template of a control The first thing to do is to create a tiny XAML file with that control in it, and edit the control template there. The temptation to work like this in situ is strong, as editing the control template is only a right-click away. Don't do it.
Don't even think about whether or not I should develop a view model for my tiny little one-off application. Yes, I should.
Learn Blend. Really, really learn it. Learn what all of the tiny icons that surround the selected object mean, and pay attention to them. (Here's a shortcut: I didn't set margins on that thing, but Blend did. That's the answer to maybe 30% of my "what the hell is Blend doing now?" questions.) Use the Blend UI even if I know it would be faster to edit the XAML by hand. This is again a matter of discipline, resisting the temptation to get it done now so that I can improve my ability to get more of it done later.
That's kinda like saying "Sliced apples are easy to make, but apple pie tastes better. How can I make apple pie as easily as I can slice apples?" Well, you can make it easier by using pre-made pie crusts or buying pre-sliced apples, but it will never be quite as easy, because lets face it, you're making something that's a lot more complex and potentially tastier.
It sounds like making styles holds you up. You could get off to a much quicker start if you just imported the same styles with every project. Usually I fly right along once I have all of my styles made.
Otherwise, the only way to make it as easy as the drag-and-drop WinForms designer is to use the drag-and-drop WPF designer.
I've been using WPF for a couple of years now - for optimal speed, I disable the design-view, use snippets, intellisense intensively (and of course ReSharper).
And then I make things simple - I have descided to use standard layout for almost everything - ie. main-screen bit -> DockPanel, ToolBar docked top -> snippet.
Popup screen -> DockPanel, ToolBar docked top, custom Persistent section docked bottom (Save and Cancel buttons) - properties of the viewmodel -> UserControl with grid, labels and properties.
For styling - first do that when I have at least 3 screens for each type - create resource dictionaries for each type. Define common stylings - Header textblock etc. Import ResourceDictionary in each screen and apply styles.
Apply coloring, margins, padding etc. in App.Xaml with non-keyed styles.
I can't think of a faster way. At least for me, I don't really need to think while doing it this way (so, I can use my brainpower later for the complex stuff) - and it gives a consistent "LOB-look" that is relatively easy to style, theme and change later on. It's basically a matter of typing.
My biggest challenge at the moment is that I'm constantly thinking of ways that the UI could be composed dynamically with data templates, which can often get in the way of simpler solutions when the extra flexibility is not required. Other than that, I've become faster now that I'm getting used to the different containers and their quirks. It's such a dramatically different technology that it's going to take time before I develop the appropriate mental tool set for my day-to-day UI tasks, especially since I still need to use WinForms regularly. I figure it's just a matter of time, however, before I have standard patterns in mind that I can deploy quickly and easily.
The advice about VS2010 is very good; its visual designer is actually useful, compared to VS2008's XAML designer, which was less than useless.
Microsoft's PR machine pushes the "Model-View-ViewModel" pattern extensively for line-of-business apps, to the point where they actually recommend things that can waste your time.
Do not spend hours trying to shoe-horn everything into XAML, unless your company or client has procedures which require it. If you can code it faster in VB or C#, and the code is still maintainable, testable, and readable, do it.
Do not become an MVVM purist; not even Microsoft has figured out the appropriate balance for this pattern, and even with the Silverlight 4 stuff, they haven't come up with a good set of development tools or best practices for the pattern, even though it's now been almost five years since it was first proposed; there are still very valid reasons to abandon ICommand and INotifyPropertyChanged in favor of just calling a method on your ViewModel from the code-behind. Also, no non-Microsoft WPF/Silverlight expert I've listened to in the past few months has failed to say, "I'm not sure about MVVM yet, I'm not a purist."
Find a balance and use XAML for what works for you, and C# or VB for what works for you. MS devs on their blogs are fond of calling XAML "markup", and C# or VB is "code, unfortunately". Well, if you're typing it in or laying it out, it's all code, and the truth is that all that XAML gets interpreted and then turned into C# or VB in files you can't see or readily edit, before it's compiled down. (For example, Application.g.vb is generated from Application.xaml as a partial class.)
There are XAML constructs like animations and storyboards which take many lines to lay out in XAML, but in the procedural languages might only take one or two lines of code and actually be easier to read, especially if the animation responds to an event under only certain conditions. Do what works best.
Also, if you're coding along and keep hitting run-time exceptions which make no sense, take a step back, find an alternate answer that gets you functioning, and implement it. Most XAML errors can't be caught by Intellisense or the compiler. It's possible to bang your head for weeks against a XAML problem, that can be coded in C# or VB with early binding in a comparatively much shorter time.
In short, relax and code to your own best practices, using the VS2010 tools, and you should be able to pick up speed.
If you use VS2010 I think the visual designer for the XAML is better now and I think brings the development time more in line with classic winforms development.
If you still need to target .NET 3.5 you can by setting the solution to compile to 3.5 instead of 4.0. This might be a good option for you if you aren't using VS2010 yet.
I feel your pain... Everytime we add a new field into the database, another TextBox/ComboBox has to be made on the form. I've found that using Expression Blend allows me to be much quicker at laying out the form. The downside is that using Blend tends to create more xaml than writing it by hand, so I usually end up cleaning up the xaml a bit.
In the end, Blend is a much better designer than Visual Studio (2010 included), so it's much quicker to do your design work in Blend, and development work in VS. (just my two cents)
Would it be practical to create WPF applications without ever touching Visual Studio (or any other IDEs)? As in, coding and compiling completely within Vim and the command-line? What resources would you recommend for someone trying to do so?
It would be possible, since basically WPF is based on XAML - a variant of XML - and C# or VB.NET or another .NET language as its backend language.
The question really is whether that's practical and if it makes sense - I highly doubt it. WPF is all about visual design, e.g. totally without a visual designer (either the built-in one in Visual Studio, preferably the 2010 version; or some other visual designer), it seems a bit silly to want to program WPF....
As for resources - well, a least a text editor is a must, then definitely a few good books on WPF, and you could leverage the C# or VB.NET compiler that comes with the .NET framework.
I have found myself writing XAML in Notepad on a number of occasions where I needed to create a quick UI but couldn't load an IDE. It is really quite trivial, and almost - but not quite - as fast as using an IDE. The main advantages of an IDE such as Blend or VS.NET are in quickly getting things like colors and animations to be "just right."
Another occasion when I frequently write XAML or C# in a text editor is here on Stack Overflow. I only fire up Visual Studio when I need to test something out.
My main recommendations for creating WPF applications without an IDE are:
First you should make proper use of WPF's layout system, using appropriate panels and "Auto" sizing wherever possible. For example, if you want a stack of buttons with some space between them, create a <StackPanel>, and on each button add Margin="4" or whatever. This is good design anyway. Most beginning WPF programmers treat it like WinForms with no layout capability, which is a shame. WPF has a very powerful layout engine and it should be used. If it is, there will never be any need for graph paper or measurements. In addition, your UI will automatically adjust its layout if you change font sizes or objects are larger than expected.
Second you should use msbuild for your project unless it is ultra-simple. msbuild is installed along with NET Framework so it is always available. The file format is very easy to edit with a text editor, and it is much better than a batch file with the appropriate "csc" command because it allows you to use code-behind and is less error-prone when adding new source files.
Third keep a PowerShell command line window open separate from your editor, with a command that runs "msbuild" and then executes your application. To run your app, then just Alt-Tab to this window and hit uparrow, Enter. Some text editors have the ability to execute user-defined commands directly from within the editor and see the output, in which case this second window is not necessary.
Fourth keep a copy of cordbg or mdbg handy. Although an IDE is the ideal place to do your debugging, any debugger is better than none at all. You will find your problems much faster if you stop at breakpoints and examine variables than if you just keep editing code and re-running.
Fifth, use "ColorPad" or a similar application to select your colors for use. Just guessing and entering your best guess in hexadecimal just doesn't work very well.
For resources, I recommend you get the book "WPF Unleashed" and work through the examples. I would also read a lot of other people's XAML, such as can be found on CodePlex.
Possible, Yes. Practical No.
For production work, I would consider Microsoft Expression Blend 3. Then copy the XAML and paste it into the editor of your choice and compile from the command line.
You could download KAXAML . It's a free, lightweight editor. I found it good for learning about XAML and seeing how minor changes and tweaks can impact on an overall design.
XAML is plain old text so find a free editor (KAXAML), use it, and if you must, paste into your editor.
If you really want to go down this route, I'd recommend getting some graph (squared) paper and a sharp pencil.
Draw out your designs on that, read off the positions and type them into your editor of choice.
One benefit of this is that you're going to have a paper prototype to show people ;)
As James Keesey points out in his comment on marc_s's answer, your edit-compile-test cycle is going to be painful.
It's definitely possible. I'd say it's not practical, though.
To be honest, I do professional WPF development and I do it with the visual designer closed. I'm much more comfortable editing the XAML by hand, just like I write HTML. However, the benefits of an IDE go far beyond the visual designer. There's IntelliSense, debugging and a whole host of other invaluable features.
Really, I must question your motives. What are you trying to gain? Visual Studio Express editions fully support WPF development, so it can't, or shouldn't, be a cost issue.
The newest version (3.0) now supports the wpf template.
Just download it from: https://dotnet.microsoft.com/
Just type in console:
dotnet new wpf -o wpfHello
cd wpfHello
code .
Greetings :-)
Visual Studio 2008 does a much better job of detecting and adding controls from projects to the toolbox for use in the forms designer. If you have an assembly with a UserControl- or DataSet-derived type, then it will automatically detect and add that control to the toolbox for designing forms. This is slightly better than the old system in 2005 that made you manually add controls and would occasionally forget them, etc.
However, on the legacy, monolithic project I am working on (now upgraded to vs2008) this means many controls that I don't want and don't need (and a redesign would not be warranted against so much legacy code :( ). I imagine that if I made certain types internal or private, then they wouldn't show up. However, I need many of those to remain public, but not show up in the toolbox. Furthermore, with so many controls getting added to the toolbox, opening the winforms designer slows significantly.
Is there an attribute or other mechanism that prevents toolbox appearance (that wouldn't otherwise affect functionality) ?
Would filtering using such a mechanism improve performance while still autodetecting new types that SHOULD be in the toolbox? (I know you can disable the autodetect, but its nice to have in many cases)
Have others encountered this irritation on large solutions (with many csproj/vbproj files)?
Edit: Thanks everyone! I knew it had to be simple (and was likely an attribute) but that fills the gap. Nice to know that I was in good company in not knowing about ToolBoxItem(false).
The following attribute should hide it from the toolbox:
[ToolboxItem(false)]
If you apply it to all the types you don't want to show, it will still show any new ones you create without this attribute. Note, you may have to manually remove the items to start with.
This blog post shows some other attributes you may want to use.
Go through the toolbox and for each custom control that you see that you want to hide, add the following attribute above the class:
[ToolboxItem(false)]
Of course, this is a compiled attribute and will affect everyone using the code, so I only recommend doing this for controls that don't make drag-drop sense. Otherwise, you will probably make someone that loves that control very very angry. :)