ID Number: Q67673
3.00
WINDOWS
Summary:
Two separate applications sometimes need to cooperate in the Windows
environment. Two Windows applications may work in tandem, or a Windows
application may require the services of a non-Windows application.
This article examines the issues involved when a Windows application
requires notification that another application has completed its
processing.
More Information:
First, the following constraints should be considered:
1. Windows was not designed to synchronize the operation of a Windows
application with a non-Windows (MS-DOS) application in any mode
(real, standard, or 386 enhanced).
2. Windows does not provide any automatic way of determining if
another application has finished, or was run correctly.
This first section included below discusses techniques that can be
included in code that is written for cooperating applications (for
example, when both are Windows applications, and when one is for
Windows and the other is not). The second section listed below
discusses techniques to apply when the other application is beyond the
programmer's direct influence.
Techniques to Use for Cooperating Applications
----------------------------------------------
The following are two options that can be used if the programmer is
developing both applications and each runs under Windows:
1. The two applications can communicate through a dynamic data
exchange (DDE) messaging protocol that the programmer establishes.
DDE is explained in Chapter 22 of the "Microsoft Windows Software
Development Kit Guide to Programming," version 3.0.
2. Each application can register the same application-specific message
text with Windows via the RegisterWindowMessage() function and
receive a numeric value for the message. The terminating
application then sends this value to the other application. This
can be accomplished by broadcasting the message to all windows in
the system. See the documentation for the PostMessage() function
in the "Microsoft Windows Software Development Kit Reference
Volume 1" for more information.
When one of the cooperating applications that is being developed does
not run under Windows, the following must occur:
1. When the MS-DOS application completes or encounters a fatal error,
it should write a message into a specified file in the TEMP
directory.
2. The Windows application should then perform the following steps:
a. Use the SetTimer() function to create a system timer that will
fire at desired intervals. The estimated completion time of the
function is one possible interval. Another would be "estimated
time to first possible failure" if the MS-DOS application will
be writing an error string for the Windows application to
display.
b. Initiate the execution of the MS-DOS application with the
WinExec() function and continue with any normal processing.
c. Upon receipt of the timer message, the TEMP directory can be
checked to determine if a message file is present. If the file
is present, the message in the file is parsed to see if
termination was due to success or failure.
Techniques to Use for Third-Party Applications
----------------------------------------------
For a third-party application, the steps taken must access information
that is entirely external to the MS-DOS application. One possible
way to implement this method is to use the title of the WINOLDAP
window to determine if the application is still running. In this case,
the following steps should be taken:
1. Use the SetTimer() function to create a system timer. Timer
messages should be at least a few seconds apart. This allows
WINOLDAP to create its window and begin processing.
2. In real and standard modes, Windows application processing stops
while the MS-DOS application is processing. In enhanced mode,
Windows' behavior depends on the settings in the program
information file (PIF) that corresponds with the MS-DOS
application. For more information about the allocation of the
processor when an MS-DOS application is running, query on the
following keywords:
prod(winsdk) and WinExec() and dependent
3. When the timer message is received, the FindWindow() function is
then used to search for the caption of the MS-DOS application's
window. The caption is created from the "Window Title" section of
its PIF file, or if it is blank or not found, the filename of the
old application. If the caption is no longer present, the
application is deemed to have completed its processing.
Another possible solution is to create a batch file in MS-DOS that
checks for error level information returned from the program, and then
creates files in the TEMP directory. The Windows application can then
check for these "result" files to determine the MS-DOS application's
status.
The following batch file creates a sentinel file named BEGIN.TMP.
Until this file is deleted, the MS-DOS application is considered to be
running. Successful completion creates the result file, END.TMP, and
then BEGIN.TMP is deleted. An execution error creates the result file
named STOP.TMP, and then removes BEGIN.TMP.
1: echo start > %TEMP%\begin.tmp
2: MyDosApp
3: if errorlevel 1 goto bad
4: if errorlevel 0 goto good
5: goto end
6: :bad
7: echo bad > %TEMP%\stop.tmp
9: goto end
10: :good
11: echo good > %TEMP%\end.tmp
12: goto end
13: :end
14: del begin.tmp
15: goto end
A system timer is employed as above to direct the Windows application
to check for the existence of the sentinel and result files.
If it is necessary for a MS-DOS application to communicate with
Windows, then contact the SoftBridge company. SoftBridge can provide
additional information on its product offerings. Contact information
is listed on page 107 of the "Windows Shopping" book, supplied with
the Windows version 3.0 retail product.