Forum Discussion

hlalumiere's avatar
hlalumiere
Regular Contributor
12 years ago

Unclear statement in documentation regarding OnUnexpectedWindow event...

I am currently in the process of designing a better handler for unexpected windows in our test suite. Reading the documentation here, it is stated:



"If you simulate a mouse click within the OnUnexpectedWindow event handler, TestComplete will check for an unexpected window (that is, the event handling routine will be called recursively)."



So, how exactly am I supposed to handle an unexpected window, if I cannot click any of its buttons without triggering my handler again? Will it perform the click, close the window and THEN call the handler? In which case I just have to check if the Window parameter of the handler is nothing?



This is all pretty confusing, I don`t seem to see the usefulness of recursivity in this particular case. It seems to be twisted and convoluted just for the sake of it.



As a reference, what I intend to do is fetch the buttons configuration of the particular dialog that triggered the event, fetch the caption in the dialog, compare the dialog and buttons selection to a database table, and retrieve the appropriate default answer for the particular dialog. Then click that button and have the test moving forward again like nothing happened.

2 Replies

Sort By
  • AlexKaras's avatar
    AlexKaras
    Champion Level 3
    12 years ago
    Hi Hugo,



    The essence of the OnUnexpectedWindow event (likewise for the OnOverlappingWindow one) is that it can be triggered only if your script tries to perform some action over the target window. I.e. if the script tries to either click something within the window, or set the focus to some control/activate the window or type something via the .Keys() method.

    The event will not be triggered if the window is operated by the methods that do not require 'direct' interaction with that window. I.e. commands like window.Close, window.control.setText, etc. will not trigger OnUnexpectedWindow event even if the target window cannot be focused because of the overlapping modal window.



    Considering the above, you have two options to prevent endless recursion in the event handler (BTW, TestComplete is quite smart and pretty often will either warn you or stop the test with the relevant message in the test log if the test code enters endless recursion in the event handler):

    a) You can operate with the unexpected windows via the methods that do not require emulation of mouse clicks or key presses;

    b) You can introduce a public flag variable of boolean type and use it to prevent recursion. Something like this (untested DelphiScript pseudocode):

    var boolInHandler;



    procedure OnStartTest()

    begin

      boolInHandler := false;

      ...

    end;



    procedure OnUnexpectedWindow()

    begin

      if (boolInHandler)

        return;



      try

        boolInHandler := true;

        ...

      finally

        boolInHandler := false;

      end;

      ...

    end;

  • hlalumiere's avatar
    hlalumiere
    Regular Contributor
    12 years ago
    b) You can introduce a public flag variable of boolean type and use it to prevent recursion. Something like this (untested DelphiScript pseudocode):



    Ah yes, this makes sense. Thank you.



    Hugo