Loading ...
Sorry, an error occurred while loading the content.

Re: Some new code

Expand Messages
  • pkaluski
    Hi Dennis, Thanks for a quick response. Please have a look at my comments below. They are by no means a kind of pressure to include changes in the code. Think
    Message 1 of 5 , May 9, 2005
    • 0 Attachment
      Hi Dennis,
      Thanks for a quick response.
      Please have a look at my comments below. They are by no means a kind
      of pressure to include changes in the code. Think of them as a next
      step in the discussion.

      2. As for PushChildButton we can add 4-th parameter like "mode" with
      values "BY_ID" or "BY_CAPTION". It is a matter of taste what is better
      - having 4-th parameter or a separate function. I believe that less
      parameters in the function makes code look cleaner, but I am not going
      to resist if people insist on 4-th parameter. Or maybe we should
      implement both so people can choose. Whatever the solution, it would
      be good to have it.

      3. Surely there are some things to refine. In addition, I have to
      admit that the function does not always work. While searching the
      internet, I've got an impression that WaitForInputIdle works reliably
      only when a new window/application is created. For all other cases it
      may actually return before the application is in input idle state. It
      happened to me when I started automated gui testing through terminal
      services.
      From the other hand it would be good to have a function, which would
      allow us to wait for application readyness instead of calling
      "sleeps". I think it is safe to assume that the initial
      siganture/prototype would be WaitForReady( hwnd, timeout ) (or some
      other name). Perl is really flexible about adding new parameters.
      By adding the current code (with more reasonable default timeout) we
      do not tight ourselves. We will have to state clearly that the
      function is not 100% reliable. If we finally find the right solution
      we will simply replace the implementation, leaving the signature
      intact.
      As for return values, I think the return values similar to those in
      original Win32 WaitForInputIdle should be fine

      One final note:
      I believe we should be carefull about specifying interfaces. Once we
      issue the code with a new interface and people will start using, it
      would be difficult to change it.
      From the other hand we should not be that carefull about
      implementations. Once we have an idea for implementation we should
      release it as soon as possible so people can test it and share their
      observations.

      -Piotr

      --- In perlguitest@yahoogroups.com, "Dennis K. Paulsen"
      <ctrondlpaulsden@y...> wrote:
      >
      > Piotr,
      > 1. I've integrated your FindWindowLike fix.
      >
      > 2. I understand the intention. Will have to look at further. I'd
      > hope that we could enhance the current function semi-pristenly to
      > accomodate for this.
      >
      > 3. Not integrated yet. I've used this functionality before and ran
      > into a quirk... Shouldn't be a big problem to integrate. We might
      > want to lower the timeout a bit in case one wants to use this to
      > determine when an app is ready for input vs. other methods,
      wouldn't
      > want a 200 second delay I think.. Might want to see what we can do
      > about unique return values... These are just ramblings off the top
      > of my head...
      >
      > Time permitting these can all get done.
      >
      > Regards,
      > Dennis
      >
      > --- In perlguitest@yahoogroups.com, "pkaluski" <pkaluski@p...>
      wrote:
      > > Ooopss!
      > > Yahoo has eaten all indentation.
      > > I will attach a zip file in the files section
      > > -Piotr
      > >
      > > --- In perlguitest@yahoogroups.com, "pkaluski" <pkaluski@p...>
      > wrote:
      > > > Hi Dennis, Hi Gabor,
      > > > Have a look at the code below. I am providing results of diff
      -c.
      > > > The following changes were done:
      > > > 1. FindWindowLike was fixed. It was treating Control ID = 0 and
      > > > Control ID = undef as the same.
      > > >
      > > > This is the fix:
      > > >
      > > > ***************
      > > > Fragment with the fix
      > > > *** 385,394 ****
      > > > (!$classre || $sClassname =~ /$classre/))
      > > > {
      > > > DbgShow("Matched $1\n") if $1;
      > > > ! if (not defined $ID) {
      > > > # If find a match add handle to array:
      > > > push @found, $hwnd;
      > > > ! } elsif ( defined $sID) {
      > > > if ($sID == $ID) {
      > > > # If find a match add handle to array:
      > > > push @found, $hwnd;
      > > > ----------------
      > > > Fragment without the fix
      > > > --- 385,394 ----
      > > > (!$classre || $sClassname =~ /$classre/))
      > > > {
      > > > DbgShow("Matched $1\n") if $1;
      > > > ! if (!$ID) {
      > > > # If find a match add handle to array:
      > > > push @found, $hwnd;
      > > > ! } elsif ($sID) {
      > > > if ($sID == $ID) {
      > > > # If find a match add handle to array:
      > > > push @found, $hwnd;
      > > >
      > > >
      > > >
      > > > 2. Added function PushChildById.
      > > > It is something like PushChildButton but considers only Control
      > ID
      > > of
      > > > the button and allows specifying a depth of a search in the
      > window
      > > > hierarchy tree. It allows to avoid problems with
      PushChildButton
      > > which
      > > > I described earlier. The function code (together with the
      > > decription)
      > > > follows:
      > > >
      > > > =item PushChildById( $parent, $button, $level, $delay )
      > > >
      > > > Allows pushing a button, which control id is eqaul to a given
      > > > parameter.
      > > > PushChildButton tries to match parameter against control id or
      > > > caption.
      > > > PushChildById matches only against control id. Secondly,
      > > PushChildById
      > > > allows specifying search depth in the windows hierarchy tree.
      > > > The default is 2, which means that only direct children will be
      > > > pushed.
      > > >
      > > > =cut
      > > >
      > > > sub PushChildById {
      > > > my $parent = shift;
      > > > my $button = shift;
      > > > my $level = shift;
      > > > my $delay = shift;
      > > > $level = 2 unless defined( $level );
      > > > $delay = 0 unless defined($ delay );
      > > > my @buttons = FindWindowLike( $parent, undef, undef,
      $button,
      > > > $level );
      > > > PostMessage($buttons[ 0 ], WM_LBUTTONDOWN(), 0, 0);
      > > > # Allow for user to see that button is being pressed by
      > waiting
      > > > some ms.
      > > > select(undef, undef, undef, $delay) if $delay;
      > > > PostMessage($buttons[ 0 ], WM_LBUTTONUP(), 0, 0);
      > > > return;
      > > > }
      > > >
      > > >
      > > > 3. Added WaitForReady function, which waits until the
      > application is
      > > > ready to receive more input. The code follows:
      > > >
      > > >
      > > > /*
      > > > * Piotr Kaluski <pkaluski@p...>
      > > > *
      > > > * WaitForWindowInputIdle is wrapper for WaitForInputIdle Win32
      > > > function.
      > > > * The function waits until the application is ready to accept
      > input
      > > > * (keyboard keys, mouse clicks). It is useful, for actions,
      > which
      > > > take a long
      > > > * time to complete. Instead of putting sleeps of arbitrary
      > length,
      > > > we can just
      > > > * wait until the application is ready to respond. Original
      > function
      > > > takes
      > > > * a process handle as an input. However, in GUI tests we more
      > often
      > > > operate
      > > > * on windows then on applications.
      > > > *
      > > > */
      > > > DWORD WaitForWindowInputIdle( HWND hwnd, DWORD milliseconds )
      > > > {
      > > > DWORD pid = 0;
      > > > DWORD dwThreadId = GetWindowThreadProcessId( hwnd, &pid );
      > > > HANDLE hProcess = OpenProcess( PROCESS_ALL_ACCESS, TRUE,
      > pid );
      > > > if( hProcess == NULL ){
      > > > TCHAR szBuf[80];
      > > > LPVOID lpMsgBuf;
      > > > DWORD dw = GetLastError();
      > > > FormatMessage(
      > > > FORMAT_MESSAGE_ALLOCATE_BUFFER |
      > > > FORMAT_MESSAGE_FROM_SYSTEM,
      > > > NULL,
      > > > dw,
      > > > MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
      > > > (LPTSTR) &lpMsgBuf,
      > > > 0, NULL );
      > > > printf( "OpenProcess failed with error %d: %s",
      > > > dw, lpMsgBuf );
      > > > }
      > > > //printf( "Calling WaitForInputIdle for pid %ld\n", pid );
      > > > DWORD result = WaitForInputIdle( hProcess, milliseconds );
      > > > if( result == WAIT_FAILED ){
      > > > TCHAR szBuf[80];
      > > > LPVOID lpMsgBuf;
      > > > DWORD dw = GetLastError();
      > > > FormatMessage(
      > > > FORMAT_MESSAGE_ALLOCATE_BUFFER |
      > > > FORMAT_MESSAGE_FROM_SYSTEM,
      > > > NULL,
      > > > dw,
      > > > MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
      > > > (LPTSTR) &lpMsgBuf,
      > > > 0, NULL );
      > > > printf( "WaitForInputIdle failed with error %d: %s",
      > > > dw, lpMsgBuf );
      > > > }else{
      > > > if( result == WAIT_TIMEOUT ){
      > > > // printf( "WaitForInputIdle returned after TIME
      > OUT" );
      > > > }
      > > > if( result == 0 ){
      > > > // printf( "WaitForInputIdle returned after wait was
      > > > satisfied" );
      > > > }
      > > > }
      > > > return result;
      > > > }
      > > >
      > > >
      > > > DWORD
      > > > WaitForReady( hWnd, dwMilliseconds = 200000 )
      > > > HWND hWnd;
      > > > DWORD dwMilliseconds;
      > > > CODE:
      > > > RETVAL = WaitForWindowInputIdle( hWnd, dwMilliseconds );
      > > > OUTPUT:
      > > > RETVAL
      > > >
      > > >
      > > >
      > > >
      > > > I would appreciate if you include it in the next release. It
      > should
      > > > not do any harm to existing code, from the other hand it
      > provides
      > > some
      > > > useful functionality, which I already use, so it would be
      easier
      > for
      > > > me to have the most recent version in source forge instead of
      > local
      > > > drives on all my machines. If you have any questions, let me
      > know.
      > > > -Piotr
    • Gabor Szabo
      Hey, it is good to see someone is working on the module again ! ... Yes, though if you clearly mark something as experimental then I belive it is ok to change
      Message 2 of 5 , May 10, 2005
      • 0 Attachment
        Hey, it is good to see someone is working on the module again !

        On 5/10/05, pkaluski <pkaluski@...> wrote:
        > One final note:
        > I believe we should be carefull about specifying interfaces. Once we
        > issue the code with a new interface and people will start using, it
        > would be difficult to change it.

        Yes, though if you clearly mark something as experimental then I
        belive it is ok to change even the interface. People who use this
        interface should know they have to take additional care when
        upgrading. So don't hold back code just because you are not fully satisfied
        with the interface.

        Gabor
      Your message has been successfully submitted and would be delivered to recipients shortly.