Forum Discussion

ian807's avatar
ian807
Occasional Contributor
15 years ago

Common dialogs in Windows 7 vs. XP or Vista

The common dialog for file opening has changed in Windows 7 as shown in the table below:















































  V32   V64 W764
Process("TKS") Process("TKS") Process("TKS")
Window("#32770",
"Open", 1)
Window("#32770",
"Open", 1)
Window("#32770",
"Open", 1)
Window("DUIViewWndClassName",
"", 1)
Window("DUIViewWndClassName",
"", 1)
Window("DUIViewWndClassName",
"", 1)
Window("DirectUIHWND",
"", 1)
Window("DirectUIHWND",
"", 1)
Window("DirectUIHWND",
"", 1)
Window("CtrlNotifySink",
"", 4)
Window("CtrlNotifySink",
"", 4)
Window("CtrlNotifySink",
"", 3)
Window("SHELLDLL_DefView",
"ShellView", 1)
Window("SHELLDLL_DefView",
"ShellView", 1)
Window("SHELLDLL_DefView",
"ShellView", 1)
Window("SysListView32",
"FolderView", 1)
Window("SysListView32",
"FolderView", 1)
Window("DirectUIHWND",
"", 1)



Notice that in the Windows 7 column, the path terminates in "Window("DirectUIHWND",
"", 1)"



The result is that it is no longer possible to select files by name or position, or detect the number of files in the dialog box as it is when the terminating object is "SysListView32.



This breaks several hundred of our scripts which use the common dialogs. Can someone explain how this will be addressed? Is there a workaround better than clicking at some arbitrary, resolution-dependent, x/y position as the recorder does?



Thanks in advance for any help,



Ian Hughes

Seismic Micro-Technology

Houston, TX





5 Replies

  • sjwalter's avatar
    sjwalter
    New Contributor
    Hi all,



    We were also hamstrung by this but found a workaround - for us anyway i.e. app being tested is built with Delphi 2007. We stepped in to the VCL source and found the use of Windows 7 (also Vista) dialogs depended not only on o/s version (WinMajorVersion >= 6) but on themes being enabled and a global variable Dialogs.UseLatestCommonDialogs being true.



    We disabled themes (by choosing the Windows Classic Theme and found we were able to get access to the properties we used to under XP.



    The actual test, in the Delphi unit Dialogs is:

      if (Win32MajorVersion >= 6) and UseLatestCommonDialogs and ThemeServices.ThemesEnabled then ... (use W7 dialog)



    We found that we can set the variable UseLatestCommonDialogs in app startup code viz

      Dialogs.UseLatestCommonDialogs := False;



    but haven't tested it yet.



    We're still considering the ramifications of either of these solutions - whether, for example, we're throwing out the baby with the bathwater by forcing our testing to be effectively against an XP UI or by requiring a code change to make the app testable.



    We would appreciate any comments from the community on this aspect



    Regards, sjwalter
  • We have the same problem with files/folders recognition in Explorer window (Win 7 platform).


    AQA support advised us to use MSAA to access the problematic control (see the "Testing with Microsoft Active Accessibility" help topic). You should add class name of you problematic control (e.g. "DirectUIHWND") to the list of windows that will be shown as MSAA objects. 

    To do this just open "Default Project Properties" dialog, navigate to the "Project -> Open Applications -> MSAA" node, and add class name of your control, which should be recognized as MSAA object (e.g. "DirectUIHWND"). Also note, that "MSAA Open Application" plug-in should be installed.




    Once expanded via MSAA, the "DirectUIHWND" object exposes properties, methods and child objects you can use to work with it.





    In your Object Browser you should see something like that: 




    ...Window("SHELLDLL_DefView", "ShellView", 1).List("Items View").ListItem("$Recycle.Bin")

    ...Window("SHELLDLL_DefView", "ShellView", 1).List("Items View").ListItem("my test file.txt")

    ...Window("SHELLDLL_DefView", "ShellView", 1).List("Items View").ListItem("My_Test_Folder")

    and so on...




    But here comes next problem.


    List("Items View") MSAA object shows only visible child objects in the Object Browser tree (e.g. children, with Visible = true). Also List("Items View").ItemCount shows only number of visible children ListItem.




    To find some item, which is not visible on screen, you should do some scroll with mouse wheel on you control, and review the children objects of List("Items View") object. 




    We are working a lot with files/folders, which are displayed in Explorer window on all Win platforms, but approach, which was described above, too much slows down scripts execution speed.




    Can someone suggest a different approach to solve this problem?




    Thanks!

  • Hi,


    TestComplete provides special support for standard dialogs. The following script opens a file in Notepad:



    function Test1()

    {

      var  notepad;

      var  comboBoxEx32;

      var  edit;

      notepad = Sys.Process("notepad");

      notepad.Window("Notepad", "*").MainMenu.Click("File|Open...");

      notepad.Window("#32770", "Open").OpenFile("c:\\temp\\work.txt");

    }



    Please see the OpenFile Method and Working With Open File and Save File Dialogs help topics for more information.


  • Hi Stephen,





    Do you face any issues when you use the approach I suggested? Could you please describe them more specifically?


  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    You can leverage name mapping for your dialogs and alias all the dialogs to the same alias declaration.  Your name mapping for the dialogs can then use "Conditional Mode" (http://smartbear.com/support/viewarticle/12852/) to indicate to map the different dialogs to the same alias so that, no matter what OS you're using, it will always find the dialog.  I did something similar in my previous "life" to great success as my development environment for automation was Windows 7 but the playback was on Windows XP.  NameMapping effectively saved my life in that case.