Recently I started a project in WinForms. I'm coming from WPF background and I find some things new to me. For example every time I want to change a property of WinForms control I have to scroll up and down to find it.
It drives me mad. I would rather type first few letters of looked up property and edit it in a couple of seconds. Is there a way to speed up this annoying process?
There is no easy way to filter properties of control. I know how you feel, as I switch between WPF and WinForms from project to project. But you can always either Categorize them or sort them alphabetically... I am sure you'll get used to it eventually, but you have to understand though, Windows Forms are not as "innovative" as WPF is. Therefore you'll see some things are rather more "traditional" than WPF in WinForms! Sorry mate :)
There is a VS Extension called RapidDesign. It is a payed project but I think it's worth the price. It does exactly what you need and even more. (Note!!! I am not connected in anyway with the author/company that develops this product)
https://visualstudiogallery.msdn.microsoft.com/c820e3a0-add2-4a43-943c-029e296ab00d
You can download the extension directly from VisualStudio galery or you can install it from inside VS by going to Tools->Extensions And Updates...->Online->and search for RapidDesign
Related
I'm working on an existing WinForms application and I am having some weird issues with Infragistics controls in a WinForms app.
When I open a form or usercontrol in the project that has Infragistics controls on it, it looks like
this http://sdrv.ms/S7gvmS
I cannot access any of the controls in the design surface. Clicking does nothing. And, all of the controls appear in the lower area.
So I created a new test solution and dropped some Infragisstics controls on and got this http://sdrv.ms/SRdo2y
Anyone know what's going on?
When I've run in to similar issues before it's tended to be a license or version problem, the Infragistics libraries contain code stopping them working at design-time if a valid license isn't installed. To resolve this, I'd first recommend deleting all of the *.licx files in your solution. These can be easily corrupted especially if you're using source control and should be regenerated correctly when you go in at design time. If that fails, then I'd try uninstalling and reinstalling Infragistics ensuring the version installed matches those of your projects' reference.
P.S. Realise this is far too late to help the original poster but hopefully will help people coming across similar issues in the future.
This happens when Visual Studio cannot find the Design assembly. The components refer to a designer and if Visual Studio cannot find the designer, it makes the assumption that the object is a component instead of a control and places it in the system tray.
Typically, this indicates that something when wrong with your installation of the components, so the usual solution is to re-install.
When I first learned about Microsoft's then-new framework for developing desktop applications, WPF, I thought that one of the biggest benefits of it would be its efficiency. After all, I already know what the GUI controls and elements were that I wanted to use--I just have to slap them all on the page and then wire up all my bindings right, and I'll be done. After that, I learned about the MVVM pattern, which promised clean separation of concern within my WPF app.
I thought this was going to be great! I got into creating several different admin and data entry WPF apps with my team at work, and thus I began to crank out working software with robust but simple GUIs, right?
Not so fast, there, cowboy coder. My experience is that writing WPF is S-L-O-W.
Well, at least the way I do it. You see, after I have a picture of my GUI on a whiteboard, I code up the XAML with the controls that I want. This part, as expected, is fast--laying out the whole of a window is pretty quick. After that, its all the little stuff you want these elements to do takes awhile. I always seem to want to make this text bold in some cases; show a red error box in these other cases.
Then things unravel: this binding isn't working right over here--I have to write a converter and adjust the layout for the right values. Whoops, I forgot that extra NotifyPropertyChanged there. Oh, and I want to use a different template in this state vs. that, so I have to figure out what I can use to swap the templates in certain situation. This data is coming in asynchronously, so I need to make sure the right thing is happening on the right thread and that Property gets NotifyChanged as well. Crap, when I maximize my window, it doesn't stretch like I thought it would--must be because its container height isn't defined, but I don't want to define that, so I have to make it stretch in its parent. Oh, now I really want to make a user control out of this stuff over here, so I better implement some dependency properties...
On and on I go, spending hours and days on stuff that just feels so small and minor. I soon resort to cutting usability features and look-and-feel enhancements because this is taking just too darn long.
Does anyone have any tips or principles I need to try in order to write WPF efficiently?
A couple of things that have saved a lot of time for me:
Use DockPanel as your default panel for layout unless you have a good reason not to.
Keep a folder full of useful classes: a ViewModelBase class that implements INotifyPropertyChanged, a RelayCommand class, etc. There's no need to get fancy and try to make this a separate assembly that you build into your project; just write reasonably good implementations and copy/paste them into your new projects.
Get Resharper and use it. Use templates for creating dependency properties, properties that do change notification, and commands.
Find or build a good library for asynchronous task management.
I find that even for very simple applications I get more done faster with WPF than I did with Windows Forms. For applications that aren't very simple, there's absolutely no comparison.
For the most part, WPF applications are a lot of work to develop because it's harder to make the case for cutting out UI features. You can't just say, "Oh, that's not possible," because it probably is possible (whatever "it" is).
Write your own library, or find an existing one.
WPF is great, but out of the box it is missing some things that would make coding faster. I got tired of writing the same things repeatedly, so I ended up creating my own library full of things like converters, visual tree helpers, attached properties, custom controls, etc., and since then, my development time has sped up considerably.
In addition to my own library, I've also started using Microsoft's Prism and Galasoft's MVVM Light Toolkit. Both contain useful objects that I use all the time and are better than what I could code on my own. (Most used are NotificationObject from Prism, RelayCommand from MVVM Light Toolkit, and EventAggregator or Messenger from either one depending on the project, etc.)
Another thing I've done to speed up coding time is to take advantage of Visual Studio's macros. For example, to create a property with Change notification, I write the private property, hit Ctrl+E, Ctrl+R which generates the public version, then run a macro which automatically sets up the PropertyChanged notification in the setter method.
I almost never change the setter methods from the default macro'd one, and instead use the PropertyChanged event to handle any changes that should occur on the setter. This not only makes it easier to track application flow, but also greatly reduces the time I used to waste browsing through my public properties to alter a setter method.
I believe the right answer isn't for WPF at all, but it can fit what you're looking for.
Most of the times, when you want to leverage a new technology there's a time while you're not efficient, productive and your solutions aren't that impressive, innovative or just doesn't look like others.
What will give you more efficiency is working with WPF itself.
It's more about project management topics than programming. After finishing some project, your team and you should go to some room and discuss:
Success stories.
Problems during development.
Pros and cons.
Fails in the application architecture.
Communication problems within the team and customer.
... and so on.
If everyone shares their knowledge, project manager or team leader does a good job documenting each project story, finally everyone will have a "know-how".
In addition, it's important that you won't need to reinvent the wheel for every new project: if some pattern worked fine, do the same way next time, even if it's not the best way of doing it. And try to enhance it, if possible.
Design patterns, technologies, paradigms, languages, companies, colleagues and nothing are a silver bullet: Microsoft said WPF is a step-forward in Windows client developments, and it is that: a more modern approach to provide shinny user interfaces and a programming paradigm that fits nowadays' desired approaches, easing the relation between coders and designers, as WPF has XAML, which allows not only separation of concerns, but separation of professionals by area (designers, UI programmers, business programmers, ...).
Finally, as I said above, WPF won't be your silver bullet: learn from your own success and read a lot, see sample applications, download open source solutions, listen your colleagues, drink a coffee and, after all, after some headaches, some day in the near future, you'll leverage these technologies (and many others).
EDIT
I'd like to add that a good way of using the know-how is creating a Visual Studio guidance pack, so you can automate a lot of tasks like creating managers, views, models and other things just in the way your team would do by hand.
For example, you can create a guidance pack for a WPF CRM-like application and you can automate module creation. When you want to add a new module, guidance pack starts a process which adds all the necessary classes to start development this new module, and it can create a sample form already associated with a navigation manager, controller or whatever (it's just an example).
Guidance pack and T4 would be both good tools for automating tedious or repetitive tasks in everyday's tasks:
http://msdn.microsoft.com/en-us/library/ff631854.aspx
http://msdn.microsoft.com/en-us/library/bb126445.aspx
I have been using WPF since 2008 and can honestly say to do it right and clean does take more time than the same thing in WinForms would take to develop. I have written a lot more WPF than Winforms. That being said - if I need a simple internal utility - it is ALWAYS Winforms. If I have something forward facing to a client - it is always WPF. Why? Winforms are cheap and dirty and you get a lot for free. What you don't get is the fit and polish that WPF can provide. The flexibility with WPF does come at a cost - but in the longer run it's worth it for public facing software.
Yes WPF is a hurdle but it also has rewards. You are on the right track with a design pattern such as MVVM. Sounds like you have not even gotten to the "rewards" of dependency properties or event bubbling. But the control over the UI is great. Almost everything is a content control. In forms I was always writing custom controls to get the UI I wanted. In WFP I have never had to write a custom control for UI and doubt I ever will. The syntax is new but it is compact - I rewrote a Form app in WPF and the WPF has 1/3 the lines and more features. Read a whole book on WPF just to get grounded - I like PRO WPF in C# 2010. You could also say LINQ is complex but man does it do a lot in just a few key strokes. WPF is not something you just pick up on the fly as you next application.
I'm new to the Windows world, and I think I'm getting lost in the weeds on a problem. I'd love some advice from people with experience with C++/CLI and WPF and XAML.
I have some win32 code, and I need to run a WPF GUI. I found this MS walkthrough sample, which uses C++/CLI. I adapted it to my purposes, and it works great.
Next, I wanted to rip out the programmatic WPF stuff and use XAML instead. This is so I can hand off the XAML to a designer person and take myself out of the UI design loop, where I most assuredly don't belong. After reading the "WPF Interoperation Projects" section of WPF and Win32 Interoperation on MSDN, I decided to go with the XamlReader::Load option and load uncompiled XAML at runtime. My XAML markup is a Canvas UIElement which I programmatically add as a child of my root Grid C++/CLI element. This works great.
Now I want to add event handler to controls in the XAML. This is where I have started to run into trouble. I'm sure that my general ignorance of the Windows world is 95% of what's killing me here.
I started with Rob Relyea's page outlining the various XAML-and-event-handler options.
I decided to try compiling the XAML as a C# DLL. It's basically the same XAML as what I used in the runtime Load case. I instantiate the object and programmatically add as it as a child, just like before. But ... I get nothing but a black window. No exceptions get thrown either. I'm baffled.
My question is, am I even headed down the right path? The page on XAML-and-event-handlers says you can use event handlers defined in uncompiled XAML in .Net Framework 4. Should I bite the bullet and just go to VS 2010 (I'm presently on VS 2008) so I can use .Net Framework 4 and just stick with uncompiled XAML? Are there any gotchas with doing things that way?
Or, if you do think the compiled C# DLL is a reasonable path, do you have any ideas on how I can debug the problems I'm having?
Or, is there a better and completely different approach?
Thanks in advance for your advice.
Polly
I think the right answer for this depends on some issues that only you can decide, but I'll start with the assumption that your C++ code base is big and complex enough that it is worth preserving.
Beyond that the next decision point is do you have UI (perhaps GDI) code in the C++ your preserving or only non-UI code. If you are attempting to preserve only non-UI code then I would consider pushing more UI responsibilty into C#. Perhaps you go so far as to build your views, event handlers, and maybe even view models in C#. This will enable you to take better advantage of the VS tooling.
If you've got extensive UI code in C++ to preserve then your current path makes a more sense. I don't think it will be impossible, but you'll have quite a challenge ahead of you. The key example here is Visual Studio 2010. It is the premiere example of a mixed application and has GDI and WPF side by side unlike any other app I've ever seen or heard of. There is a series of blog posts that I found pretty interesting that describe some aspects of what the Visual Studio team did to achieve this integration at The Visual Studio Blog.
I also came across this video Henry Sowizral on Refacing C++ with WPF in Expression Design that I have not seen myself, but discusses putting a WPF UI on top of an existing MFC C++ app.
Good luck.
I don't have any specific advice on the first part of your question other than to say that putting more responsibility in C# would allow you to build a small stub app if necessary which could go a long way toward diagnosing problems.
Thanks to everyone for the responses. On the matter of getting stuck on the C# DLL, I found this C++/CLI sample: http://msdn.microsoft.com/en-us/library/aa970266.aspx. Using that, I found my error, and was able to load the WPF without problems.
However, the whole motivation for loading the C# DLL was that I had understood that that was the way to attach event handlers programmatically. Following AresAvatar's suggestion, I found that I could use FindName to attach the handlers -- both within the C# DLL, but it also worked with my original loose-XAML approach. So, I didn't need the C# DLL after all!
It's all working nicely now. Again, thanks for all of your help and suggestions.
I want to create an automated UI test that will test my syncfusion grid. My problem is that the recorder can't recognize this control (or any syncfusion control). I've searched a lot in the internet but I couldn't find any extension so the recorder will recognize my controls (I'm using WinForms, not WPF!), or at least a way to extend the recorder abilities so syncfusion's controls will be recognized somehow.
Is there any easy way to extend the recorder? Or is there any extension available?
Or maybe can I get the grid object from the WinClient that the recorder generates?
Thanks!
Start your program. Run the Spy++ utility. Type Ctrl+F to start the finder tool and drag the bulls-eye onto your form. Ok, Synchronize and have a look-see at the windows that are visible in the tree. If you see regular Windows Forms controls, like a Button or a Label, but not any of the SyncFusion controls then you've probably found the source of the problem.
Component vendors that try to improve .NET controls typically do so by creating 'window-less' controls. They are not really controls, they don't derive from the Control class and don't have a Handle property. They use the surface of the parent to draw themselves, making them look just like controls. The .NET ToolStripItem classes do this. And this is also the approach WPF uses.
The big advantage is that they render quickly and support all kinds of effects that regular controls can't support, like transparency, rotation and anti-aliased window edges. The big disadvantage is that the kind of tool that you are using suddenly gets noddy and can't find the control back. Because they work by finding the Windows window back on your form, there is no window for them.
This is a hard problem to solve, the 'control' exists only in memory and there's no good way for a tool to find it back. Using Accessibility is about the only other way for such a tool to find a control that I can think of. Which would have to be implemented by the control vendor first, a somewhat obscure feature that gets easily overlooked. You really do need the help of the vendor to find a workaround for this. Shouldn't be a problem, that's why you paid them the big money.
This is Rajadurai from Syncfusion. Thank you for your interest in Syncfusion Products. To make UI Test Automation recognize Syncfusion grids(WinForms), some internal support need to be provided in grid whose implementation is in progress and about to be completed. Please submit an incident through Direct-Trac for any further related inquiries in the following link.
http://www.syncfusion.com/Account/Logon?ReturnUrl=%2fsupport%2fdirecttrac
You can also contact us through support#syncfusion.com. We are happy to assist you.
Regards,
Rajadurai
Just recently, I learned about using MVVM to decouple GUIs from the underlying model. I ended up learning as much as I could to convert my current application over to MVVM, and was largely successful. Now I need to figure out how to actually take a GUI generated in Blend and use it in place of my current GUI, which was designed in Visual Studio. I can't find any resources on the web for making this as seamless as possible. I'd like to know what you all have done and have had work for you.
My ultimate solution would be something that would allow me to, at runtime, select a skin from a menu and immediately have the GUI change from the current one to another that the user selects. Can anyone point me to posts that explain how to do this?
My current goal is less ambitious -- I'd like to be able to add my new Blend GUI into my Visual Studio project and when I compile, have the new Blend GUI appear. If I want to go back to the old GUI, I would have to recompile. For now, that is okay.
I've got my Blend project added to my VS2008 solution, and have set it to be the startup application. That works fine -- if I run the app, my new GUI appears instead of the old one. The problem now is that it needs DLLs that are actually in a different folder -- the bin\Debug folder of the original startup application. Am I supposed to leave my original GUI as the startup application, and then have its App codebehind load the other GUI?
Also, each of the respective GUIs needs a reference to the ViewModel. In my case, I was just instantiating it in my current GUI class. For the Blend GUI, I instantiated one there as well, since only one of the GUIs will be active. Is this where something like the Unity framework should be used?
Sorry about all of the possibly-incoherent questions, but I'm not quite sure how I should proceed from here. I feel like I'm so close to proving to myself that MVVM is the way to go from a GUI standpoint (I'm already sold on the testability bit).
All the examples I've seen dynamically switch GUI appearance by using some form of ResourceDictionary swapping. A few links:
Load XAML Resource Dictionaries at Runtime
WPF change theme/style at runtime
Hope that helps.
I found a mistake, where in one part of my code I was using the wrong property to get at the currently-running assembly's path. I am now using
System.Reflection.Assembly.GetExecutingAssembly().Location
Although this does work, it only works if I copy the exe from the Blend project's bin\Debug folder into my main application's bin\Debug folder. I will have to live with this by using a post-build event, I guess. I was so spoiled for the past several months working with .NET, where I didn't have to do this (like before in C++) because all of the referenced assemblies get automatically copied over. If I want to debug any code-behind, I also have to set the starting executable in the Blend project's settings, which is inconvenient as well, especially when working on different computers where the paths aren't set up the same. Any suggestions here would also be appreciated!