invoking multiple winforms from visual cobol programs (unmanaged and managed)

I have Program A that calls Form1 (which will only display one table entry).  User puts in a search key, presses Search key, and the data is passed to Program B, which looks up the entry and returns that to Form 1.

User may then press List button.  Control goes to Program B, which will then call Program C.  Program C reads through the database and fills an array with appropriate records, then attempts to invoke Form2 (list screen using data grid view).  However, it stops at  'invoke Form2 "NEW" returning anotherInstance' (I have to stop debug to end program).  Form1 remains where it is, and Form 2 never displays.  Not sure how to fix this...

Program A -> Form1

Form1 -> user presses Search button -> ProgramB

ProgramB gets data, returns it to Form1

Form1 -> User presses History buttonto get list of all records with the record key -> ProgramB

ProgramB -> ProgramC builds array with data and invokes Form2

ProgramC remains on line that attempts to instantiate the object, Form1 remains and Form2 does not appear (not surprising, as object is never instantiated).




  • The subject of this post mentions both unmanaged and managed COBOL programs. Can you elaborate on where the unmanaged programs come into play here?

    How are programs A, B and C being called, thru the COBOL CALL statement or are they classes being instantiated?

    Is there an exception being raised on the invoke?

    Try wrapping it in a TRY CATCH block:

        set anotherinstance to new Form2

    catch myexception as type Exception
       display myexception::Message


  • Hi Chris,

    ProgramA is unmanaged and invokes Form1, whichis managed.

    Form1 will call ProgramB, also unmanaged, when most buttons are clicked.

    ProgramB, depending on what code Form1 sends it, will do various processing and exit, returning control to Form1.

    However, if ProgramB is sent a code to list history, it will call another unmanaged cobol program, ProgramC.  ProgramC will gather the details for the records and store them in an array.  It will then attempt to instantiate a new object, Form2, via invoke.  Form2 is managed code.  It does not get beyond invoke new.  And it doesn't like the try/catch block.  Thanks.

    Maybe new forms should all be called from the first one?

  • This seems like a horrendous way to code your application and is probably almost impossible to debug between managed and native programs.

    Why don't you recompile the native programs as managed code? Is this because you are using Oracle Pro*COBOL and would mean that you would have to convert to using OpenESQL and ADO.NET? We added the directive SQL(PROCOB) for use with ADO.NET to make this easier for you.

    How is your managed application setup? Are Form1 and Form2 part of the same project and therefore will reside in the same assembly? Since when you invoke the managed Forms from native you actually are calling thru the COM interface there may be a problem with having 2 instances running at the same time. I am not really sure what will be going on with the main GUI thread when this is invoked in this manner.

    This is definitely not a recommended approach. Having some sort of a traffic cop program that would handle all the form I-O would be a better approach I believe.

  • Yes, it might be that...

    ...but let me explain what we are trying to do. This is a real project I am working on but also a prototype for what we want to do in the near future.  That is, be able to use all of our unmanaged COBOL 'backend' code but replace the netexpress screens with Winforms.   Our netexpress screens often have many other screens that are displayed 'from' them.

    And yes, it is partly because we are using Oracle Pro*COBOL (and because there are still some issues, for instance, SQL return codes are still different between the two), we don't want to convert to  OpenESQL and ADO.NET yet.  If we go to release 4, I understand all should be transparent, but Kris does not want to have to recompile/retest everything at the moment, as we are in the middle of another project. 

    Form1 and form2 are not in the same project.  They are separate projects.  I could have ProgramB gather all of the data and return it to Form1 (not sure how, as this is new to me), and then somehow have Form1 call Form2 - which must be able to be done, somehow. 


  • The latest product release is now at V5.0.

    The SQL(PROCOB) directive turns on a sqlcode mapping facility whereas you can control which codes are returned to your program, OpenESQL sqlcodes or Oracle sqlcodes.  This is controlled by the mfpcocds.txt file, locates in %ProgramData%\Micro Focus\sqlcodes by default.

    This is covered in the docs here:

    It is recommended that you compile your entire application as managed code and convert the Pro*COBOL code to OpenESQL. This is your best way to move forward in the future.

    Using a mixed mode of unmanaged code calling managed Windows Forms thru a COM interface is going to be a nightmare to maintain.

    If you wish to keep your data access using Oracle Pro*COBOL then you should at a minimum separate the layers of your application so that you have a managed UI layer handling all of the screen I-O that calls into an unmanaged data layer which handles all of the database access.

    I would recommend that you speak to your Account Manager about contacting our Professional Services team who can aid you in this initial application design phase of your project.


  • Okay.  Thanks for all of the information.  I will bring it up for discussion.


  • Is there an example of code that does this?  I looked for   but it can't be found.  I already have everything working using one winform.

    Thank you.

  • I fixed the attachment on the original article for MultiFormsDemo so you should now be able to download it.

    Article can be found here:


  • Thanks, Chris! I think this will help immensely.