I would expect FoxPro and derivative applications to be no different to other Windows applications in that they would be composed entirely of windows that you access via window handles. The fact that they utilise COM/ActiveX objects probably doesn't help you unless they also expose a public interface.

As for accessing the child windows (controls) of the application window, Win32::GuiTest provides a PushChildButton method that allows you to specify either the handle or the text of the child window. For simple purposes you wouldn't even need to enumerate the child controls, just specify the text of the button you want to push. For example:

#!perl
use strict;
use warnings;

use Win32::GuiTest qw(FindWindowLike SetForegroundWindow);

my $hWnd = (FindWindowLike (0,qr/My FoxPro Application/))[0] ;
die "No window found\n" unless $hWnd;

SetForegroundWindow ($hWnd);

PushChildButton( $hWnd, "PushMe!" );
[download]

I have also had some success using SendKeys to queue messages for the main application window. With this approach it is not important which child control actually dispatches the message, just that the application must be capable of responding to the keyboard (a usability test in itself!)

Beyond this you may need to investigate Win32::API which allows you to call native Windows API functions such as SendMessage() etc. But frankly I wouldn't go this far myself, and if I did it would be with a language better suited to this kind of chicanery.

Thanks for your reply Edward, I find however that ActiveX controls, at least, aren't accessible by handles... or at least FindWindowLike doesn't return the child handles of said controls. The furthest I can go with win32::GUITEST is to hit the reflection window.

Window Found(Text : '' Class : 'CtlFrameWork_ReflectWindow' Handle: '853406')

I picked up Programming Windows with MFC 2^nd Ed and in Chapter 21 it talks about ActiveX controls and how the container object can contain windowless controls and that interface messages are intercepted and passed through the reflective window. So now I know why the application looks like an opaque wall to my recursive windows handle traversal.... there weren't any win handles!

So...now to finish reading and figure out how to talk with and get information from the reflective window to talk to the controls beyond.

So, I am still searching for clues if anyone has already done work in this area. For those of you reading the thread the page # referring to windowless controls is pg 1284 in section Windowless Controls.

Cpan has a module Wx::ActiveX I am going to investigate ... worst case I can converse with its author and crack open my copy of extending and embedding perl and create a Win32::ActiveX module for generic use. Or (fingers crossed ) I can use the module unmodified. Has anyone used this particular module?

Just to share with the other monks my e-mail answer:
-------------------------------------

To have a better control of the ActiveX control you can use the method GetOLE():

 
  my $flash = Wx::ActiveX::Flash->new( $parent_frame , -1 , wxDefaultP
+osition , wxDefaultSize );

  use Win32::OLE ;
  my $OLE = $flash->GetOLE() ;
 
  my $version = $OLE->Invoke('FlashVersion') ;
  ## or just:   my $version = $OLE->FlashVersion() ;
  
  print "$version\n" ;
[download]

Note that the code above is for wxPerl (Wx), and not Win32::GUI.

If you want to keep using Win32::GUI, take a look in the module AxWindow at:
http://perso.club-internet.fr/rocherl/Win32GUI.html
(I don't know why it's not in CPAN yet).

The module AxWindow make the same thing that Wx::ActiveX does for Wx.

Regards,
Graciliano M. P.
-------------------------------------

Graciliano M. P.
"Creativity is the expression of the liberty".