Focus on window not visible on screen

[luisanillo]

Hello,

I'm testing an application (delphi) and every time I press F12, I get a new window which helps me navigate in the application (note that both the application and the window are part of the same process, which is why minimizing does not show the window). My issue is that when it is done enough times, the window appears behind the application. From what the devs told me, I have to change the window Z order to make it visible on screen.  

I have tried multiple things, but the object always says visible = true, while visibleOnScreen = false. Any idea how can I change the z order of application windows or even better, make my window visible again ?

[tristaanogre]

windowObject.Activate where "windowObject" is your window you want to bring forward.

See if that helps.

[luisanillo]

Sadly it does not, I have already tried Activate, SetFocus, Minimize/Maximise and no success.

[tristaanogre]

Activate should work.. that is, essentially, the command that brings a window within an application forward.  

So... setting aside my TestComplete hat and putting on my QA/Tester hat...

Does it always happen at the same place?

You say you use it to navigate.  What if you navigate to that place where it fails right away rather than several times through?  Does it "fail" then, too?

See... my suspicious b*****d of a brain is wondering if this isn't a problem in your AUT where some form or other is set in such a way that it is ALWAYS in front, regardless of what else is happening.

[luisanillo]

The window is not visible and not accessible even by hand. It is some sort of weird bug, where the buffer of the number of form object in the application is capped and the window that I use to navigate is not accessible anymore. The solution would be to change it's z index in order to be higher than the actual application, and thus, it would be visible.

It's quite hard to explain, I am probably doing it wrong, but hear this example.

Open up Excel, and then go to File -> Open -> Browse. 

A dialog will pop out, prompting you to choose a file to open. If you go into the opened applications icon in your taskbar, you can see Excel Icon. Hover your mouse on it and you should see a preview of Excel (not the Open file window). That is the correct behaviour.

In my case, our application has the contrary effect. We do not see the dialog once we try to open a file and when hovering in the application icon, we see the dialog only and not the application...

That's why I'm looking for a way in TestComplete to change the z order of the application displayed. It seems Windows has some API to do so, and that is where I'm currently investigating.

I hope this makes the question clearer. Thanks for your concern !

[tristaanogre]

OK... then my hunch was right... you found a bug in your application under test.  TestComplete did it's job... you set up an automation to test the application and uncover bugs... you found one.

At this point, I'd push back to the development team as a tester and say "I found a bug, here's how you reproduce it" and then set up your automation to record the problem as a failed test so that, when they fix it, the test passes... kind of "Test Driven Development" in a way.

[AlexKaras]

Hi,

Robert is correct with all he has said.

window.Activate() brings the target window on top, unless it is overlapped by some other modal window. OnUnexpectedWindow event will be triggered in the latter case.

For obvious reason .Activate does not work in your case just because there is a problem in your tested application.

You may try to search for Windows call and try to bring this problematic window to top... Especially, if this is a real blocker and showstopper.

However: If the problem occurs soon enough (say, after 5-10 F12 presses), then this means that the real users will meet it as well. And according to your description, this will be a serious problem to them. Thus is must be considered as a high priority issue for Development and you, probably, should not spend your time to search for the workaround.

If the problem occurs after a lot of F12 presses (say, after test is executed for 3-4 hours), then, depending on the usual usage scenario of your tested application, this might appear as quite unlikely scenario for real end-users. In this case you may consider to restart your tested application from time to time during test run.

[luisanillo]

Indeed, however, that tool is only internal and it won't be fixed. That is why I'm trying to find a workaround with TestComplete!

[AlexKaras · Accepted solution]

Well, I see...

Ages ago I used this function (VBScript) to put on top some form. (Actually - window registered in Windows.) Hope, it might inspire you with some ideas.

'-------------------------------------------------------------------------------

Sub ActivateForm(ByVal strClassName, ByVal strWindowTitle)
  Const cProcName = "ActivateForm(): "

  Dim hWnd
  Dim dwLastError

  hWnd = Win32API.FindWindow(strClassName, strWindowTitle & " [Shared]")
  If (0 = hWnd) Then
    hWnd = Win32API.FindWindow(strClassName, strWindowTitle & " [Personal]")
    If (0 = hWnd) Then
      Log.Error cProcName & "Window was not found", "Window class name: " & strClassName & _
          vbCrLf & "Window title: " & strWindowTitle
    End If
  End If
'  If (0 = Win32API.BringWindowToTop(hWnd)) Then
  If (0 = Win32API.SetWindowPos(hWnd, Win32API.HWND_TOPMOST, 0, 0, 0, 0, Win32API.SWP_NOSIZE)) Then
    dwLastError = Win32API.GetLastError()
    Log.Error cProcName & "Window was not activated.", "Window class name: " & strClassName & _
        vbCrLf & "Window title: " & strWindowTitle & vbCrLf & _
        "System error code: " & dwLastError & vbCrLf & "System error message: " & _
        Utilities.SysErrorMessage(dwLastError)
  End If
End Sub
'-------------------------------------------------------------------------------

[luisanillo]

This might help, thank you !

I will respond give out more information once impleted !