In my webapp, I have a send dialogue box which sends the data to a selected email address. The issue is that the dialog box disappears after few seconds of clicking send button which makes the user click send button multiple times as a result of which same mail is sent multiple times.
What I think is that this can be a function of the speed of the DB (and probably the size of the data).
If it takes several second to receive confirmation then you must reflect that in the UI, by putting up a "wait" cursor, disabling the "Send" button, possibly dimming the dialog box etc. There's nothing wrong with taking a few seconds as long as you make sure the user is aware and cannot click Send a second time
Even if you expect the operation to be nearly instantaneous in most cases, you STILL must reflect the possibility of a delay in the UI. That's just a fundamental UI design principle.
Related
Using redux-toolkit, rxjs, redux-observable
I want to add a 1-second delay between the same action if they are within a short period of time.
A naive example:
if you click a button that displays a pop-up 10 times really quickly, then I want to only show all ten pop-ups but only one pop-up for a second before showing the next pop-up.
let's say the button dispatches an action. is there a way to observe the stream of actions coming in and add a delay?
I have made a postback button that appears when a user messages the Facebook page a specific phrase, with 3 options to choose from as a trivia competition:
Option 1
Option 2
Option 3
Users can click an option, they will receive a follow-up message if it's right or wrong. If user clicks the right one, another postback button with question appears to continue, however if user clicks wrong one, just text gets sent that they have lost.
However, they still have the previous postback message that if they lose, they can choose the correct option to continue.
Is there a way to implement that the postback button be overwritten with new postback button, or if already selected an option not able to choose a different one.
You can use Floating Buttons ( Quick Reply ) for this purpose. When any user press floating buttons, the buttons disappear.
You can attach quick reply with your generic template card too.
See more about Quick Replies here: https://developers.facebook.com/docs/messenger-platform/send-messages/quick-replies/
I need to allow or stop an event from happening, based on a given condition such as a pop up box with options YES, NO and CANCEL.
I need to notify the user saying that there are unsaved data and if the user wishes to SAVE it, IGNORE it or CANCEL his current action(event such as Selection-change or Click).
I tried to use createInterceptor() function. But could not achieve the functionality.
Can anybody give me some suggestions with example? Basically I want to know how to stop an event.
Thanks..
Edited
I like the idea of using beforeXXX events. But I am still facing problems. As I mentioned, I need to ask the user if he wishes to save the unsaved data, which is a popup message box (With options YES, NO and CANCEL) that runs asynchronously. So by the time I get a reply, the event will have happened.
For ex. lets imagine a situation where, there is a page that displays a list of records in a grid with a pagination toolbar attached to it on the bottom(with a page size of 10 and total number pages is 10. So totally 100 records) on the left hand side. If you select a record in the list, the details are shown in a detail view on the right hand side.
Now,
I select third record in the list and make some changes to it in the detail view(form).
Without saving the record, I click on next page button on the Pagination toolbar.
It will show a confirm box from the beforeXXX event of Pagination toolbar, but the event will have happened anyway.
Here if the user clicks on CANCEL, I will have to restore the previous state which is already gone. Somehow I will have to go back and select the third record in the list of previous page.
So in order to resolve this problem, if I return false from my beforeXXX event, the next XXX event will be not be triggered.
But if the user clicks on YES or NO options I will have to trigger the event XXX manually which I am unable to do it for a selection-change event as of now.
Like this there can be many operations like list-filtering, searching, Ordering(A-Z/ Z-A), logout etc. For each of this operation I will have to write customised code which totally spoils the readability of the code.
So I was thinking if there is way to, somehow manually trigger the event XXX by holding the event object in beforeXXX...or is there any other way to restore the previous state.
Please give me suggestions....Thanks...
Many events have their "before-" counterpart, for example "beforeactivate". If you return false from this kind of the processing stops.
If not, or if your event does not have it's before- part, then you can use event object passed to all event handlers and call:
ev.stopEvent();
ev.stopPropagation();
return false;
at the end of your handler.
I have a button which launches a "modal dialog" - it just creates a transparent grid covering everything, with the "dialog" created on top of that.
However I have a strange issue - if I double/triple click the button really fast (or add some delay in the event code), the button click event is executed multiple times, creating multiple overlapping modal dialogs. If the first action in my event is to disable the button (IsEnabled=false) it seems to prevent this.
My guess is that Silverlight is being multithreaded with input - it is not only recording the second click in another thread (while the button's click event is running), but it is jumping the gun by evaluating which control should be the target before the previous event has finished executing. Even though that event alters what control is at those mouse coordinates, it doesn't matter.
Does anyone know anything about this behavoir, or a way around it? If I have something like a save window, where the user clicks a save button, a blocking grid ("Saving...") is placed up while it saves, and then the whole "window" is closed, I'd like to avoid the user being able to queue up multiple save event clicks (this could lead to unpredictable program behavoir).
If you've ever worked with WinForms or WPF, this is expected behavior. Your button is broadcasting its Click event until your modal dialog covers it up. Unfortunately, there is some amount of time between your first click and when the modal dialog covers the button which allows multiple clicks to the original button.
You have two solution choices:
Disable the button after the first click and then re-enable after the modal dialog returns. You've already mentioned that this works.
Write code in the Event Handler of the button to determine if a modal dialog is already being displayed. This way, you're putting the responsibility in one location rather than splitting it up (disabling and re-enabling the button). This would be my preferred solution.
I think what you're seeing is the behaviour of Silverlight's routed events.
You can set the Handled property of the event arguments to true to prevent the event from bubbling.
Is there a way to start off showing a dialog modally, but then instead of hiding it, to keep it visible while changing it to a non-modal dialog?
I want to show a dialog, blocking the method that shows the dialog. Then when the user clicks the 'Finish' button on the dialog I want:
The dialog to remain visible.
Control to return to the method that showed the dialog.
I've achieved this result by running the dialog on a separate STA thread, and using an event to block the main UI thread until 'Finish' is pressed, but there's a catch to this method: you can click on the close button of the 'main' window while the dialog is visible, and the main window closes when the dialog is hidden.
Update
Thanks for the responses so far. Sorry - it looks like I got the balance wrong between too much background and not enough.
The form is effectively a modal 'wizard' dialog - it appears, sits in front of the main app modally, and then is hidden. So as far as the user's concerned there's no non-standard weirdness going on. The only difference is that the dialog is driven from a series of callbacks from the UI thread, so I don't think making it truly modal (via a call to ShowDialog) for its lifetime would work. The first callback must show the dialog, and then block while the user sets their preferences via the dialog UI. After that, the dialog stays visible and displays a progress bar page while various other callbacks are made from the UI thread. Eventually the form is hidden. The user isn't interacting with the main window while the form is up. As far as they're concerned, it should appear to be 100% modal wrt the main UI thread.
(The form is a dialog for a Visual Studio wizard - these are driven from a series of callbacks on the UI thread). An alternative would be to show the dialog, hide it, immediately show a topmost 'progress' form instead and then hide that, but I think showing a single dialog is more seamless an experience for the user.
Again - sorry for the confusion!
Perhaps you want to rethink your interaction model? How are you going to explain this to your users? They have an internalized model of how computer programs work, and you better have a very good reason to break that. They know about modal dialogs, they know about non-modal dialogs, they know about inspectors. Choose one, and apply it.
Modal dialogs are made for short-time interaction. They should not block exiting the application. The user is in control of the interaction, the program only provides the minimum of restrictions needed.
[after the explanation, replaced]
What's wrong with showing the progress bar in the modal dialog? Start processing once ok
is clicked, disabling all buttons, only keeping the cancel button active? If it takes a long time, the user might want to abort the action. Only close the dialog when you're finished processing.
You could use a modeless dialog then have your main UI check if the user has clicked the Finished button. If the modeless dialog is open but Finished hasn't been clicked then don't respond to any users actions in the main form...
This is just a terrible idea - it's completely non-standard behavior and you're going to jump through all kinds of hoops to get something working that is just going to horribly confuse your users.
Like most of the other answers here stated, you're implement non-standard UI elements that will be confusing to most users.
If the dialog remains visible just to provide read-only access to the data, then why not have dialog window close normally and open a side-bar window in your application with the data from the dialog window?
If the dialog remains visible to allow the users to continue making updates in it, then perhaps, it shouldn't be modal to begin with.
Point is, there's a couple different ways you can accomplish your task without breaking standard UI metaphors.
I'd make it a flyout from the side or bottom of your app that shoves other things out of the way. If it's on top of other stuff that the user might need to see or interact with then it's just gonna annoy them.
I found that showing an an invisible modal dialog on the main UI thread during the blocking stage of the interaction works great.
Hidden modal dialog settings (so it's not visible): ShowInTaskBar=false, FormBorderStyle=None, size={0,0}, Opacity=0%, StartupPosition=CenterParent.
The hidden dialog is shown on the UI thread using ShowDialog. The visible dialog is shown on a separate STA thread. The thread is kicked off before calling hiddenDialog.ShowDialog on the main UI thread.
The visible dialog hides hiddenDialog when it wants the initial blocking state to complete. This stops the main UI thread from blocking.
The important bits of code:
void LaunchWizardForm(s)
{
// Show the wizard on its own thread.
ThreadStart t = () =>
{
_wizard = new WizardForm(s);
Application.Run(new ApplicationContext(_wizard));
};
var thread = new Thread(t);
thread.SetApartmentState(ApartmentState.STA);
thread.Start();
// Block this (main UI) thread
_hiddenForm.ShowDialog();
}
void EndModalEpisode()
{
_hiddenForm.Invoke((Action) (() => _hiddenForm.Hide()));
}