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.
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 read manuals, but I'm confused yet, when it's necessary to use wait method in Appium. So, what I have to implement (on Ruby):
When app starts, it shows Sign in activity. I enter log in data there and click Sign in button.
App goes to another activity. First, empty screen is shown with circular progressbar, then loaded data is shown.
I want to tap on this screen in specified place.
My code is:
textfield(1).send_key('login')
textfield(2).send_key('password')
button(1).click
Appium::TouchAction.new.tap(x: 0.5, y: 0.5).perform
In arc it works perfectly, but when it's running in tests I have a problem on step two: it seems tap is executed on empty screen, when data is not loaded yet. So, how can I tell to test that it's necessary to wait some time?
I am not familiar with ruby,
In python we use this after line of code to wait for specified time you can give 5,10,15,20 in seconds as required.
self.driver.implicitly_wait(10)
I have the following script:
gosub, menucreate
Settimer, CheckRun, 1000
ExitSub:
ExitApp
return
Mess:
msgbox tada
return
menucreate:
Menu, TRAY, DeleteAll
Menu, TRAY, NoStandard
Menu, TRAY, Add, Exit , ExitSub
Menu, TRAY, Add, Message , Mess
return
CheckRun:
gosub ,menucreate
return
On occasions the menu Message works, but sometimes not.
Every few starts of this program it shows the message, and it keeps working if I reload.
But if I restart it might not working (or might ... I couldn't figure out any pattern)
To me it seems like you fail to end the Auto-execute section.
After the script has been loaded, it begins executing at the top line, continuing until a Return, Exit, hotkey/hotstring label, or the physical end of the script is encountered (whichever comes first). This top portion of the script is referred to as the auto-execute section.
So try and put a return after your settimer and see if that helps
OK, in mean time I found out, but till now hadn't time to add this here (and kinda forgot).
The thing is: If the menu gets redrawn every second it will only cause an action until it gets redrawn.
So if you have pulled it up and the redraw happens before you click on a item nothing happens.
This thing here was just a test script to find out why the actual one has stopped working.
In that one I have included a test if actually something has changed and only then the menu get redrawn ... and voila it works.
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
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).