Data Access Worldwide Knowledge Base
Article Text
Many DataFlex programmers who upgrade from character-mode DataFlex to Visual DataFlex are experiencing problems with one of character-mode DataFlex developers' favorite commands: chain. This article explains what chain was designed for, why it is obsolete in Visual DataFlex, and what to use instead of chain.
The design of Chain was for the DataFlex character-mode runtime to put aside the current program's code and load another program's code and execute that in the same process. This works pretty well in DOS, in part because DOS is not a multitasking operating system, but also mostly because the entire environment is controlled by DataFlex. In other words, there are no other DLLs, and there is no code other than the DataFlex runtime in the environment. There's also no concept of processes and task switching.
However, in Windows, which is a multitasking operating system, this sort of design does not work. As far as Windows is concerned, you're not really starting a new program: the chain-ed program is running in the same process (Windows will return the same
value for the GetModuleHandle Windows API function). This wreaks havoc in Windows, as well as any third party DLLs, ActiveX controls and so on, because they're not aware that the chain-ed to program a different program, they all think it's still the same (chain-ed from) program. This can manifest itself in many different ways. Sometimes it can even be very difficult to see these problems in a reliable manner.
The problems experienced with chain are not bugs in Visual DataFlex, and they cannot be "fixed" in VDF. The problems occur because chain is trying to do something that other components of the program are not, and cannot, be aware of. These problems simply occur because chain was not designed and never intended for use on an operating system like Windows or to be used with other processes like DLLs.
An example of these types of internal issues that can wreak havoc is a DLL that uses global variables. Consider a counter that keeps track of how many times you have called a specific function in your program. When chain is used, it's not really starting a new process; this means that the counter will keep on counting up from whereever it is. The DLL is not aware that it is executing a different program after the chain command was called, so the counter is not reset.
For these reasons, the chain command has been made obsolete. In VDF, chain is a left-over from character-mode, and should no longer be used. RunProgram can often be used as a direct replacement. RunProgram does not suffer from any of the problems of chain in a Windows environment. RunProgram starts a new process, so that the whole environment is aware of the new program.
If you are using chain wait, the recommendation is to see if you could use RunProgram instead. The two features are virtually the same, but chain has known problems, as described above, which RunProgram does not have.
In most cases you can just switch chain wait for RunProgram Wait and it will work just fine. But Chain also has some extra features, such as sharing record buffers and global integers, so sometimes it's not as easy as simply replacing chain with RunProgram. In those circumstances, you need to resort to different approaches for passing on such information between the two programs.
You can, for example, use command line options to pass a record id and have the receiving program manually find the particular record instead of sharing the record buffer. You can also pass on the values of the specific global integers on the command line, and manually set them in the receiving program instead of relying on shared global variables. There are many alternative ways of communicating between the two programs.
This article is recommended reading for the following keywords and/or categories:
chain wait runprogram
Email this Article
Email this Article to a Colleague
Send Feedback on this Article to Data Access Worldwide
Copyright ©2010 Data Access Corporation. All rights reserved.
| The information provided in the Data Access Technical Knowledge Base is provided "as is" without warranty of any kind. Data Access Corporation disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Data Access Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Data Access Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply. |