Onevent WINDOW_OPEN and WINDOW_ACTIVE do not work properly

[Enricoys]

In the code below I used three OnEvent methods to close a modal message window. I have commented out two of them in the code below to make sure that only one at the time is used. My problem is that the two hanlders based on WINDOW_OPEN and WINDOW_ACTIVE do not work on my PC. The CUSTOM works fine. Reason? My system is Win7, IE11 and MS 14.2.09.

Code: Select all

//Set IGNORESPACES to 1 to force script interpreter to ignore spaces.
//If using IGNORESPACES quote strings in {" ... "}
//Let>IGNORESPACES=1

//Three versions of OnEvent. Only first version works fine.

// This Onevent Handler based on CUSTOM works fine.
Let>DoIt=False
OnEvent>CUSTOM,DefaultTrigger,DoIT,CheckWarning
SRT>DefaultTrigger
END>DefaultTrigger
SRT>CheckWarning
  ifWindowOpen>Macro Scheduler Message
    GetTime>OEtijd
    WriteLn>%script_dir%\log\onevent.txt,Res,%OEtijd% Checkwarning version 1

    SetFocus>{"Macro Scheduler Message"}
    UIClick>{"Macro Scheduler Message"},{"OK"}
    Wait>0.1
  EndIf
END>CheckWarning

/*
// This one does not work either with param 0, 1 or 2
OnEvent>WINDOW_OPEN,Macro Scheduler Message,1,CheckWarning
SRT>CheckWarning
  GetWindowList>winlist
  UpperCase>winlist,winlist
  Separate>winlist,MACRO SCHEDULER MESSAGE,RecCheck
  If>RecCheck_count>1
    GetTime>OEtijd
    WriteLn>%script_dir%\log\onevent.txt,Res,%OEtijd% Checkwarning version 2

    SetFocus>{"Macro Scheduler Message"}
    UIClick>{"Macro Scheduler Message"},{"OK"}
    Wait>0.1
  endif
END>CheckWarning



// This one does not work either.
OnEvent>WINDOW_NEWACTIVE,0,0,CheckWarning
SRT>CheckWarning
  ifWindowOpen>Macro Scheduler Message
    GetTime>OEtijd
    WriteLn>%script_dir%\log\onevent.txt,Res,%OEtijd% Checkwarning version 3

    SetFocus>{"Macro Scheduler Message"}
    UIClick>{"Macro Scheduler Message"},{"OK"}
    Wait>0.1
  EndIf
END>CheckWarning
*/


GetTime>OEtijd
WriteLn>%script_dir%\log\onevent.txt,Res,%OEtijd% Start
Let>DoIt=TRUE
MessageModal>test message
 

[JRL]

None of the three work for me and that would be my expectation. The reason? Because you are calling a modal message that effectively stops the script when called. The script doesn't start again until you close the window at which point the message window is no longer open to be detected. You either need to detect the message window from a separate script or figure a way to use a non-modal message.

[Enricoys]

Thanks JRL for your quick reply.
The reason why I made this example is that originally I had this problem with a pop-up window 'Message of webpage' showing the error 'No data received'. This pop-up window is also a modal window which I assumed could be handled with the OnEvent method. Unfortunately it didn't work with the WINDOW_OPEN en WINDOW_ACTIVE method. Furthermore the example reacts the same with the non-modal method 'message'. This example is easier to understand than my original script however show the same problem. Once again, the first method works fine on my system for both modal as non-modal messages. Why does it behave different on your system and why do WINDOW_OPEN and WINDOW_ACTIVE not work at my system for both modal as non-modal messages?

[JRL]

Why does it behave different on your system...

First I have to apologize. I copied and ran your sample again this morning and indeed the custom OnEvent> does close the Message window. The only excuse I can come up with is that I deleted the Writeln> lines and I must have also inadvertently deleted the Let>DoIt=TRUE line. Of course without that line the custom OnEvent> will not trigger.

