I was putting finishing touches on a new WPF/Silverlight custom control and decided that this time I would go with .NET 3.5 SP1 requirement (for WPF version). So, I decided to go with recommended new way of setting toolbox icon/image with ThumbnailAttribute. After spending some time on it I couldn't make it work and turned for help to Google.
Surprisingly a search for ThumbnailAttribute produces basically no results on Google. There's MSDN documentation of the class, a few irrelevant hits and 2 articles (one of which is mine) showing how to do it the old way and just mentioning that there's a new way with ThumbnailAttribute.
So, my question is this: does anybody use ThumbnailAttribute to set toolbox images for WPF/Silverlight controls? Does it work?
Update: Microsoft recommends using specifically named icon files rather than ThumbnailAttribute as per Michael S. Scherotter (see comment below).
You want to create a design-time assembly for your class. You do this to assign design-time attributes to a class that don't take up space in the assembly. This is important for Silverlight apps which should have smaller assemblyies for faster downloading.
See this article for an description of the design-time assembly.
For Icons, in the design-time assembly add 12x12 and 24x24 PNG icons as embedded resources with these names:
Namespace.ControlName.12x12.png
Namespace.ControlName.24x24.png
Related
Im making an wpf application and i need to generate reports and then to print them. I am using CodeReason.Reports library but it is very dificult to me to design the reports with out a designer.
Any one knows if there exist any Flow Document designer, or if there is any way to design it from blend?
Thanks
I don't know the library you are talking about, but I used WPF for creating some report, let's say a minimal report engine, so I think I can give some suggestion to you.
First, learn XAML. Visual studio has a good designer, but I use it just to see what's happening: writing XAML with the good Visual Studio intellisense is much more productive. I can't suggest how to operate with your lib, but with my strategy the document pages are wired by the engine in code, content are produced by user controls: they just live very well in VS designer. I also used an MVVM library to develop in a an code free view way.
So what I learn in y WPF experience: it is a great and powerful environment, you can present thing the way you want, but don't look for a cutting edge designer. The WPF designer is XAML, mastering it is necessary.
I used flow documents in a regex tool I created. I ended up creating a programmatic wrapper over the flow document library which once done was easy to use because it had my target look and feel.
No, AFAIK there is no design tool for flow documents nor does Blend support it. Create a document and provide a wrapper which speaks to that design is your best option if you use flow documents.
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'm looking for a vendor for a grid control for WPF that works nicely together with MVVM; and that allows grouping by dragging the columns. I've been looking around and at first sight it seems that my choice at the moment would be Telerik.
If there are people that have experience with one or more vendors, I would like to hear your opinion.
Thanks!
L
did you try the dataGrid included in WPF .net 4.0?
as MS finally added one, you could first try to use it and see if it suits your needs.
except of course if you are limited (having to use .net prior to v4.0 for instance...)
see there for more info:
http://msdn.microsoft.com/en-en/library/system.windows.controls.datagrid%28VS.95%29.aspx
The Xceed DataGrid for WPF does support MVVM. You can refer to their product page for more information here and you can also refer to their extensive and online documentation here.
After installation, you are also given many sample applications that are installed on your machine. You can find them here:
C:\Xceed Samples\Xceed DataGrid for WPF Professional Edition vX.X
A while ago, I posted a question regarding switching between a Blend-authored GUI and a Visual Studio-authored one. I got it to work okay by adding my Blend project to my VS2008 project and then changing the Startup Application and recompiling. This would result in two applications that had completely different GUIs, yet used the exact same ViewModel and Model code. I was pretty happy with that.
Now that I've learned about the Laurent Bugnion's MVVM Light Toolkit, I would really like to leverage his efforts to make this process of supporting multiple GUIs for the same backend code possible. The question is, does the toolkit facilate this, or am I stuck doing it my previous way?
I've watched his video from MIX10 and have read some of the articles about it online. However, I've yet to see something that indicates that there is a clean way to allow a user to either dynamically switch GUIs on the fly by loading a different DLL. There are MVVM templates for VS2008 and Blend 3, but am I supposed to create both types of projects for my application and then reference specific files from my VS2008 solution?
UPDATE
I re-read some information on Laurent's site, and seemed to have forgotten that the whole point of the template was to allow the same solution to be opened in VS2008 and Blend. So anyhow, with this new perspective it looks like the templates are actually intended to use a single GUI, most likely designed entirely in Blend (with the convenience of debugging through VS2008), and then be able to use two different ViewModels -- one for design-time, and one for runtime.
So it seems to me like the answer to my question is that I want to use a combination of my previous solution, along with the MVVM Light Toolkit. The former will allow me to make multiple, distinct GUIs around my core code, while the latter will make designing fancy GUIs in Blend easier with the usage of a design-time ViewModel. Can anyone comment on this?
I checked your previous question and this one, and I had never really heard about switching projects to work in Blend and in Studio, and end up with two different UIs. I think this was not the intent of MSFT when they built Blend. Instead, the possibility to open the exact same project and code files in both IDEs (and all the discussions I had with the various teams at MSFT) hints that the intent was in fact to have one application only which can be edited in both environments.
I think that in the end, the goal is to have a variety of tools that you can use to edit your UI - XAML, Visual Studio designer, Blend. Depending on your role in the project (developer, designer, integrator) and depending on your ability with the tools, you can choose one or the other.
This doesn't mean that we never switch templates! Depending on the kind of application (for example between a SL4 desktop application or a WinPhone7 application), we use the same ViewModel (and below) code, but slap a different UI altogether on the files. I demoed how to do that in this video:
http://channel9.msdn.com/posts/kreekman/TechDays-2010-Understanding-the-Model-View-ViewModel-pattern/
This is the same talk I gave at MIX but extended by 15 minutes where I show how to reuse the ViewModel and model files, but use a completely different UI for WinPhone7.
Another application is switching templates when a window is resized (used very often in WPF, but also applicable to Silverlight) in order to show less details or a different layout for different screen sizes.
I hope that this reply doesn't confuse you :) and in fact, I'd love to hear your comments on that before we continue the discussion.
Cheers,
Laurent
I think MEFedMVVM would be a good candidate for this. It is simple and you can combine it with other frameworks.
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 :-)