sttngds9,
According to Microfocus, you can't really do that. What they recommend is that you create a VB exe with the form you want, then compile your COBOL program as a DLL, and make calls to the COBOL DLL functions from the VB exe.
When I first heard this, I was like "You've got to be kidding," but after thinking about it, what difference does it make which language calls which, so long as you have the GUI to front-end your COBOL.
I have not done this myself yet, but years ago (before Visual Basic), I wrote a whole bunch of DLLs in COBOL, which worked fine. I was able to call them from BASIC/C/COBOL/PASCAL with no problems.
| support | Self-Service | Net Express Examples and Utilities | Samples | Mixed Language
and look for an example called: VB-Call-COBOL.zip
If this works for you, please write back and let me know because I have a couple of COBOL programs that really need this same sort of thing, in order to get rid of a bunch of "Accepts" at the front of the programs.
Let me explain better to you. I know that I can't call a form directly, but I can call a Vb classe who call a Vb form. That's the way that I am doing.
I know that example you mentioned, I have this example, and I know how to VB call a program Cobol. But sometime I need that a Cobol program call a VB program to show to the user that he is processing something. So, I do a call from a class Vb, make a Invoke in the class, but the problem I have is when class Vb call a Form VB non-modal. Cobol gives error, he want the Form modaless. And I don't want that. I need the Cobol accepts A Form non-modal. And when I try to Animate the Cobol Program he works perfect. He accepts both the Forms VB nom-modal or modal.
So what I have forget to Animate work, and when I execute don't ?
We have a long experience calling VB from Micro Focus Cobol. As far as I can say, it worked with VB4 16 Bit and the old 16 Bit Cobol Compiler and it works with 32 Bit Cobol and VB.NET. But there is no way making VB5 or VB6 show non-modal forms when called from Cobol - period.
(The reason is somewhere at the Microsoft side and if you have too much free time you can ask them about that ;-)
I'm using AcuCoobl to do very similar things to this, and we just make VB OCX controls and then embedd them in a Cobol program.
If the OCX has an interface, then we embedd it in the screen seciton. If it doesn't, and it's just some sort of business logic, I need to create the objects using the CREATE verb and reference them by their addresses.
Doesn't MF have something like this? They were doing OCX stuff even before ACU became ACU, weren't they?
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.