That said. The fact that the custom works and the other two do not puzzled me enough to spark a memory. Back at the end of 2011 I was testing new OnEvents that were coming out in about-to-be-released version 13. Marcus can confirm this or call me crazy... but as I recall he made the custom OnEvent> run in its own thread so that it could be independent. He did this because he could not know what a coder may want to do with the custom event handler. This would explain why the custom OnEvent> will close a Macro Scheduler modal message window spawned from the same script, while the other two OnEvents will not.

To demonstrate that the WINDOW_OPEN and WINDOW_NEWACTIVE OnEvents will close a Macro Scheduler modal message window, see the script below. The script takes the WINDOW_OPEN OnEvent script and writes it to the temp directory then uses ExecuteFile> to run the newly written script. When the original script opens a Modal Message, the external OnEvent script promptly closes the message window. Both scripts will close after a time out period and the original script will delete the external script so there should not be any clean-up needed unless you quit the script early.

To address your original problem with the web page modal message. Without seeing the webpage I can only guess what the issue might be. Some possibilities include, the window isn't being properly detected due to: The displayed window name, 'Message of webpage', may not be the window's real name. The window may not be a window at all, could be an oversized button displaying an image or a borderless window displaying an image. Or it could be the message can't be closed using the UI functions. Have you tried setting focus then pressing Enter? Could be the window can only be closed by mouse click. Have you tried closing it manually using the keyboard?

Hope something here is helpful.

Code: Select all

LabelToVar>ScriptToWrite,vScript
WriteLn>%temp_dir%KillMessage.scp,wres,vScript
ExecuteFile>%temp_dir%KillMessage.scp

/*
ScriptToWrite:
// "This one does not work either with param 0, 1 or 2"
//Use 1

OnEvent>WINDOW_OPEN,Macro Scheduler Message,1,CheckWarning
SRT>CheckWarning
  GetWindowList>winlist
  UpperCase>winlist,winlist
  Separate>winlist,MACRO SCHEDULER MESSAGE,RecCheck
  If>RecCheck_count>1
    SetFocus>{"Macro Scheduler Message"}
    UIClick>{"Macro Scheduler Message"},{"OK"}
    Wait>0.1
  endif
END>CheckWarning

//Added so the external script pauses long enough to see the Message Window
//then times out after three seconds and closes.
Label>Loop
  Timer>EndTime
  If>EndTime>3000
    Exit>0
  EndIf
Goto>Loop
*/

MessageModal>test message
//Need to wait long enough for the external script to close before deleting the file
//5 seconds is longer than 3 seconds.
Wait>5
DeleteFile>%temp_dir%KillMessage.scp

[Enricoys]

Thanks JRL. Your reply helped me to understand that I have to run first a macro in background which does the job. I work with compiled macro's so I did it that way. I'am still not sure whether it solved my problem. Reason is that the original macro runs as an exe on a system were the message 'No data received from the server' occurs only one or two times a day. My problem is that I can not replicate this error on my system since it occurs so rarely. So debugging is trial and error to find and I hope the solution is using the OnEvent method. I will let you know if this background method solved it.

[JRL]

I still wonder if the issue is that the windows actual name does not match the name that displays ('Message of webpage'). In the past I have used a compiled script with a WINDOW_NEWACTIVE OnEvent to log each window name on the computer I'm working with.

Something like:

Code: Select all

OnEvent>WINDOW_NEWACTIVE,0,0,Log

SRT>Log
  GetActiveWindow>vTitle,vWinX,vWinY
  TimeStamp>%temp_dir%ActiveWindowLog.txt,vTitle
END>Log

Label>Loop
  Wait>0.01
Goto>Loop

[Enricoys]

Problem solved. The solution was indeed to run an 'OnEvent>WINDOW_OPEN,...' macro in the background checking for this window title. I had no problem by matching the window name. In the part of original script where I need to check for this message I start the background macro using 'RUN>' and later on when I don't need it anymore I remove the process by 'KillProcess>' to save processor time. I had to compile this window checker script with the '/NOSYSTRAY' option otherwise the icon remain in the system tray after the KillProcess (actually the icon would remove itself as soon as I hover over the system tray, however it's nicer not have this rubbage in system tray).
JRL, thanks for your help.