Hey I dont really know much about c++ (so far my laguage is delphi) But I was woundering is it a good language if i wish to interat with other programs? and is there anywhere I can find out hiow to do these types of task (I'd guess it requires sending commands to programs) The tye of thing I'm aiming for is:
a program to send things like '17 + 2 =' to a program like calculator, then return the value of 19 to my program. Of course this is not what i'm planning on eventually doing, (as a calculator program is easy) Just to get the hang of controlling other apps.
I guess another example would be. set the bold to true on wordpad etc.
Are these things possible? or is there a better language to aim at for these tasks?

The answer is that in general C++ would be as good as Delphi for this sort of thing.

It is not so much the language that is at the heart of what you wish to do but the facilities presented to you by these other programs.

As you are talking about MS Windows programs in your question I shall assume this is the type of system you are interested in.

Microsoft's method for remotely controlling one program from another revolves around COM (Component Object Model), specifically around that part called Automation or OLE (Object Linking and Embedding) Automation.

The idea is that such programs present an automation interface to other programs who then obtain a reference to the running program's automation interface(s) from where it can make calls to do things to the other program. Exactly what you can do depends on what facilities the creators of the other program deemed important and added to the automation interface(s) they provided - which of course could be none at all.

To find out about what, if any, automation interfaces are available you would need to obtain and read the documentation - often the developer oriented documentation - for the application in question. Of course having read such documentation you may well find that at least some of what you wish to achieve cannot be done as the automation interface(s) supplied are deficient for your requirements in some way. Ho hum, such is life.

Another option is that an application has its own SDK (software development kit) that allows extensions or plug-ins to be written for it. Maybe it uses another standard technology - such as Microsoft's ActiveX controls which are also based on COM. Or maybe they provide a custom extension interface specific to their application. In such a situation you can write an extension that communicates with your application - of course you then have to deploy this extension with your application and update the other application during installation of your application - if, that is, the application needing the extension is installed on the target system.

Quite often applications supply both a simple automation interface and an extension interface for those who need to go beyond the automation interface.

Now as to languages suitable for doing these things. Automation is designed to be accessible from all sorts of languages - such as Visual Basic and maybe some scripting languages. It presents a way to determine the available functions by name with their parameters also similarly described, (called a despatch interface) and can also provide a more usual calling method - a so-called 'v-table' interface (C++ style, although also callable from C and probably Delphi, though I am not at all sure about Delphi - that's your area of expertise not mine!).

As for extension interfaces - if the extension interface is a custom one then you will have to obtain the SDK that goes with it - and these are usually for C / C++ as they contain not just the libraries to link against but also the header files describing the functions and other objects and definitions required to use the extension interface. This means you will require a compatible language and maybe even one of a specific set of supported compilers - usually the MSVC++ compiler is supported, and maybe one or two others - the Borland C++ offering being a possibility here. Of course if you are lucky and put in some work converting header files and the like you may possibly be able to use something like Delphi even thought it is not officially supported, however it may be that things like static library file formats trip you up. If the SDK functions are provided as C functions in a DLL you may be in with a  chance - after all this is how the Win32 API functions are presented to the world.

If the extension interface uses something like ActiveX then so long as your language can produce such components you should be alright.

Of course once the extension is written you can go back to your favourite language to write your application - as presumably you would have written the extension to be able to communicate with your application using only techniques available and compatible to both the extension's implementation and your application's implementation.

The final possibility that I can think - if the application has no provided automation or extension support - is that you poke data directly into a running application. To do this you would require information on the running program - specifically you require window handles to the windows that make up the application - and remember all dialogs and controls are windows and that they may be created dynamically so the dialog handle you had last time it was open may not be the handle you need the next time it is opened. You will also need to know the control and menu IDs for controls so you can spoof notification messages and the like from them to dialogs and windows. So you need to know exactly how the application in question is structured so you can determine the correct window handles to obtain (find main application window, then locate window XXX as one of its children then see if dialog YYY is open as a child of that child etc. etc.).

The only other way is that you might be able to hook the application using one or more of the Win32 hooks - however most of these are called in response to an event of some sort and give a hook function the chance to modify data or react in some way to the event - whereas you also need to pump messages to an application.

In these cases you are using the Win32 API directly and C++ is obviously a natural language to use as the Windows SDK is delivered for use with C and C++. However, if you can use the Win32 API directly from the likes of Visual Basic then I am sure it can be done from Delphi. If you have not already looked into this then you might check to see if you have any language support included for calling Win32 API functions from a Delphi application.

Here is a simple example in C++ for your example calculation 17 + 2 = 19 performed on the Windows calc.exe Calculator Accessory application. Note that it was originally laid out using spaces - so should be viewed using a non-proportionally spaced font such as Courier New, and that posting through AllExperts may ruin this formatting - sorry!

// Send 17 - send button clicks for 1 and 7 buttons to the Calc dialog:
 SendMessage( Calc_Handle
         , WM_COMMAND
         , MAKEWPARAM(Digit_1_Id, BN_CLICKED)
         , LPARAM(Digit_1_Handle)
 SendMessage( Calc_Handle
         , WM_COMMAND
         , MAKEWPARAM(Digit_7_Id, BN_CLICKED)
         , LPARAM(Digit_7_Handle)

// Send + - send button click for + button to the Calc dialog:
 SendMessage( Calc_Handle
         , WM_COMMAND, MAKEWPARAM(Operator_plus_Id
         , BN_CLICKED)
         , LPARAM(Operator_plus_Handle)

// Send 2 - send button click for 2 button to the Calc dialog:
 SendMessage( Calc_Handle
         , WM_COMMAND
         , MAKEWPARAM(Digit_2_Id, BN_CLICKED)
         , LPARAM(Digit_2_Handle)

// Send = - send button click for = button to the Calc dialog:
 SendMessage( Calc_Handle
         , WM_COMMAND
         , MAKEWPARAM(Operator_equals_Id, BN_CLICKED)
         , LPARAM(Operator_equals_Handle)
// Get the result from the calculator display static text control:
 int const ResultMaxLen(10);
 char resultBuffer[ResultMaxLen+1];
 GetWindowText( Display_Handle, resultBuffer, ResultMaxLen );  

Note that this is a quick and dirty example only - not production quality code.

SendMessage and GetWindowText are Win32 API functions. WM_COMMAND, BN_CLICKED are defined values for Windows messages and notifications, LPARAM, HWND are Win32 types and MAKEWPARAM a convenient macro to stuff 16-bit values into the low and high halves of a 32-bit value. Note that this style is consistent with a C rather than C++ API, however C++ has been designed to be as compatible with C as possible so can easily use the Windows SDK directly.

The xxx_yyy_Handle values - such as Operator_equals_Handle - are window handle values to windows and controls in a specific execution instance of calc.exe. The xxx_yyy_id values - such as Operator_equals_Id - are the dialog control ids associated with control windows. These values were obtained by executing calc.exe and using a tool provided with MSVC++ called Spy++ that allows all the windows on the desktop to have their properties inspected. Note that if I close the instance of calc.exe and re-ran it I would have to find the new handle and id values I required, update the program and re-built it. Not a good thing. However in a production piece of code you would use the likes of FindWindowEx et al to dynamically locate the windows and extract the information required.

If you wish to know more about any of these Microsoft development topics then I suggest you take a browse of the MSDN site and the MSDN library (online at the MSDN site). Start at http://www.msdn.microsoft.com/.

Good hunting.  


All Answers

Answers by Expert:

Ask Experts


Ralph McArdell


I am a software developer with more than 15 years C++ experience and over 25 years experience developing a wide variety of applications for Windows NT/2000/XP, UNIX, Linux and other platforms. I can help with basic to advanced C++, C (although I do not write just-C much if at all these days so maybe ask in the C section about purely C matters), software development and many platform specific and system development problems.


My career started in the mid 1980s working as a batch process operator for the now defunct Inner London Education Authority, working on Prime mini computers. I then moved into the role of Programmer / Analyst, also on the Primes, then into technical support and finally into the micro computing section, using a variety of 16 and 8 bit machines. Following the demise of the ILEA I worked for a small company, now gone, called Hodos. I worked on a part task train simulator using C and the Intel DVI (Digital Video Interactive) - the hardware based predecessor to Indeo. Other projects included a CGI based train simulator (different goals to the first), and various other projects in C and Visual Basic (er, version 1 that is). When Hodos went into receivership I went freelance and finally managed to start working in C++. I initially had contracts working on train simulators (surprise) and multimedia - I worked on many of the Dorling Kindersley CD-ROM titles and wrote the screensaver games for the Wallace and Gromit Cracking Animator CD. My more recent contracts have been more traditionally IT based, working predominately in C++ on MS Windows NT, 2000. XP, Linux and UN*X. These projects have had wide ranging additional skill sets including system analysis and design, databases and SQL in various guises, C#, client server and remoting, cross porting applications between platforms and various client development processes. I have an interest in the development of the C++ core language and libraries and try to keep up with at least some of the papers on the ISO C++ Standard Committee site at http://www.open-std.org/jtc1/sc22/wg21/.


©2017 About.com. All rights reserved.