I have a Control say for ex a Submit button if user clicks the button twice or more continuously then user receiving same message / same operation taking place twice or more.
I need to avoid this situation.
thanks for your inputs.
You need to detect the button click event either in the code behind of the view (or ViewModel if using the MVVM pattern) and disable the button. Now I take it that your submit button is firing off some kind of asynchronous operation. Once the asynchronous operation has successfully completed you will probably need to enable the button so that it is available again.
Shankar, if you want to avoid clicking on button, you should disable it. If you can give more details about what exactly you are trying to do, more details can be given.
Related
I am currently working on a LabVIEW project and have found myself stuck on how to make a while loop exit when I press the abort (stop) button. For a simple while loop I understand how to do this - but the problem is that this while loop is nested inside of an event structure and I'm guessing that the button cannot be pressed while the loop is executing. Attached here is a picture of part of my code (that contains this specific event case which is causing me problems): To spend a little more time explaining what the problem is - I think the code is doing what I want it to do (namely output a set of commands in a repeated cycle with a wait timer) but I cannot stop the code mid cycle (pressing the abort button with my mouse does nothing - as in the button doesn't show it being pressed and the indicator shows no change, I also can't use any other functionality of my program during the cycle which I'm assuming is related). And I do not want to stop the LabVIEW program from running entirely - just the code inside the while loop pictured above. This is what the front panel is configured too for completeness:
Essentially what I want to happen is the while loop to execute when I press DWG and in the middle of the cycle be able to abort it. Sorry if my code seems a little messy. Additionally, I've tried the same code with a for loop originally (via a conditional terminal so it could stop early) and that didn't work either. Thanks for any help I appreciate it!
Your problem is that inside the event structure, by default the UI is frozen so no UI actions (keyboard/mouse/etc) are processed until you exit that frame.
Option 1. You can right click the Event Structure and select "Edit events handled by this case" dialog and then uncheck the "Lock panel" checkbox -- that will allow the UI to be live while you are in that frame. I do not recommend this solution generally unless you have an extremely simple user interface because it leads to the user being able to change controls without the events behind those controls being processed (not a good UI experience for users). But if the UI is simple enough, that works.
Option 2. You can create a user event that is the code you want inside your While Loop. When the Deg Wait Go button is pressed, use the "Generate User Event" node to trigger that event. Do the same thing in the user event case so that the event re-triggers itself if and only if the Abort button has not been pressed.
Option 3. Create a separate loop OUTSIDE your UI loop that does your processing with some sort of command queue running between the UI loop and that other loop. The other loop moves into various states at the request of the UI loop... it's the one that does nothing until it receives a "go" message and then keeps looping until it receives a "stop" message. You can Google "queued message handler" for extensive details of this solution. This is the most common solution for complex UI requirements, especially useful for separating concerns of the UI code from the execution code.
I have a Lotusscript agent behind a submit button that takes a while to do everything....the user needs to know it is processing so that they do not click the button multiple times.
Am using #Command([RunAgent];"agentname") to kick the agent off.
How in Lotusscript could I add some kind of 'processing' indication, either a progress bar or a spinner or something? I suppose I could embed some javascript inside the lotusscript, but hoping someone has a clean example or some tips to do this.
Maybe hiding the submit button at the same time if I use javascript via a display property on a surrounding the button would help too.
You can't do this with LotusScript coding, and while hiding the Submit button is a good idea, you're going to have to know when to unhide it. A simple #Command([RunAgent]...) call won't give you a way to do that.
You're going to have to redesign your form to include a significant amount of JavaScript and make an AJAX-style call to invoke your agent asynchronously via a ?OpenAgent URL sent in a POST request via XMLHttpRequest. Your main JavaScript code will continue after the call and launch the spinner, and the callback that you set up to handle the asynch return from the XMLHttpRequest can then either transition to a new page or stop the spinner by setting a variable that the spinner is checking once every second or two.
I and my co-workers can't seem to agree on what the best practice should be when it comes to Vue and popups.
The question is as follows:
You are on the main window, you get the data from the backend using REST API and you notice an error. To fix it, you go to an edit popup and after hitting save what should happen?
Should you call the API from the popup?
Emit the changed data and let the main window call the API?
...
This is very interesting question but I think the truth depends on your whole architecture, implementation and approaches you use.
Say, if you worry about the "separation of concern" you wouldn't give a popup any access to API because its work is to show you some data as a popup, return data, and that's it.
On the other hand, how are you handling errors? What if an error occurs when user works in popup? Where do you show error?
Another question is the usability. For example, if error occurs when you save data, if it's done by the main window, you are going to:
Show the error message
Make user to click some button again to show the popup
Fix a problem and click the Save button in it.
But if you would access API right from popup you would avoid first 2 steps. Another concern is how you handle wrong data.
If you are still in the popup you easily can validate the data and cancel saving (or disable this button at all) but if it's done after the popup is closed it may be too late.
I am using simple event handler in the while loop.
I have value change event for the boolean button. There is some code that takes 3-4 seconds to execute.
The problem is I am not able to click anything on my Front panel during this period. Is it possible to allow the user to click on other controls when event handler is working on some case (as I understand the event handler is able to collect all events and process them ASAP)?
I fully agree with Mikhail N Zakharov's answer, but anyway your problem can be easily solved by just unchecking the checkbox named Lock panel until the case for this event complates
Please see screenshot below.
PS. Once again it is not the best practise to make event structure to work for 3-4 seconds.
I think you need to restructure your application to make it more responsive. LabVIEW best development practices suggest keeping event handler code as fast as possible. One of the ways to handle this would be to send a message into the queue on the change of this Boolean control and process the queue in a separate loop.
My mdi VB.Net application performs a long operation on some data. Ideally I should use a separate thread to prevent the dreaded “Not Responding” message.
My problem is if I use a separate thread users then have the ability to click on other controls in the application which can directly affect the operation my background thread is working on, creating an error.
Is there any way to prevent all the mdi windows, toolbars and other controls from receiving mouse clicks and keyboard input during my background thread’s operation?
Or is there a way to clear the message que before performing a Application.DoEvents?
Thanks
I would say that the best choice when you don't want a user to click on a control is to set Enabled to False for that control.
CLARIFICATION: Setting Enabled to False for a parent control will also disable any children. So, setting Enabled to False on the main window and and MDI windows, will do the trick.
There are a couple of ways of disabling the controls but I'm not sure it's what you want.
If you have a main window which is completely disabled while a background thread is processing then why go through the overhead of processing on the background? The advantage of processing on the background is to allow the user to still work with the application while you process data.
I think a better approach would be to take Dustin's route and selectively disable certain controls that can affect the background operation. Or make your background operation independent of the UI while it's processing.
If you tell us a little bit more about how your Main Window and Background thread interact we may be able to give you a better solution.
Hide all forms and only show the one main form. Then disable the Toolbar/Menu if you have either. Then have a status bar with a progress bar and when it gets done, unhide the form the user was working on.
When you are using a statusbar or a progress bar while your background thread is processing some longduring task, disabling your form will also disable your progress/status bar from updating. So what you should do in this case is disable every other control exept from the one that needs te be kept active (e.g. like a progressbar).
List<Control> lstControls = GetAllControls(this.Controls);
foreach (Control ctrl in lstControls)
{
if (ctrl.GetType().Name.ToLower().Contains("progressbar") {
ctrl.Enabled = true;
}
else
{
ctrl.Enabled = false;
}
}
Use a thread and display a modal dialog that shows the user the progress of your task and gives the user the option to cancel it.
The modal dialog will automatically prevent input (the parent may have to be the mdi window itself.)
(Please do not use hacks like hiding or disabling controls or windows. And please, please, please! do not use DoEvents.)