Calling DDT-program from Cobol-program ??

[Fim Wästberg]

I want to use PB för building screens with DDT and then call that program as a DLL from a program written in another language (Cobol). That is no problem. But… I want to do a conversation with the screen from the calling program. When the user put something in an entry-field, then leaving the field using Tab or the mouse, the contol should be transferred to the calling program with information of what the user had put into the entry-field and the name/number of the field. And after that, the calling program can transfer control back to the DLL for another user input.

Is this possible??

[Michael Mattias]

>Is this possible??

Sure.

PB creates standard Windows DLLs.

There's really no difference between calling functions in a DLL from a Pb-created EXE and an EXE created with some other product.. or vice versa, as long as each module IMPORTs and EXPORTs what it needs from the other.

Just ask yourself how you would call functions in your PB-created EXE when you have trapped a notification message in your dialog procedure which just happens to be in a DLL. Same rules apply.

MCM

[Michael Mattias]

However, I would not design that way. I'd do my editing in the dialog procedure and return the results of the dialog with one call.

    CALL   "MyScreen" USING 
              BY VALUE  X  SIZE 4 
              BY REFERENCE    Y , Z 
      RETURNING   WS-RESULT-CODE

Something like that. You may have to call functions (ENTRYs) in your COBOL-Exe to assist with the editing before returning, but that's to be expected.

MCM

[Cliff Nichols]

Ditto

Think of the other language as the parent and your dll as the child.

If you want to watch the child, then either keep an eye on it, or a way for the child to say "Hey I did something" and have the parent check to see what they did.

Either way, has, was, and will be done

Its just a matter of style, and what it is that you want to achieve???

[Kev Peel]

You need to be careful using DDT with a DLL, there are some restrictions that are not readily apparent when using DDT statements between differing modules (ie. a DLL and an EXE are classed as separate modules).

One example is you can't call the DLL to create child dialogs then manage them from the main program (EXE), the DDT statements will fail. I had some code that did this and had to work around it by creating the child dialogs from within the main program.

This info applies to PB 9.0's DDT only, I don't have any info about other versions..

[Michael Mattias]

there are some restrictions that are not readily apparent when using DDT statements between differing modules (ie. a DLL and an EXE are classed as separate modules).

Somehow I don't think he'll be using a whole lot of 'DDT' syntax in his COBOL Exe.....

[Kev Peel]

Yet another helpful reply

[Michael Mattias]

Ok, so maybe this is more helpful:

>This info applies to PB 9.0's DDT only, I don't have any info about other versions..

Applies to ALL versions of compiler since DDT's introduction in PB/DLL 7 (6?)

I just found PB/DLL 6.0 on an archive disk, and DDT was supported in that version. I think it may have been new in that version since the help includes " Welcome to PowerBASIC's powerful new Dynamic Dialog Tools™. ")


However, there are no restictions on the use of DDT statements against dialogs/controls created in the same module, regardless if that module is an EXE or DLL.

MCM

[Kev Peel]

I wasn't talking about when DDT was first introduced.

There are different restrictions with the different compiler versions, it's no secret that newer compiler versions are more strict with regards to what DDT statements can be used with.

However, there are no restictions on the use of DDT statements against dialogs/controls created in the same module, regardless if that module is an EXE or DLL.

That much is obvious.

[Michael Mattias]

There are different restrictions with the different compiler versions, it's no secret that newer compiler versions are more strict with regards to what DDT statements can be used with

Not really. Some DDT statements just happen to work across modules because the implementation selected does not utilize the runtime for control data (eg 'control set text.')

However, neither cross-module nor use of DDT syntax against non-DDT-created windows use has never been officially supported.

In other words, 'dumb luck' can make selected misuses "work" - or at least, seem to work.

MCM