Im trying to create a password page similar to the one that opens up when you click Lock+wallpaper in the settings of the Windows Phone.
How ever I could not find a keyboard with the done and cancel, a done and cancel buttons along with the numeric keyboard is visible in the lock+wallpaper page when you toggle the password switch.
How do I get one similar to that? As as alternative I tried to create done and cancel buttons, but the problem is, the keyboard overlaps these buttons where as in the lock+wallpaper page, the keyboard stays and does not overlap the button.This should mean that the buttons are present along with the keyboard right?
Could anyone help me on this one?
There is no InputScope which add "done" or "cancel" buttons to the SIP.
Instead you should look to use the ApplicationBar and add buttons for each of these functions. FOr doen you could use an image of a tick or a save icon for "done" and a cross for "cancel".
Be careful not to add a Cancel button if you really don't need one as the hardware back button would suffice instead.
Related
My Table control uses windowless checkboxes (because there can be an arbitrary number of checkboxes here). Right now, I use TrackMouseEvent(TME_LEAVE) and manually checking if the mouse is in the checkbox rect during a WM_LBUTTONUP. I have TODOs marked in my code for the edge cases that this causes, such as a missing WM_LBUTTONUP when the mouse has left the client area.
Now I notice today's The Old New Thing says buttons use mouse captures. This got me thinking, and after looking into it, mouse captures would fit what I need more appropriately; if my assumptions are correct it would handle the various edge cases I mentioned above and be more correct in general.
In particular, the assumptions I make are: I should abandon any capture-related operations on a WM_CAPTURECHANGED even if every other condition is met. I will get a WM_CAPTURECHANGED after a ReleaseCapture(). After a SetCapture(), I will always end with either a WM_LBUTTONUP or a WM_CAPTURECHANGED, whichever comes first.
I've read both MSDN and a few articles I've found by Googling "setcapture correct use"; I just want to make sure I've got the right idea and will be implementing this correctly. Do I?
on WM_LBUTTONDOWN
if the button is in a checkbox
SetCapture()
mark that we're in checkbox clicking mode
on WM_MOUSEMOVE
if we are in checkbox clicking mode
draw the checkbox in the pressed state
on WM_LBUTTONUP
if we are in checkbox clicking mode
leave checkbox clicking mode
THEN call ReleaseCapture(), so we can ignore its WM_CAPTURECHANGED
if the mouse was released in the same checkbox
toggle it
on WM_CAPTURECHANGED
if we are in checkbox clicking mode
abandon checkbox clicking mode and leave the checkbox untoggled, even if the mouse is hovering over the checkbox
Do I have the right idea here? And in particular, is my order of operations for WM_LBUTTONDOWN correct? Thanks.
What you have said is basically right, although a real checkbox tracks WM_MOUSEMOVE while in "clicking mode" and displays the checkbox in its original state if the mouse moves off of it. So to emulate that you should have:
on WM_MOUSEMOVE
if we are in checkbox clicking mode
if mouse is over the checkbox
draw the checkbox in the pressed (toggled) state
else
draw the checkbox in the original state
I've seen plenty of information about this topic, but not the answer to this question exactly. I have the opposite problem of most. I want to prevent the Enter button from clicking a button when the button has focus. And to do this, I don't want to simply disable the button from accepting an Enter button press, but rather I want to conditionally capture the Enter button press in a callback method. Right now, I have bound the following event to all widgets in my python program:
parent.Bind(wx.EVT_CHAR, self.CharInputCallback)
The EVT_CHAR event is actually thrown when the enter button is pressed and I'm able to get the callback in my callback method. My problem is that the enter button's functionality of virtually clicking a button still goes through, despite purposely not skipping the event (which would forward on the event). Since this is happening, and I'm sure my callback method is not forwarding the event along (I've tested this by capturing characters going to a text box) I suspect that the enter button throws an additional event that I'm not capturing. I've tried binding and capturing the additional following events to prevent the "virtual click" from the enter button:
parent.Bind(wx.EVT_TEXT_ENTER, self.CharInputCallback)
parent.Bind(wx.EVT_KEY_UP, self.CharInputCallback)
parent.Bind(wx.EVT_KEY_DOWN, self.CharInputCallback)
Yet when I press enter, the button in focus is still clicked. To summarize, is there an additional event being thrown when I press the enter button? If so, which event in particular is "virtually clicking" the button? Most forums I've found have discussed how to recognize when the enter button is pressed, but I want to recognize it and disable it's default action when a button is in focus.
I tried binding all those events to different handlers and I also bound EVT_BUTTON. It appears that EVT_BUTTON always fires BEFORE the key and char events do. If you don't want your button to be clicked, then you'll probably have to either disable it, use a different widget (maybe one of the generic buttons) or create your own. I would also ask on the wxPython mailing list to see if they have any suggestions.
The only way to order the events in wxPython that I'm aware of is to use wx.CallAfter or wx.CallLater. I'm not sure how you'd use that in this context though.
The event that causes enter to click a button is the key up event. My code for my callback was messed up slightly. Capturing the key up event and not skipping it prevent the enter button from clicking a button in focus. On Windows 7 anyways.
I'm writing a Silverlight+XNA game and when the user has something in their clipboard they can see less of the screen. I'd really like to be able to not show this clipbaord but I can't see any way (though it does seem to go away after some amount of time)
I've tried an empty string and Clipboard.SetText(null) but that throws an exception.
Unfortunately, there is no way to either clear the clipboard from code or influence the display of the SIP beyond setting an InputScope.
The best you can do for now is to update your design to allow for the amount of space which the SIP may use. :(
While more complicated, you could create your own text input keys as buttons, and instead of using a textbox, use buttons templated to look like textblocks, with background as you show above, and all... When the user taps the "button" that is a "textblock", you set a flag that says which textblock the keypad buttons send their numbers to.
Or, if the only spot you are sending inputs to (as it appears now that I look at your UI again), there is no need for the button template as the input space, or the flag. Just create buttons for user to tap for input, and send that input to the textblock that appears to be where your answer is. You could make the buttons whatever size you want, that way, as well, so you control how much of the screen is visible. Another thing you could do is make the buttons semi-transparent, so you could have even more background image showing.
Another thought - send the buttons all to the same event handler (except the backspace button), and have the code for that event handler look like this:
{
Button btn = sender as Button;
textblock.Text += btn.Content;
}
GUI: should a button represent the current state or the state to be achieved through clicking the button?
I've seen both and it sometimes misleads the user. what do you think?
The label on the button should reflect what the button does, i.e. it should describe the change the button makes.
For example, if you have a call logging system a button should say "Close Call" and the user can click it to close the call. The button should not have the label "Call is Open" and the user clicks to change the call status as that's very counter-intuitive, since the button is effectively doing the opposite to what it says on it.
In my opinion the label - and so the function - of a button should rarely, if ever, change. A button is supposed to be a like a physical button and they usually only do a single thing. (There are a few exceptions like play-pause on a media player where it's OK for the button label/icon to change, but at least this is copying a button from a real physical device.)
To carry on the example from above, I would say usually you would want two buttons, "Open Call" and "Close Call" and disable whichever one is not appropriate. Ideally you'd have a field elsewhere displaying the status of the call.
In summary, buttons are for doing things not for passing on information to the user.
The button should represent the action to be executed, not the state.
Some buttons are actions and are not ambiguous, like "Save", "Print" or "Enable user".
When a button represents a state that can be toggled, like Enable and Disable something, I do one of the following:
Change the button text, and make it always point to the state that will be achieved; (i.e. make the button point to actions, not states);
- Keep the button's text the same, but use one of those sticky buttons that will stay pressed, representing that the current state is "on" or "off". I prefer the former approach, though.
It should represent the action taken when clicking the button. States should always be presented by other means.
But I know what you mean. My car radio has buttons with text that shows the current state. It is really confusing.
This depends on the function which will be triggerd by the button click.
if the click changes the state of an entity i would suggest that the button represents the state the entity will enter after clicking the button
if the click triggers some kind of functionality the button should represent the function.
The appearance of the button is also a clue to its state. It should follow the standards of the environment if any exist (example, beveled edge / shadow appears on mouse click in Windows).
How can I dismiss dialog in Cocoa application when user presses Esc or Enter key? I have OK button, is it possible to make it default button?
If you present the alert panel using the NSAlert class or, NSRunAlertPanel family of functions, or the NSBeginAlertSheet family of functions, you will get support for default and cancel buttons automatically.
If you're presenting a sheet that needs OK/Cancel buttons, and you're not using any of the above, you should be able to assign your buttons appropriate keyboard equivalents in Interface Builder using the attributes inspector. (Just highlight the Key Equiv. area and press the key you want to be equivalent to pressing that button.)
If you're presenting a dialog that's not either an alert or a document/window-modal sheet — don't. :) Document-modal alerts aren't Mac-like, and shouldn't be used for things like preferences windows.
Just assign the "escapeKey" or "cancelKey" in the IB in the property "key equivalent" for the buttons you want and it will work fine. Also if you assign that keys the buttons gets a different highlighting.