Kbase P17011: WINOLDAP does not respond on Windows 98
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
1/8/2003 |
|
Status: Unverified
SYMPTOM(s):
WINOLDAP does not respond on Windows 98
CAUSE:
Winoldap is basically a dos shell that is invoked when you are in
Windows, and need to do something in DOS, it's not specific to Progress.
FIX:
How to Determine When Another Application Has Finished
--------------------------------------------------------------------------------
The information in this article applies to:
Microsoft Windows Software Development Kit (SDK) versions 3.0, 3.1
--------------------------------------------------------------------------------
SUMMARY
Two separate applications sometimes need to cooperate in the Windows
environment. Two Windows-based applications may work in tandem, or a
Windows-based application may require the services of a an application that is
not based on Windows.
This article examines the issues involved when a Windows-based application
requires notification that another application has completed processing.
MORE INFORMATION
First, the following constraints should be considered:
Windows was not designed to synchronize the operation of a Windows-based
application with an MS-DOS-based application in any mode (real, standard, or 386
enhanced).
Windows does not provide any automatic way to determine if another application
finished, or ran 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-based 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:
The two applications can communicate through a dynamic data exchange (DDE)
messaging protocol that the programmer establishes.
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 PostMessage().
When one of the cooperating applications that is being developed does not run
under Windows, the following must occur:
When the MS-DOS-based application completes or encounters a fatal error, it
should write a message into a specified file in the TEMP directory.
The Windows-based application should then perform the following steps:
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-based application will be writing an error string for the Windows-based
application to display.
Initiate the execution of the MS-DOS-based application with the WinExec()
function and continue with any normal processing.
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-based 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:
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.
In real and standard modes, Windows-based application processing stops while the
MS-DOS-based 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-based application is running, query on the following
keywords:
prod(winsdk) and WinExec() and dependent
When the timer message is received, the FindWindow() function is then used to
search for the caption of the MS-DOS-based 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-based application can then check for these "result"
files to determine the MS-DOS-based application's status.
The following batch file creates a sentinel file named BEGIN.TMP. Until this
file is deleted, the MS-DOS-based 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-based application to
check for the existence of the sentinel and result files..