I want to perform a operation after a window is closed, i.e Suppose I have a window or any dialog popped up and now I want my code to wait until this particular dialog get closed and after that I want to code continue.
Means I want to wait till that window is opened without using hardcoded 'Wait()' function.
Is there any method in VBScript or QTP that fulfills my needs?
You could try the 'WaitProperty' method on your window to determine when visible property becomes false, but that might throw an error once the window is no longer available. Otherwise, you can always loop until it no longer exists
While Window("My Window").Exist(0)
Wait 0, 500 ' Pause briefly before looking again
Wend
Related
I'm using OpenEdge ABL to create a window that will run a secondary window on the touch of a button. However I am trying to get the first/parent window to freeze while the child window is running and resume when the child window closes.
I attempted to use WAIT-FOR WINDOW-CLOSE OF CURRENT-WINDOW on the parent window however this returned the error: Invalid widget handle used in WAIT-FOR statement. WAIT-FOR terminated (4122).
To run the child window I use:
RUN D:\adherenceEdit_12875-Win.w(cUserId,cShiftCode,dtDate).
Are you trying to make the child window modal?
I think you can look into using the TOP-ONLY or ALWAYS-ON-TOP attributes on the window, or make the child a dialog box.
I got around this was by adding:
DO WITH FRAME {&FRAME-NAME}:
Making the sensitivity of the buttons false meant that they would not be pressed while the child window was running.
ASSIGN CURRENT-WINDOW:SENSITIVE = FALSE.
RUN D:\adherenceEdit_12875-Win.w(INPUT cUserId,
INPUT cShiftCode,
INPUT dtDate).
After the child was closed the parent window continues running and resets the buttons sensitivity allowing them to be pressed
ASSIGN CURRENT-WINDOW:SENSITIVE = TRUE.
END.
I'm not sure if this is the most efficient way to do this and #nwahmaet's answer may have provided a more efficient method.
I like to do this by hiding the Main Window while the Popup is opened...
// Replace the C-Win to window's name - Not required to specify the frame
C-Win:VISIBLE = FALSE.
RUN My_Program.w.
C-Win:VISIBLE = TRUE.
I'm trying to write an AppleScript that tells if application has a specific menubar item. I've found this snippet on the internet, and tried to run, but it doesn't produce any effect. I've spliced into it some debug statements to check the control flow, and it seems not to enter the conditional 'if' at all.
No error message, no output, nothing!
on menuItemExists({appName, menuName1, menuItem1})
display notification "1"
tell application "System Events"
display notification "2"
tell application process appName
display notification "3"
if menu item menuItem1 of menu 1 of menu bar item menuName1 of menu bar 1 exists then
display notification "4"
return true
else
return false
end if
end tell
display notification "5"
end tell
end menuItemExists
if menuItemExists({"timeEdition", "Extras", "Start Recording"}) then
display dialog "hoda"
end if
If we assume that the AppleScript is functioning as it should, then this leads to one conclusion: at least one of those menu or menu item GUI objects does not exist, and therefore the script has nothing to return.
If that conditional statement passed—and only if it passed—then notification 4 would be displayed, and the function menuItemExists would return true. If this function returns true—and only if it returns true—then a dialog box would appear displaying the message "hoda".
However, no such dialog appeared, which implies that menuItemExists did not return true. If it did not return true, then it must have returned false. And if it returned false, this means the condition of some menu item’s existence failed, so no notification after number 3 would have been seen.
I believe you were expecting some output even in the event of failure. However, there is no error in the script, and the only statements that return values are all inside a function handler. That returns its value (which we’ve now deduced was the boolean value false) to the parent script that called it; and it’s only the parent script that would return any value—if it had a value to return—to the output window you were expecting to display a result.
Without having the application you’re using on my computer, it’s not possible for me to determine where in that conditional clause the assertion fails. My advice is to test each object individually, from menu bar 1 through to the menu item in question, and I’m confident the culprit will emerge.
The AppleScript code in your OP is only going to return true and trigger the display dialog "hoda" if and only if timeEdition is running and is not actively recording. When it's actively recording the menu shows Stop Recording. If timeEdition is not running, you can add tell application "timeEdition" to activate to the top of the script if you want the handler to result in true and display "hoda" in a dialog box when it's running and not actively recording.
display notification "5" will never trigger because of the use of return with both true and or false triggering prior to it.
I installed timeEdition and tested the AppleScript code in your OP and it does return false in Script Editor if it's not running. If running and not actively recording, it does trigger display dialog "hoda".
So, the AppleScript code in your OP actually works just as coded, although how it's coded is not of any practical use other then some testing, until its recoded for a real world use case scenario.
I'm writing a MEL script which involves opening the grease pencil UI toolbar. I want to remove the close button on that toolbar. I tried doing
GreasePencilTool;
window -edit -tbm 0 greasePencilFloatingWindow;
but get Error: line 2: window: Object 'greasePencilFloatingWindow' not found.
Further tests reveal that running
GreasePencilTool;
window -q -exists greasePencilFloatingWindow;
will return a result of 0.
Running GreasePencilTool; and then window -edit -tbm 0 greasePencilFloatingWindow; at separate times works as expected, as does running window -edit -tbm 0 greasePencilFloatingWindow; when the toolbar is already open.
However, I need to be able to remove the close button immediately when the toolbar opens.
The closest thing I can think of that illustrates what I want to do are Javascript callback functions, where another function can be executed once the current function is finished... but is there a way to do something like that in MEL?
I've also tried using the evalDeferred command without success.
The grease pencil tool is launched asynchronously so the window will not be present for some unknown length of time. This means the best you could do is trigger a function which would check periodically and do it the next time you find the correctly named window; you could attach this to an idle time script job.
It's ugly. But it is probably the only way since there's no event that will notify when thje window arrives. If you do that, make the script job suicide after it fires so it's not sitting there on every idle check till the end of time.
To prevent users from clicking in my main_window when a MessageBox appears I have used:
EnableWindow(main_window,FALSE);
I got a sample MessageBox:
EnableWindow(main_window,FALSE);
MessageBox(NULL,"some text here","About me",MB_ICONASTERISK);
EnableWindow(main_window,TRUE);
The problem is that when I press "OK" on my MessageBox it closes and my main_window is send to back of all other system windows. Why this is happening?
I tried to put:
SetFocus(main_window);
SetActiveWindow(main_window);
after and before : EnableWindow(main_window,TRUE) the result was strange: it worked 50/50. Guess I do it the way it shouldn't be.
Btw.
Is there a better solution to BLOCK mouse click's on specific window than:
EnableWindow(main_window,FALSE);
Displaying modal UI requires that the modal child is enabled and the owner is disabled. When the modal child is finished the procedure has to be reversed. The code you posted looks like a straight forward way to implement this.
Except, it isn't.
The problem is in between the calls to MessageBox and EnableWindow, code that you did not write. MessageBox returns after the modal child (the message box) has been destroyed. Since this is the window with foreground activiation the window manager then tries to find a new window to activate. There is no owning window, so it starts searching from the top of the Z-order. The first window it finds is yours, but it is still disabled. So the window manager skips it and looks for another window, one that is not disabled. By the time the call to EnableWindow is executed it is too late - the window manager has already concluded that another window should be activated.
The correct order would be to enable the owner prior to destroying the modal UI.
This, however, is only necessary if you have a reason to implement modality yourself. The system provides a standard implementation for modal UI. To make use of it pass a handle to the owning window to calls like MessageBox or CreateDialog (*), and the window manager will do all the heavy lifting for you.
(*): The formal parameter to CreateDialog is unfortunately misnamed as hWndParent. Parent-child and owner-owned relationships are very different (see About Windows).
I'm programming a Windows application that doesn't have a menu. Every time I press Alt, it receives the WM_ENTERMENULOOP event and hangs until I press a key.
I've tried other applications without menu (like the MS .chm file viewer) and they exhibit the same behavior.
There is no difference between forwarding the event to DefWindowProc or processing it.
Is there a way to stop Windows from entering the menu loop if there is no menu? Alternatively, is there a way to exit it manually as soon as the event is received?
Process WM_SYSKEYDOWN and WM_SYSKEYUP manually (dont' pass them to DefWindowProc) if you want to disable entering menu loop.
Also, you may want to process WM_SYSCHAR and return TRUE for this message to avoiding beeps for keystrokes like Alt+SomeKey
Scalable code after parsing window message and return correct result with NO call DefWindowProc.
case WM_SYSKEYDOWN:
case WM_SYSKEYUP:
case WM_SYSCHAR:
return (LRESULT)1;
https://learn.microsoft.com/en-us/windows/win32/inputdev/wm-syskeydown
https://learn.microsoft.com/en-us/windows/win32/inputdev/wm-syskeyup
https://learn.microsoft.com/en-us/windows/win32/menurc/wm-syschar
Return value
An application should return zero if it processes this message.