Highlighted
Absent Member.
Absent Member.
5934 views

[archive] calling a vb dll from acucobolgt v6

[Migrated content. Thread originally posted on 26 October 2004]

Hi!
Can acucobol-gt v6 call a vb dll?
Thanks,
Tom
0 Likes
20 Replies
Highlighted
Absent Member.
Absent Member.

RE: [archive] calling a vb dll from acucobolgt v6

You can call a Windows standard DLL, whether it has been made in vb, vc++, c, delphi or whatever doesn't matter.
Note however, the common trap most people run into in this regard is that they create an OO dll, this is not Windows standard, and is not supported by ACUCOBOL-GT.
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] calling a vb dll from acucobolgt v6

Gisle Forseth,

I understand from the suppport folk that you are THE guru when it comes to interfacing with VB.

1)When the vb programmer creates a vb dll, what does he have to do so that:
a) it can be called by acucobol ?
b) it can call acucobol ?

2)Is there an advantage of using VB instead of one of the C
languages, or vice versa, when dealing with acucobol ?

Please calm my concern that once I hire a vb programmer, we wont find out too late that a vb dll and an acucobol-gt v6 acu cant talk to each other.

Blessings,
Tom
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] calling a vb dll from acucobolgt v6

I am afraid the techies are exaggerating a bit 🙂

But yes, I do know quite a bit about Windows programming, interoperability and ACUCOBOL-GT. That is however, apart from ACUCOBOL-GT a language independent matter.

When it comes to VB, I know the language in the sense that I can read VB source and I can make simple applications. Give me a week or two and I should probably become a seasoned VB developer too. But, as of current, I have yet not ever made a DLL with VB, nor do I have VB installed, so I can hardly make any promises. My expertise apart from ACUCOBOL-GT lies in VC++ and Delphi.

Now, having said that, I would be surprised if it was impossible to make a Windows DLL with VB. World is full of surprises however.

But, the question you should ask the VB guy is simple:
Can you make me a STANDARD WINDOWS DLL that exports these functions <>. They should use the WINAPI calling convention and not use any kind of OO.

If the programmer cannot give you a flat yes or no to that question, there is two alternatives; A) He is not a seasoned VB programmer or B) it is just not possible.

Why not consider Borland Delphi? A very good language, and it do allow you to make DLLs.

Anyway, if you insist on using VB, and it is impossible to make a Standard Windows DLL, you do have the option of making a windowless ActiveX in VB, this can then be used from ACUCOBOL-GT.

I do however have a burning question, what do you want to use VB for?
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] calling a vb dll from acucobolgt v6

Gisle,

Thank you for your reply.

The matter of VB as the language of choice was suggested by the prospective developer of the program I would be calling. That's why my last message to you asked "Is there an advantage of using VB instead of one of the C languages, or vice versa, when dealing with acucobol ?"

I would like to use a language that
1) will easily work with acucobol
2) is common enough that if the original developer falls off the earth, another developer can easily substitute.

Other than delphi, which language would you recommend?

When calling a dll, what limitations are there as to the amount of data (bytes) that can be passed to and from it?

May I contact you via email instead?

Thank you again for your input,
Tom
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] calling a vb dll from acucobolgt v6

Visual Basic does not create win32 dll's. It creates activex dll's. This means they must be registered in the registry and called buy acucubol via acitvex/com interoperability. This is not difficult to do and the nice thing about VB is that it is extremely popular and there are a ton of programmers who know it and a very large developer community on the web. The code examples on the web are vast, and you'd be hard pressed not to find an example of something you need to get done.
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] calling a vb dll from acucobolgt v6

Thanks Dan!
Blessings,
Tom
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] calling a vb dll from acucobolgt v6

Hi Tom.

I've created some ActiveX Dlls using VB6 - registered them on another computer using AcuCorp GT 6.10 prgrams and the AcuCorp programs could make use of the methods of the dll.

Do you have some sample code? If you wish I could send you a small demo.


VB src (and DLL) and a AcuCobol GT 6,10 sample program that uses it. Will have to wait until I'm back at work on Monday.


Brent
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] calling a vb dll from acucobolgt v6

