Announcement

Collapse
No announcement yet.

Calling DDT-program from Cobol-program ??

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Calling DDT-program from Cobol-program ??

    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??
    Fim Wästberg

  • #2
    >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
    Tal Systems Inc. (retired)
    Racine WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      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.

      Code:
          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
      Michael Mattias
      Tal Systems Inc. (retired)
      Racine WI USA
      [email protected]
      http://www.talsystems.com

      Comment


      • #4
        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???
        Engineer's Motto: If it aint broke take it apart and fix it

        "If at 1st you don't succeed... call it version 1.0"

        "Half of Programming is coding"....."The other 90% is DEBUGGING"

        "Document my code????" .... "WHYYY??? do you think they call it CODE? "

        Comment


        • #5
          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..
          kgpsoftware.com | Slam DBMS | PrpT Control | Other Downloads | Contact Me

          Comment


          • #6
            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.....
            Michael Mattias
            Tal Systems Inc. (retired)
            Racine WI USA
            [email protected]
            http://www.talsystems.com

            Comment


            • #7
              Yet another helpful reply
              kgpsoftware.com | Slam DBMS | PrpT Control | Other Downloads | Contact Me

              Comment


              • #8
                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
                Last edited by Michael Mattias; 8 May 2009, 05:38 PM.
                Michael Mattias
                Tal Systems Inc. (retired)
                Racine WI USA
                [email protected]
                http://www.talsystems.com

                Comment


                • #9
                  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.
                  Last edited by Kev Peel; 8 May 2009, 07:37 PM.
                  kgpsoftware.com | Slam DBMS | PrpT Control | Other Downloads | Contact Me

                  Comment


                  • #10
                    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
                    Michael Mattias
                    Tal Systems Inc. (retired)
                    Racine WI USA
                    [email protected]
                    http://www.talsystems.com

                    Comment

                    Working...
                    X