I have one doubt, What happening if we press OK button in Window.alert in gwt? Is there any event happening backside if we pressed OK button?
Window.alert() is a blocking call, so upon clicking OK the code resumes running.
Window.alert("OK?");
GWT.log("That line won't run until after you dismiss the alert box, "
+ "THAT's the \"event\"!");
Related
I just want to ask what command in Ruby allows you to check if an application made in Ruby or running application is about to be closed? For example, I have an executable file that i ran and I clicked the close button on the window. I want to make a pop up of a dialog that says "you are about to close". Once you pressed the OK button, the window finally closes.
How can you do this in Ruby?
I don't know how things work in Ruby, but in general, on Windows, when a window receives a request to close, its window procedure receives a WM_CLOSE message. This is the place to display prompts to the user. If the app then wants to block the window from closing (because the user wants to reject it, etc), the app can simply skip destroying the window, and not pass the message on to the default message handler (DefWindowProc()).
In the case where the user clicks on the window's close button, or chooses the "Close" option from the window's pop-up system menu, or presses ALT-F4 while the window is in focus, the window receives a WM_SYSCOMMAND(SC_CLOSE) message, and if the message is passed on to the default message handler, the window then receives the WM_CLOSE message.
Take that information and translate it to Ruby as needed.
In some cases, if the user clicks on the Cancel button of an IProgressDialog, I would like to ask for confirmation and resume if the user changed their mind. Is that possible? I've tried resuming the Timer and also resetting the Progress but the dialog wouldn't resume.
I have a very large accounting system. In a user preferences section, the program has begun to act abnormally on my development machine only. No customers are reporting this, nor can I duplicate it on any of my other computers. Running Windows 8.1, others are on 7.0. Not exactly sure when this started happening because it's not the kind of thing one goes into on a regular basis. The preferences screen consists of a tab control and various standard controls. At the bottom is Okay, Cancel, and Apply buttons. All three buttons seem to be acting with the same strange behaviour. Clicking with a mouse does not generate a click event yet does not hang the system - mouseup follows and you can click it again and see the mousedown and mouseup but no click. However, since the Okay is defined as Default, pressing enter DOES create the desired click event, and all the code inside that even runs fine. Cancel and Okay also unload the form, but when clicked, that doesn't happen because none of the code gets executed, yet you can still navigate the screen (move between tabs and controls) but you can't even click the "X" button to close the form at that point.
Also, if you go straight in, and press enter, everything works and the form unloads, but if you do anything before pressing enter (or escape to cancel), like change a tab and/or edit a value, then press enter, the click event again does not run and the system semi-hangs.
I tried turning-off my anti-virus thinking that might have something to do with it, but no-go. Debugging is frustrating because while I finally got it execute the click event, the stop command inside that event (after debug.print "click") would allow stepping and success if just straight in and enter, but if anything else done as before described would stop at the stop statement (keyboard enter only still no mouse clicks under any scenario) and would do a total lock-out. In other lockouts where it would let me navigate, almost always selecting a new tab would cause a fatal error and it would force-unload VB for me, otherwise I had to use the task manager.
This is driving me nuts, but I don't know how else to debug it.
The culprit was tv_w32.dll which is Team Viewer. Turning-off Team Viewer allows my program to run normally.
I have a win32 application, there is an button on the main window.
When i click the mouse left button, i receive the WM_LBUTTONDOWN message, when i release the mouse left button, i receive the WM_LBUTTONUP message, that is normal.
However, if in the processing of message WM_LBUTTONDOWN, (while i am holding the mouse left button), the program show a modal dialog window, the button will never receive the WM_LBUTTONUP.
This becomes an issue because in the WM_LBUTTONDOWN the program did something that needs to be clear up in the WM_LBUTTONUP. Now because of the modal dialog, there is no chance to clear up anymore.
Is there a better way to handle this? I tried SetCapture, seems still can not receive the WM_LBUTTONUP.
This is quite reasonable. When you show the modal dialog it starts its own modal message loop. And so it will receive the WM_LBUTTONUP message.
The fundamental problem that you have is that you are showing the modal dialog in response to WM_LBUTTONDOWN, when in fact you should show it in response to WM_LBUTTONUP. Try pressing buttons in other applications and note that the action occurs only when the button goes up. You should do likewise and follow the platform standards.
I have a dijit dialog that pops up on clicking of a button. This dialog has a button which stands for submitting and one to hide the dialog On click of ok it sends a REST call and gets a response.
On error, an alert box is generated.
But what is happening here in IE 8 is that I need to explicitly again call a showdialog method to retain the dialog on screen.
What is expected behaviour is: when error occurs an alert box pops up and on click of ok the dialog in background retains. But this is not occuring normally. So I need to everytime check response and make an explicit call to show that dialog. If I do not call an explicit showdialog, the dialog simply visually seems nowhere(Gone!).
This is not a requirement if I use other browsers like chrome and FF which retain the dialog unless user himself cancels and hides them.
This explicit calling may not have been a problem unless it caused the blink effect. That is it has some delay and then shows( a sec or two after ok click on alert).
Further adding to the woe is that when this error scenario occurs and if user after clicking ok and then getting the dialog again after a blink follows and clicks cancel on dialog....poof! the behind screen that originally triggered that dialog still remains blurred! Hanging the browser!
Thanks & yes need a help, stuck on this!