Is there any way to control the threshold of the flick action to on/off a toggle switch so that it doesn't mess with the pivot control's navigation?
Sorry, but I'm going to avoid you're question (I can't answer it anyway) and suggest you use a different approach.
You could (I assume) use a checkbox to just as easily provide the option to the person using the application. Afterall a toggle switch has the same functionality as a checkbox (specify/choose between two states) it just implements the interaction differently.
The toggle switch has not been designed/built (AFAIK) to support being used on top of something which also supports the same gesture.
As a general rule of usability, having controls on top of each other (or even next to each other) which support the same gesture is likely to cause problems for the user. Even if the problems are through accidentaly triggering the wrong gesture or expectations about how their gesture will be interpretted.
In summary: this is a really tricky problem to solve; I don't think you can with the controls as they are; and the problem goes away entirely if you use a different control for toggling anyway.
I've had the same problem with my codermate, we've been digging this for many hours and we finally reached the top of the hill and we came up with a solution.
This solution works for the bing map control:
on mouse enter: myMapControl.CaptureMouse();
on mouse leave: myMapControl.ReleaseMouseCapture();
And there you go, when you'll navigate inside the map the pivot won't do transition ;)
If you don't get the point, just poke me and I'm going to explain with real code (I'm quite busy right now).
Cheers
This solution posted recently seems to be working out for people for dealing with gesture conflicts on pano / pivot. You might like to check it out.
Preventing the Pivot or Panorama controls from scrolling
Set the IsHitTestVisible = false in your root pivot control
The solution to this is simple, and comes from my experience with Android and iPhone application development.
simply make sure you only tap into the OnMouseLeave event - not the OnChecked or the OnMouseClick as these will accidentally fire just by touching the toggle.
You want make sure that they were touching it when they let go of the screen, and this (unless you put the toggle on the edge of the screen will almost never be the case
Related
I'm here because my research and testing lead me nowhere.
I have made a little calendar application and now I want to improve the user interface with nice controls. I'm trying to achieve an interface where you can create an event by dragging over it (as you can do in Google agenda, in fact this a school project and I want to reproduce this week view).
For this purpose I have tried this approach:
For each cells of the area (a GridPane that contain VBoxes) I attach handlers that achieve that feature (setOnDragDetected, setOnMouseDragEntered and setOnMouseDragReleased). And it does the job well but in some case this don't work (if the mouse move over another event, which do no have the handlers, the drag feature stop).
As I saw this too heavy and subject to bogus (3 handlers x 7 columns x 48 rows = 1008 handlers !! ), I thought about other approach but I'm a beginner in javaFX and I don't know if there is other mechanism to perform this. (I thought about a transparent layout/pane that will handle this feature and act like a "touch screen" over my application but I did not found satisfying answers). Can someone enlighten me about this kind of problem ? For a good example of what I try to achieve take the behaviour of the Google agenda for an event creation with the mouse (I do not need to manage overlap of event). Thanks in advance !!
I post a picture of what the actual view look like.
So as Tomas Mikula suggest me I only attached my handlers to the GridPane (and not to each "cell" as I made previously): setOnDragDetected, setOnMouseDragOver, setOnMouseDragReleased and setOnMouseDragExited.
As the handlers are triggered on the GridPane, moving the mouse over other element doesn't stop the feature.
With this I reduced the number of handler, simplified the code (As I do not need to manage extra behaviours as mover over another child).
Thanks !
when i use pivot with in the panorama .pivot are used as a gallery view. i want to move pivot when i swipe it .but the problem is this because of both panorama and pivot are the same gesture event so both are they move .
i want swipe only my pivot view .
I would like some sample code or any other suggestion to do this.
so please give me a solution for doing this and
also give me a link where i easily understand this. Thanx in advance
You shouldn't have a Pivot in a Panorama control. End of discussion.
I believe it is achievable, because I've already solved similar issues with having WebBrowser control inside a custom horizontal-scrollable overview container like Pivot/Panorama, but believe me, it is NOT worth it. I've had to dig very deep into the visualstructure of the controls and attach my own manipulation-handlers to their viscera, manually choose which horiz/verti events to pass and which to cancel, and so on. This is not so easy, takes a lot of time, and doesn't guarantee that on the end you will have something behaving in a way you wanted to achieve in the first place. If you are not bound by some contract to preserve the shape of the UI, please, drop the idea and redesign your UI, just to save on your sanity and nerves.
But, if you are already insane or really want to dig where noone should, start on analysing your UI as a two rectangles: large pano and small pivo, and think which part should behave how on different possible touches/h-v swipes/h-v pans/pinches/so on. Write it down just to for reference, or soon you will probably start making small mistakes that will interfere with your understaning of the flow of the events.
I've checked the version I have, and "my" Panorama uses internally the UIElement.ManipulationXXXX events. In that case:
Display visualtrees of your UI and try attaching manipulation-events to every control. In those events, write/log which control's which handler was invoked. Then make some swipe/scroll on your APP and observe events. Analyze how they were bubbling and try cancelling (e.Handled=true) the manipulation-completed and/or manipulation-delta events somewhere between pivot and panorama. Your goal is to have the panorama see that e.Handled=true, while your pivot must see e.Handled=false. Your Pivot will probably see the event sooner than the Pano, so that point should be relatively easy.
If it fails to work, then you should check your version of the Pano, and check how it detects movements. If, for example, it uses the GestureListener - try the same trick with it. Etc.
And remember, you can always make your own horizontal-overwiew-container that will look like Pano, behave like Pano, and that will work with Pivo better - because it will be your code and you will tell it what and when to move. if you want to go this way, start on google and check all the preliminary Panorama previews that random people have published before that control was published by MS.
i'm talking about the "zoom" functionality in the universal access system preference panel. normally this is accomplished with command–option–8. then the zoom controls are command–option–+ (magnify) and command–option–- (minus/minify).
my most recent attempt involved sending the keypresses for the shortcuts as events. however this approach has serious bugs. on top of that, i don't know whether the user already has zoom enabled. i'm looking for something cleaner. like, the way you're supposed to do it.
of course there is always using applescript to open the system preferences pane and toggle the radio buttons, but that is not really what i would call "clean."
even if you don't know exactly how to accomplish what i'm asking, even some pointers as to where this kind of thing (programmatic toggling of os functionality) might be documented would be helpful. the language doesn't matter. thanks.
it's not quite what i wanted, but UAZoomEnabled() in /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/Headers/UniversalAccess.h lets me know whether zoom is currently enabled. then i know whether to send the command-option-8 keystrokes using CGEventCreateKeyboardEvent(), CGEventSetFlags() and CGEventPost(). in order to make sure that they're zoomed in 10 ticks, i zoom out 100 ticks, then zoom in 10 ticks.
source: http://lists.apple.com/archives/accessibility-dev/2011/Mar/msg00013.html
I want to put help buttons on all my windows, like this:
But when I put the help button in, the minimize/maximize buttons disappear. Does Windows forbid having the min/max buttons together with the help buttons? That would be disappointing because that would mean I could put the help button only on dialogs and not on frames.
If Windows does forbid this, it would be nice to see an official Microsoft document which talks about this policy.
It is not possible through setting windows styles. If you really wanted to you could set some hooks that would probably let you do what you want, but I would not recommend doing that. You can mimic the functionality of the help button by sending the WM_HELP message.
According to MSDN, the styles WS_MAXIMIZEBOX and WS_MINIMIZEBOX can not be combined with WS_EX_CONTEXTHELP.
Although it is true what daalbert says, with some effort it is indeed possible to draw just about anything properly on the window frame. Of course this is in no way "official" and the limitation that daalbert mentions still stands.
You can listen for WM_NCPAINT and draw the button yourself with the help of DrawFrameControl with DFC_BUTTON (which makes sure it will look like the real thing). Use WM_NCHITTEST and friends (WM_NC*BUTTON*) to find out whether the button you draw gets clicked.
So yes, it's technically possible to achieve what you want but usually not worth the extra effort.
Just wanted to have this on record for completeness.
We are designing the UI for a new line of business application. We have no real constraints and are free to design the UI as we see fit. The UI will be done in WPF and targeted for Windows 7, Vista, and XP Pro users.
Many dialog boxes contain OK and Cancel buttons in their lower right corner. Do you feel it is necessary to have this Cancel button or is the red X in the upper right corner sufficient? We are discussing this as we have been noticing more UIs that do not have cancel buttons, only the red X.
Not only you should add it but also make sure ESC is mapped to it.
Present the two designs to the customer - one with the "Cancel" button, the other without. See what their thoughts are.
Better still present them as partially working prototypes and watch them as they use the dialogs. If you ask them to perform a set of tasks and see if they have trouble when asked to cancel an operation.
Having said that, my preference is to include a "Cancel" button for the reasons others have mentioned:
Accessibility (especially as Esc should be mapped to it).
Convention (users will be expecting it).
Include the Cancel button. The red X is VERY hard to tab to. ;)
Include it. This is very common in other user interfaces. Give the user the choice of which to use; making it for them might make them annoyed with your interface.
Users are used to having standard GUI layouts - otherwise they get confused. They also have different ways of using the standard interface. Some people only use the X, some people only use Cancel. People usually ignore the one they're not using, but get confused if their one isn't present. So be safe and keep them both in - it should only be a one-liner function for Cancek anyway.
Include it!
From a user interface perspective, not including a cancel button might leave some users feeling like they have no choice, which is certainly not the case. Imagine the following simple decision scenario:
Warning: All of the files in the selected folder will be deleted. This action cannot be undone. Are you sure you would like to continue?
How silly would an interface be if the only option was Ok? Also, as noted above, on many platforms the Escape key is mapped to Cancel. It's also probably worthwhile setting a default button so that pressing the Enter/Space key doesn't inadvertently perform the action that cannot be undone.
+1 on including it. If you don't include it now and then need some different functionality on Cancel to Close later on, your users will already be used to automatically closing.
Just like we have 'ESC' button on keyboard, we need 'Cancel' in dialogs.
A matter of usability :-)
Include it. And please also make sure that you make sure that hitting the Escape key does the same thing as the Cancel button.
Also, just because you're designing from scratch, please don't throw out all convention. Take a look at MSFT's UX Guidelines for dialog boxes.
The red button is really for 'Close' rather than 'Cancel'. 'Cancel' canceling a running task. Use a 'Close' button instead. And yes include the 'Close' if there is a reason for people to click on it. The red button is quite difficult to click when you really want to close something quickly.
If you have that kind of freedom, consider eliminating dialog boxes from your application entirely, especially ones with the typical "OK | CANCEL" paradigm. Dialog boxes disrupt the flow of action and generally should only be used for things which absolutely require the program to interrupt the user.
You'll notice how disruptive they are in the web environment -- e.g., Stack Overflow only uses them when it needs to be able to OVERRIDE your action, e.g., when you navigate away from an unsubmitted answer.