I'm about to change my application to include tool tips for all buttons, combo boxes, etc. I was wondering if there are any recommendations on doing this.
For every control I'd like the tooltip to show the control's name in bold, followed by the description. I want to keep the style separated from the control, so I can change the tooltip style globally.
What I would like to have, unless there's a better suggestion, is two additional fields per button/combobox/etc: 1-ToolTipName and 2-ToolTipDesc, both containing a string. How can I accomplish this (and is it even possible?).
If you want this to be separate from the style of the controls, and you want to specify multiple "properties" per control, then an attached property may be an option.
I would recommend looking into Behaviors from the Blend SDK. They would make this fairly easy (especially if you're using blend), as it would allow you to make a tooltip behavior that you could just drag onto your controls.
I recommend using ToolTips with all toolbar and iconic controls.
You need to guard against having ToolTips in places where it is obvious what is happening in the UI, or the ToolTip hides information from the user forcing a mouse move.
The Popup control in WPF might also offer you the UI presentation you are looking to show additional information.
Super ToolTips, as in Microsoft Office Ribbon, also offer the ability to present additional information to the user.
There are recommendations for using ToolTips and InfoTips in the Win 7 User Experience Interaction Guidelines (aka UX Guide).
Related
I'm a WPF newbie and, unlike WinForms, I have a hard time to setup things in the design window.
My first obstacle is the Image control. After I drag it in the Design window it disappears and there's no way for me to edit its properties (like with the button control for example). The only way to make changes is via the XAML code which isn't very visual and intuitive.
Is there a way to keep editing the Image control in design mode? (example, move it around, select it to view its property panel, etc.)
All you should need to do is give the image control a fixed height and width and it should stay in the designer.
The best thing about the XAML is which separated from code for better re usability like asp.net. It's best you to learn different layouts such as grid, wrappanel, stackpanel etc. Then, you will feel the power of xaml. Else, you can choose the XAML building tools.
Link to refer
I'm new to wpf and have just been given a project to create a set of custom controls which will be used to make a previous windows forms application more manageable and current. However I cannot seem to find much info with regards to customising the built in Listbox, this would involve preferably replacing the scroll bar and the +/- buttons with custom images etc..
Just wondered if anyone knows how to get at these ?
Thanks in advance.
Check here for the default control template of the listbox.You can customize the scrollviewer there to do what you are looking for.Check the below article to get started
Using Templates to Customize WPF Controls
Learn about WPF styling and templating. Other than that, the question is too generic for SO. Read the article (and perhaps google some more articles on the topic), try to style the listbox and come back with specific issues. WPF is not easy to get into, but it is definitely worth the time.
I'm looking for a smooth method of managing toolbars (and menus) with mvvm in WPF.
Consider an UI with tabbed workspaces and heterogenous content (like Visual Studio). There the toolbars should be hidden or visible depending on the active tab. How would you design the view viewmodel for the toolbars?
I'd use a collection of toolbar-viewmodels and bind the ToolbarTray to it, but afaik that's not possible.
Any recommendations are apreciated.
Links to samples, best practice papers, etc. are welcome.
I had this same issue in one of my applications recently. I was using a Ribbon as my main toolbar, and based on what module was selected the buttons on the ribbon had to be hidden or shown. I came up with two different solutions... hopefully one will work for you.
The first solution would be to create a region in the shell of your application (it can be a Grid/Canvas/whatever) and dynamically load the desired toolbar into this region based on what tab the user clicks on. In other words, if you have 5 different tabs that require their own toolbar, create 5 UserControls that contain a toolbar and load the correct one into the region when the user clicks on the tab. Next you'll want to respond to the event of when the user clicks on a button on the toolbar. In my solution I used the Mediator approach to allow ViewModels to communicate with each other. It works, but I don't know that I would do it again that way... CAL is probably the better approach.
The other solution would be to create one toolbar with all of the required buttons and bind their visibility to the ViewModel. Based on the user's selection, set the visibility of the controls to whatever your requirements may be. Hopefully one of these solutions works for you.
by the way... what part of Germany are you from? I know a man with the last name of Stoll, so I wasn't sure if it was a common name or not...
I'm trying to decide whether I should create a simple StackPanel with Buttons on it, or whether I should use the WPF ToolBar class to contain these buttons (I am creating a simple toolbar).
What are the pros and cons to using WPF's built-in ToolBar control?
So far, these are the only advantages I have seen:
The ToolBars can collapse when necessary; additional items are available from a context drop down.
If the ToolBar is contained within a ToolBarTray, multiple ToolBars can be repositioned relative to each other.
Are the any other benefits to the WPF ToolBar? Neither of these apply to my simple toolbar.
Accessibility might be better with the WPF Toolbar, because it shows itself to Windows UI Automation as a toolbar with toolbar buttons, rather than some random controls. You never know who'll use your software.
Another very small advantage is that buttons in the ToolBar will be styled correctly, whereas the buttons in the StackPanel will take on their default look. Not insurmountable by any means, but a little annoyance none-the-less.
I would say use the Toolbar, because you never know when the next project will come along and need it. You also never know when this project may need it. I don't think there is any real drawback to using it over a StackPanel and the advantage you didn't mention is you'll have more experiance with a built in control for the next project.
On the other hand, I don't see any harm in doing it with the StackPanel, only that if you need to extend functionallity in the future, you'll have to do some rework.
I am very new to WPF, about 4 hours new. I am coming from ASP.net and Masterpages.
I was looking at examples of Control Template that can used to template a window so all windows look the same.
Other post
Can some direct me to an example of how it is accomplished or sample code from start to finish?
Second part:
Is the ControlTemplate the best way to go about building WPF windows client applications? What is best practices in architecting WPF windows applications.
Thanks
There really isn't a "best" way to architect WPF UIs. It all depends on the user experience your application will have.
If you want a very web-like experience you are probably better of using the pages constructs. Otherwise if you have windows, but want a common header, you may just want to make a control template for that. Maybe you need separate windows or maybe you just need to have a sub part of a grid panel change content depending on state... There are different ways to do things that are more or less suited to the type of client experience you want.
Although there are some best practices in relation to using MVC/MVVM design patterns, there isn't a "best" way to style and theme your controls. I don't consider WPF as friendly to newcomers as WinForms were, but at the same time it seems a lot more powerful in the long run. What might help you out are some basic levels of theming:
Styles: these are mainly aesthetic changes to the look and feel of basic controls and elements with some very basic support for triggering things like mouse cursor roll over. They are similar to CSS on webpages.
Control Templates: these are the more heavyweight versions of styles where you actually reconstitute a control so that, say a button can have a textbox inside of it. Where styles work on a logical level where something like a button is the most atomic element, control templates can drill down further into controls so that the border, background, text, etc of a button are seen as separate elements instead of one atomic part.
Data Templates: A more focused version of control templates meant to customize how data items in lists are drawn. If you have a bunch of pictures you don't want the file name to show up in the listbox, you'd rather have the image itself. A data template lets you accomplish this kind of thing.
So you have to ask yourself when you say, "Make all windows look the same," do you mean changes are merely aesthetic/looks (styles), customizing how a collection of items are displayed (data/item templates) or altogether changing how a standard control looks and behaves or making sure the layout of controls on a page are the same across multiple windows/pages (control templates)?
Finally, the "end to end" of the other post you linked to is pretty simple. You take the control template there, and under your tag you simply add Template={StaticResource MyTemplateName} and the template is applied. This article on MSDN is a decent intro to control templating.