My WPF application has a number of "pop-up" dialogs. There's no real need to show them on the task bar. Problem is that by turning off "ShowInTaskBar", they can be minimized to what I think is a somewhat unconventional representation (just above the taskbar), and as such can be inadvertently pushed down in z-order behind the "parent" or other windows, thus seemingly disappearing, but still deactivating the parent while open. There's no real need to minimize them anyway (user might as well just close/cancel), so I think it would make sense to disable minimize functionality for the "pop-up" windows. What would be the most straightforward way to do that (still allow resize/maximize/restore)? As best I recall, this was no big deal in "old-fashioned" Win32/MFC/Winforms - either a checkbox setting to disable the minimize box or a simple tweak of the system menu.
One of the favoured solutions I've seen in a related Q&A was to make the window "NoResize", but I want most of them resizeable. Another answer was to customize the title bar... is that really necessary? Would it be possible/feasible/advisable to access and tweak the system menu in WPF? Any "gotchas" in doing so?
Related
Short Version:
Is dynamically attaching/detaching WPF behaviors to/from a control at runtime a feasible practice in WPF or should I be looking for something different to solve my problem?
Long version:
I have a WPF control which represents a drawing surface. The user can use any one of a number of mouse "tools". One tool draws a line, one draws a polyline, one merely selects exiting items, etc. etc.
I handle this in code-behind for mouse events. Unfortunately no matter how much I try to generalize it, there is a lot of switching on tool type because the tools do very different things. Consequently, it is difficult to maintain. Adding new tools requires too many edits and testing. The handlers keep on growing larger.
I need to make this control relatively easy for the next developer on this project to understand it and to add a new tool without worrying about breaking anything.
It would seem that WPF behaviors would provide a natural way to simplify this and make it more modular; You set a particular "tool behavior" on the control and it handles the only mouse events it needs, altering the control properties as necessary. Different tool code is no longer mixed together.
But this approach differs from the way I've used WPF behaviors in the past. It would require me be able to dynamically attach/detach behaviors at run time with the push of a button. That is new to me. Usually I just have a simple behavior that I declare on a control once in XAML and it stays that way for the lifetime of the control. In fact, all of the WPF Behavior examples I've ever seen have been the sort where you set up the behavior one time in XAML and forget about it.
So I'm wondering has anyone out there done something like this? Is this an approach I should pursue or would it probably end up proving unwieldy? Or should I be looking for a different solution?
I come from a couple years' background in looped game programming. I'm very used to having a constant loop in my application which continually calls functions like Update and Draw, allowing me to perform actions like animations over time by incrementing values a bit each frame.
Now that I've got a job involving WPF, though, I find that I was too reliant on that system. Maybe I've got a limited feel for WPF, but it seems like everything is event-based. User clicks a button, you inform the code, the code manipulates values. The values change, code informs UI, UI updates layout. It works well for GUI-based application programming but I find that when I encounter situations which would be trivial in loop-based game programming I am stuck, unable to find a good way to implement simple behaviors.
At the risk of being too vague I'll provide my current problem as an example. After Windows 8 was unveiled I became very enamored with the idea of Semantic Zoom. After playing around with the Start Screen extensively I began working on a port of Semantic Zoom to WPF4.0 for Microsoft Surface (I work with the Surface at my job). I just want a trivial example of it which would allow me to use pinch gestures to navigate up and down in a stack of views.
After many hours spent trying to understand manipulation events (I won't go into that... bleh), I've finally got my view scaling based on a pinch gesture. If it scales past a certain point I jump back to the 'zoomed out' view. Pretty cool. But, the problem is, if the user doesn't complete the gesture and decides not to zoom out, I'm left with a smaller view. I want to animate the scale of the view to constantly 'rebound' from user pinching and restore to a scale of 1. I know if this were loop based I'd just Lerp toward 1 each frame. But since WPF is all based on events, I'm a little lost.
There's probably an answer to this specific problem using inertia or different manipulation events (and I'd be happy to hear it), but in addition I'd just like to know how I can re-orient my mindset to work more effectively in WPF. Is it just about knowing which events to subscribe to? Are there clever ways to use Animations to do what I want? Should I use threads to accomplish these kinds of tasks, or is that cheating (it seems unreliable, plus I'm shaky on threads in WPF)?
This issue is one of my biggest barriers to being effective in WPF, I think (well, this and not quite knowing MVVM yet, working on that). I'd like to see it torn down and be able to be effective in more than just loop-based games programming.
Although i'm pretty sure that most of what you want to do can be done in an event-based manner, you might want to take a look at the MSDN How to: Render on a Per Frame Interval Using CompositionTarget. Please also note the final section Per-Frame Animation: Bypass the Animation and Timing System in Property Animation Techniques Overview.
I find that the winform tool tips behave very erratically. They seem to randomly decide to do nothing, show up or disappear when I perform the same hovering/clicking/etc actions.
Is there some pattern that I'm missing? Do I just not understand the UI technique to bring up a tooltip? Is this a common problem? Do people actually expect tool tips to work this way?
Tooltips display automatically. That's a bit of a problem, the native Windows control has counter-measures in place to avoid displaying tips too often, potentially wearing out the user with info that has been shown frequently enough. Not exactly sure how that rate limiting is implemented, accumulated time is a factor (like 60 seconds), possibly also the number of times it was displayed.
The SDK docs do not document the implementation details. There is also no message available to forcibly reset the rate limiter. I do think that passing another control in the Show() method resets it.
All and all, it does mean that the ToolTip control is really only suitable to act as a traditional tool tip. It doesn't work well as a 'dynamic label'. which is your alternative, a Label control with BackColor = Info. Albeit it not quite the same because you cannot easily make it a top-level window.
What's the pros and cons for each of them?
It depends.
Use MDI (or tabbed MDI) if the user will generally focus on one document at once, and will want to see as much as possible.
Use owned non-modal forms (such as toolwindows) if the user will want to interact with many smaller forms at once.
You can also use both, a la Visual Studio.
It depends on many factor, the most important is how do you want your user to interact with your application (or how does he/she choose to do it).
For example the old internet browsing way was with a lot of different windows that would clutter up the taskbar. Now the new trend is with tabs and everyone is moving toward it.
On the contrary, MS Office is moving on the opposite direction. You used to have a lot of files opened in a single window but now they are cluttering up in the taskbar.
What is great about tabs is that you see them all at once and you can swap between then fast with hotkeys. Office however, was hiding those files in [menu bar]-[windows]-[file name]. Much of a pain to change between files.
MDI was first invented for two obsolete modes, which are "mosaic" where every window is arranged to have about the same height/width and "cascade". I never met a single user which liked those modes.
New trend is to have clipping windows, like Slaks said, such as in Visual Studio or most developpement environements where you need to see a lot of data at once. This method is the clear successor of the "mosaic" mode, but with the big advantage that whenever you resize or move a single window, all the other auto-rearrange.
+1 for #SLaks's answer.
It may be important for your users to have some dialog-style windows that are actually modeless if they will need to use the displayed data as part of another task.
For example, some of the dialogs in SQL Server Management Studio are actually modeless, even though they may have OK and Cancel buttons; the Database Properties window is such a beast.
A while ago I created a drag-over check box list which allows you to check many check boxes in a single gesture. Do you think it is viable and usable on the web where people might not know how to use it. The default behaviour still works for the individual check boxes.
1 - The idea
The idea is nice and can probably be used in professional applications where you have direct contact with users and can explain them how things work, but not necessarily on public websites where users don't want to RTFM and are just looking for familiar behaviours. Unless it was just a sample exercise or a control meant to be included it in a control pack, it violates the YAGNI principle ;)
2 - The implementation
You certainly noticed that the implementation is buggy (at least on IE7 and FF3.1B2). Sometimes, a gesture above all checkboxes will select all of them but one or two. Moving the mouse over the div's above or below the list will stop the drag (I know it's a "feature", but it's not very user friendly). I Checked the source code and to be honnest, while it looks pretty neat, I just didn't want to deal with it because it is plain javascript. Don't you know that...
3 - Possible improvements
...you can write less and do more with a javascript library, typically jQuery. I would completely rewrite this control as a jQuery plugin. It will provide you with a lot of tools to make your code much easier to write, maintain and extend. Just try it, you'll love it. This is from a technical point of view. From a user point of view, try to make you control as familiar as possible, like what Angela suggested, windows explorer : a nice selection rectangle, the ability to use shit + click, or something like that. Finally, remember that for many windows checklistbox users, "selected" and "checked" are two different things.
The demo definitely needs a few enhancements to make it even a little bit useful (although I am not sure if it would be enough):
Allow the dragging to start somewhere that is not a check box.
Allow selection by dragging over the labels as well.
This problem seems similar to the action of selecting multiple files in a file explorer like Windows Explorer. Maybe it can work like the action of selecting multiple files by dragging a rectangle shape around the items to be selected (select one corner, drag to the other corner)? This has the advantage of being similar to an interface element that people may already be familiar with.
For some reason I can't open your link (it says my ip address was blocked). But I think what you're looking for is what I already did in jquery, I uploaded a plugin which I basically ported from crossbrowser.com's dragcheck functionality, it was to be found at http://plugins.jquery.com/project/dragCheck but currently the jquery plugin site is being revamped and my plugin has disappeared. I'm trying to see if they're going to put it back up or if I have to create a new project again...
Anyways until we get that worked out you can see a demo here: http://jsbin.com/ibihi