Brent,
You're a blessing! Yes, please send me what you have that would give me a head start.

Thank you VERY much.
Tom
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] calling a vb dll from acucobolgt v6


Last message to you asked "Is there an advantage of using VB instead of one of the C languages, or vice versa, when dealing with acucobol ?"


Sorry, I oversaw that. However, no, there are no advantages of VB compared to other languages regarding interoperation with ACUCOBOL-GT.

It is correct as Dan states, there are a huge amount of VB programmers out there, so you will probably be better of choosing that language. Having said that, it is likely that a large number of these are also more hobbyists, than professional, so be careful to demand documentation.

1) will easily work with acucobol


I would say VB, C#, Delphi, C and C++ all interoperates fairly easily with ACUCOBOL-GT. C, C++ *might* be less readable though.

2) is common enough that if the original developer falls off the earth, another developer can easily substitute.
...
Other than delphi, which language would you recommend?


I would rather say, find a developer that knows to do his/hers work properly. E.g. write clean code, document functions, give straight forward instructions on how to do this and that and finally, documents his/hers work. That is much more important than the language which is being used.
There is COBOL code out there, written decades ago, spaghetti style, undocumented. There is C code out there, written some time, neatfully designed and carefully documented functions, followed by complete instructions on how to build and deploy.

Which would you prefer?

I myself would opt for the C code in this case. Even though I still tend to state my knowledge of COBOL above C. But it would take me longer to understand an undocumented heap of COBOL than a well documented structured C code.

However, I would put VB, C# and Delphi equal. They are all fairly readable languages. In choosing between these, it is hard to say. I have a personal weakness for Delphi, C# was made to have the best of all worlds, VB is considered to be the most widespread language of today (PC world that is).
When I was young (okay, I am not that old though...), during my days at the university, there was a saying "Nobody were fired because they had bought IBM". I guess you may take that onwards and today say: "Nobody is fired because they had chosen Microsoft".
Which of C# and VB then? C# is young, has the future, but still needs commitment from a broad user base. VB is settled, there are tons of sample code, a large user base.
Despite I don't fancy VB overly, I suppose it will be the best choice, in a close race between the three.

I could talk at length of this topic, limited place though. If you are heading into Windows development, and expect to operate in proximity with the API and interoperability in general, you may want to consider participate one of my trainings; "Advanced Windows Programming". There are two coming up quite soon now, New Jersey (15, 16 Nov) and Dallas (18, 19 Nov). Further away, there is probably going to be on in San Diego at the end of January and UK first week of March.

When calling a dll, what limitations are there as to the amount of data (bytes) that can be passed to and from it?


Virtually none. Because, DLLs just like calling COBOL programs operates on passing addresses, thus, if your ACUCOBOL-GT has a variable of 1024Mb and you want to let a DLL access it, you may do so by passing the address and the DLL will work on it, right in your applications data segment. What should be more of a concern, is the number of parameters. When designing functions in DLLs, it is a good habit to limit the number of function parameters to a few.


May I contact you via email instead?


I generally prefer to discuss in the open, particularly so for this issue, as it is a topic of wide public interest. However, in my last email I asked you if you could elaborate what you wanted to accomplish with the DLL, if you want to write me in an email to tell me this, it is fine. Feel free to post me in private here, or on my company email.
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] calling a vb dll from acucobolgt v6

Originally posted by DanM
Visual Basic does not create win32 dll's. It creates activex dll's...


Excellent Dan. Thanks, you are a resource!

I do find it a bit weird though, that one cannot make a standard Windows DLL with VB. Odd!

Gisle
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] calling a vb dll from acucobolgt v6

Gisle,
Yes, I found that strange as well when VB 6 first came out. My only thought was that perhaps Microsoft was being over confident about Activex and assuming developers would rather use it than standard DLL's, and so they decided to only have VC++ be able to create standard DLL's.
This idea was somewhat confirmed when the MS .NET Framework came out and once again, only VC++.NET has the option to create native code and standard DLL's while the other .NET languages like VB.NET, C# only create manged code and .NET assembles. Once again, strange. But I guess that's Microsofts way of trying to push new technology. 😉
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.