I have this: var display = await DisplayAlert("My title", "My question text?", "Yes", "No");
If I click outside the Display, the default return will be false
Is there anyway to get another return if I click outside the display? Like null
DisplayAlert is a simple Yes or No tool. Pressing YES means take an action, pressing NO (or maybe outside of the Alert box as a Cancel move) means do not take an action, from the user point of view. (You can't even press outside the box in IOS).
From technical point of view, when the confirmation box pops you can no longer interact with any other objects in the screen besides that confirmation box, until it is closed. And there are no overloads for the method that catches NOT ANSWERED situation. Creating such an overload is out of the scope and I think it is unnecessary.
Simply use DisplayActionSheet if you need more interaction.
Related
this is probably dead easy but I can't find a solution. I made a dialogue system and have a UI-button to click when the player should display a sentence next.
The issue is that the button is only triggered onMouseclick and I would like to change the input button to Enter. Would anyone know how to go about this?
If you need to determine if the button is selected first or not, I suggest you take a look at this page: https://docs.unity3d.com/ScriptReference/UI.Selectable.IsHighlighted.html
If you don't want pressing the button to have any functionality, you just wouldn't link it to any functions.
Working code might look something like this:
public class selectableExample : Selectable{
BaseEventData _event;
void Update()
{
if (IsHighlighted(_event) == true)
{
if (Input.GetKeyDown("enter")){
print("replace me with working function"); // whatever you want to have happen on button press
}
}
}
}
You simply attach this to your button and it should respond the same as being pressed. To be honest, it hardly seems like you actually need a button at all for this though, you'd probably be fine with just a label telling the player to press "Enter" and then simply checking for that input.
You can use the Event Trigger component to use one of the many event types. Select Submit (this is set to enter and return in the input settings at edit>project settings>input by default).
Don't set anything in the OnClick event.
The only thing needed now is to actively highlight the button from somewhere with ReferenceToButton.Select().
I have a semi-transparent form (using AlphaBlend) that acts as an overlay. For the user to still be able to interact with the window below I have set WS_EX_NOACTIVATE on my form so all right and left clicks go through to the other window.
However I have a few clickable labels on my form. Clicking those and performing the appropriate action works fine since despite the WS_EX_NOACTIVATE flag the OnClick methods are called, but the click will (obviousely) also propagate to the other window, which I do not want in this case.
So, does anyone know how to "stop" the click being sent through to the window below in case I already handled it in my form ? Basically I would like being able to chose whether the click "belongs to me" and does not get propagated or whether the window below mine receives it.
As Rob explained, WS_EX_NOACTIVATE is not relevant here. Most likely you used WS_EX_TRANSPARENT and that made your window transparent to mouse clicks.
To get finer grained control of mouse click transparency, handle the WM_NCHITTEST message in your top level window. Return HTTRANSPARENT for regions that you want to be "click through". Otherwise return, for example, HTCLIENT.
Wm_ex_NoActivate should be irrelevant here. That just controls whether your window receives the input focus. Indeed, if you start with a scratch program and do nothing but change the extended window style, you'll see that when you click within the bounds of that program's window, the clicks are handled in the usual way, except that the window is never activated; programs behind that window do not receive any click events.
Therefore, to make your label controls eat click events instead of forwarding them to the windows behind them, you need to find out what you did to make them start forwarding those messages and simply stop doing that, whatever that is.
I've a dialog based Win32-app on Win7-Aero which only displays a dialog. The dialog should have a title bar. I don't want that the user can move the dialog on the screen.
I've no luck so far... handling WM_NCHITTEST, WM_SYSCOMMAND... setting SWP_NOMOVE.
What is the best way to achieve NoMove? I think DWM changes something on Win7.
You could do this by handling WM_WINDOWPOSCHANGING and when you see an attempted move, change the coordinates back to where they should be. E.g.
switch (uMsg)
{
case WM_WINDOWPOSCHANGING:
if (!(reinterpret_cast<LPWINDOWPOS>(lParam)->flags & SWP_NOMOVE))
{
reinterpret_cast<LPWINDOWPOS>(lParam)->x = g_iMyXCoord;
reinterpret_cast<LPWINDOWPOS>(lParam)->y = g_iMyYCoord;
}
return 0;
}
You would probably need to add some intelligence to this to distinguish between attempted moves by the user, and moves that your own program makes (or that the system makes if necessary - e.g. if a monitor disappears for instance).
Even though you say it doesn't work, I would have thought you could also do this by trapping WM_NCHITTEST and returning HTBORDER whenever HTCAPTION would have been returned - however you would have to do this by sub-classing the window rather than in the DialogProc (because you would need to call the default handler first and then process/change the return value). Same for WM_SYSCOMMAND (to catch moves the user attempts via the system menu).
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).