Windows Forms and Navigation
I have researched and read many different web articles and books but found no relevant responses to my problem.
Currently I am programming Windows Forms in Visual Studio using VB 2010.
I am in the search of a solution to find if it is possible to communicate between Windows Forms and having them at a consistent size. Some forms need data and others don't need any.
Is there any solution to my problem or am I wasting my time?
To keep a form from being resized, you can set FormBorderStyle to a fixed style. Here's a similar question on MSDN forums where they recommend also disabling the maximize button by setting MaximizeBox to false on the form. Also, here's the MSDN reference where non-resizability is documented. So to achieve consistent size, you would set the initial sizes as you desire and then lock the forms down to prevent the users from resizing.
Also, it is possible to share data between forms, but how to do so is more of a chapter or two in a book than a Stack Overflow answer. Basically you would share your data objects between forms, which would display and update the objects. Search around for data binding. Microsoft has a brief introduction to the subject here.
Related
I come from mainly a web development background (ASP.NET, ASP.NET MVC, XHTML, CSS etc) but have been tasked with creating/designing a Silverlight application. The application is utilising Bing Maps control for Silverlight, this will be contained in a user control and will be the 'main' screen in the system.
There will be numerous other user controls on the form that will be used to choose/filter/sort/order the data on the map. I think of it like Visual Studio: the Bing Maps will be like the code editor window and the other controls will be like Solutions Explorer, Find Results etc. (although a lot less of them!)
I have read up and I'm comfortable with the data side (RIA-Services) of the application. I've (kinda) got my head around databinding and using a view model to present data and keep the code behind file lite.
What I do need some help on is UI design/navigation framework, specifically 2 aspects:
How do I best implement a fluid design so that the various user controls which filter the map data can be resized/pinned/unpinned (for example, like the Solution Explorer in VS)? I made a test using a Grid with a GridSplitter control, is this the best way? Would it be best to create a Grid/Gridsplitter with Navigation Frames inside the grid to load the content?
Since I have multiple user controls that basically use the same set of data, should I set the dataContext at the highest possible level (e.g. if using a grid with multiple frames, at the Grid level?).
Any help, tips, links etc. will be very much appreciated!
Microsoft has created a great community site for helping people get started with both design and Silverlight here: http://www.microsoft.com/design/toolbox/
It may be far more than what you need for your current project, but it definitely will give you the training you need to master Design with Silverlight.
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.
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
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I have an upcoming project which will have to be able to print simple reports from its data. It'll be WPF-based, and I'm wondering which way to go.
I know that WPF introduces its own printing technology (based on XPS) which looks quite easy to use. However, part of me wonders whether it would just be easier to use the ReportViewer control and embed it in a Windows Forms host control, since that will give users the ability to export to a variety of formats as well as print.
Has anyone had any experience with printing/reporting from WPF? Which direction would you recommend?
Limitations of RDL
I originally went with RDLC/ReportViewer for printing with WPF but found it very limiting. Some of the limitations I found were:
RDL could only create the most boring of reports
It was much more work to create a report using RDL than in straight WPF: The design tools are very primitive compared to Expression Blend and RDL deals only in tables
I didn't have the ability to use ControlTemplates, DataTemplates, Styles, etc
My report fields and columns could not effectively resize and rearrange based on data size
Graphics had to be imported as images - it could not be drawn or edited as vectors
Positioning of items required code-behind rather than data binding
Lack of transforms
Very primitive data binding
Printing directly from WPF is very easy
Because of these limitations I looked into creating reports using pure WPF and discovered it was really quite trivial. WPF allows you to implement your own DocumentPaginator subclass that can generate pages.
I developed a simple DocumentPaginator subclass that takes any Visual, analyzes the visual tree, and hides selected elements to create each page.
DocumentPaginator details
Here is what my DocumentPaginator subclass does during initialization (called when first PageCount is fetched, or during the first GetPage() call):
Scans the visual tree and makes a map of all scrolled panels inside ItemsControls
Starting with the outermost, makes items in the ItemsControls invisible last to first until the Visual fits on a single page without any need to scroll. If the outermost can't be reduced enough, reduces inner panels until it succeeds or has only one item at each level. Record the set of visible items as the first page.
Hide the lowest-level items that have already been shown on the first page, then make subsequent items visible until they no longer fit on the page. Record all but the last-added item as the second page.
Repeat the process for all pages, storing the results in a data structure.
My DocumentPaginator's GetPage method is as follows:
Look up the given page number in the data structure generated during initialization
Hide and show items in the visual tree as indicated in the data structure
Set PageNumber and NumberOfPages attached properties so report can display page numbering
Flush the Dispatcher (Dispatcher.BeginInvoke(DispatcherPriority.ApplicationIdle, new Action(() => {} ));) to get any background rendering tasks to complete
Create a Rectangle the size of the page whose VisualBrush is the visual being printed
Measure, Arrange, and UpdateLayout the rectangle, then return it
This turned out to be quite simple code, and allowed me to turn practically anything I could create with WPF into pages and print it.
Additional reporting support
Now that my paginator is working, I no longer have to worry very much about whether I am creating my WPF content for screen or paper. In fact, often UI that I build for data entry and editing also works very well for printing.
From there I added a simple toolbar and some code behind, resulting in a full-fledged reporting system built around WPF that was far more capable than RDL. My reporting code can export to files, print to the printer, cut/paste page images, and cut/paste data for Excel. I can also switch any of my UI to "print view" with a click of a checkbox to see what it will look like if printed. All this in just a few hundred lines of C# and XAML!
At this point I think the only feature RDL has that my reporting code doesn't have is the ability to generate a formatted Excel spreadsheet. I can see how this could be done but so far there has been no need - cutting and pasting the data alone has been enough.
From my experience my recommendation would be to write a paginator, then start using WPF itself to create your reports.
We had this same issue, and ended up using RDLC/ReportViewer for now. There's no native WPF reporting tool (that I know of) and RDLC is pretty simple to use, and is free. The runtime overhead for it is small (around 2Mb) but you must remember to distribute it as it isn't part of the .NET Framework.
Look at http://wpfreports.codeplex.com/
Take a look at PdfReports. It's a code first reporting engine, which is built on top of the iTextSharp and EPPlus libraries. It's compatible with both .NET 3.5+ Web and Windows applications.
How about Scryber? It allows PDF report templates to be defined using xml and bound to data within your application at run time. http://scryber.codeplex.com/
To elaborate on Ray Burns answer, if you are looking for an implementation example, see:
Custom Data Grid Document Paginator
Which is a great starting point.
I've reccently accomplished task of developing own reporting system, which basically consist on design enviroment and data Source manager. The first task was to develop WYSWIG-like design enviroment. I've done this using GDI+, without even bothering about printing, as it came out printing/generating print preview was easiest than i expected, In general it only takes to draw all things on screen to graphics object of printing event.
I think that in case of WPF it would be similar, so all you should worry about is to display you report on screen and printing would be only few lines of code.
Without getting into a whole political discussion about the future of WPF, the best option we found was to wrap the ReportViewer in a Windows Forms host control.
http://blog.pineywoodstech.com/index.php/2012/01/using-microsoft-reportviewer-with-wpf/
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. :)