Highlighted
Absent Member.
Absent Member.
9443 views

[archive] AcuCobol tips & tricks

[Migrated content. Thread originally posted on 29 October 2003]

Here is a little collection of the things I've figured out, if you are curious about them, buzz me here in the forum and I'll explain how I did it:

general
a generalized background threaded search
highlight background color for current cell in a screen section
using C$Redirect, create logger which logs file I/O to a special file (Vision)
using I$IO, a DTS program which converts from your vision file to another source like (sql database)
random number generator
advanced date parsing, manipulation functions
match the color of the Acucorp Treeview item to the backgroud color of the Treeview (looks much better!)

subclassing
implement file drag/drop to AcuCobol floating windows
floating forms that hover over your AcuCobol form (and move with the main form)

VC++
smart dynamic memory allocation (array manager, qsort, no more sort files!)
convert vision file system I/O statements to SQL statements
File I/O driver for PostgreSQL
C++ program that parses XFD files
C++ program that generates FD, SL from SQL table

Delphi/C++ Builder
call Delphi graphical progress bar for progress.
call Delphi form from a AcuCobol application (as a floating window)
use Delphi Report Generator (Ace Reporter) from a Cobol program
use Delphi to manage the clipboard
bind Vision files to Delphi data aware components (including grids)
0 Likes
28 Replies
Highlighted
Absent Member.
Absent Member.

RE: [archive] AcuCobol tips & tricks

a generalized background threaded search

random number generator

advanced date parsing, manipulation functions

match the color of the Acucorp Treeview item to the backgroud color of the Treeview (looks much better!)

floating forms that hover over your AcuCobol form (and move with the main form)

Thanks
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] AcuCobol tips & tricks

Do you have a C compiler? If so, which one(s)? Some of these examples require a C compiler (especially subclassing) and others will be easier.

I'll start up with a little discussion about calling dlls from the AcuCobol runtime then post the examples every couple of days when I can scrounge the time.

Also, I should have mentioned it, but my assumption is that you are working on MS Windows platform. I'm not sure if these approaches will work on other platforms or not (can you call .so objects on a *nix platform as you can for .dlls in windows?).

It's AcuCorp's Visual BasicIsh method of calling dll methods that makes extending the runtime so easy. Otherwise, you have to be able to recompile the runtime, which also requires a C compiler. This works great, and is slightly faster than dll calling methods, but I perfer not to do it because:

1. It's not as modular
2. Requires VC++ compiler (on windows)
3. Forces you to use the release version of the vendor suplied libraries. In other words, if you are relying on a bug fix or other custom behavior that AcuCorp may have provided in the form of a special version of the library, you will not be able to recompile without losing the vendor supplied changes.
4. Working with dlls is just plain easier.

The main issue with calling dll methods is that passing improper parameters can cause an access violation which will crash the runtime. There are a couple of general techniques to avoid this which is very important if you work on a large project with several developers.

Paramater Safety Trick #1 use copybook.
Trading coding elegance for safety, this approach will usually pass parameters in a structure to a C routine. Remember to becmoe familar with how your C compiler aligns variables and to deal with your non terminated stings.

Your copy book will look something like:
01 Function-Params.
05 Param-1 unsigned-int
05 Param-2 pic x(32).

Your function call will look something like:

move val-1 to Param-1.
move string-2 to Param-2.
inspect Param-2 replacing spaces by low-values
call "MyFunc" using Function-Params.

Paramater Safety Trick #2 use front end program.
Trading speed for safety, this involves writing a Cobol front end program which will in turn call your C program. Using the system methods C$NARG and C$Paramsize, you can check the parameters before calling the real routine. This is my perferred approach. Another nifty trick is you can use this method to 'overload' your functions by varying the paramcount to call different routines. You can also terminate your nulls here (by convention) if desired.

Now you can
call "MyFunc" using val-1, string-2.

This is just a little backgrounder to help you with some of the examples that are about to follow. In some cases, you can apply a pure COBOL approach by using the Win32 API (which is exposed via the system dlls) to make system calls.
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] AcuCobol tips & tricks

As you may have noticed, setting the background color of a treeview in the runtime does not set the background color of the treeview items. Depending on your color set up, this may not get you the color you want.

Here is the Win32 API command to set a treeview's background color:

SendMessage(hHandle, TVM_SETBKCOLOR, 0, dwColor);

If you fire this at your treeview you will indeed find it sets everything to a matching background color.

dwColor is the 32 bit color value to set. Use the RGB() macro to set it up from the red, green, and blue values or hard code it.

In COBOL, each time you display your screen section (or your treeview), use the following code (this is just one way to do it):

inquire My-Treeview system handle in TV-Handle.
call "SetBackColor" using TV-Handle, TV-Color.

call "SetBackColor" using TV-Handle, TV-Color.

TV-Handle is usage unsigned-int.
TV-Color is also unsigned-int...either hard code the value or calcualte it from the Red, Green, and Blue Values.

"SetBackColor" is a dll method I created (with my C compiler) which has exactly one line:

__declspec(dllexport) void _cdecl SetBackColor(HANDLE* pHandle, DWORD* pColor)
{
SendMessage(*pHandle, TVM_SETBKCOLOR, 0, *pColor);
}

I have to dereference the pointers because the default calling convention is by reference. I perfer to do it this way to avoid forcing the other programs to use 'by value' syntax in the call.


This particular function is possible to do without using a C compiler. You can make the SendMessage call directly to the Win32 API from COBOL. This has been documented elsewhere in the forum, so check it out there 🙂

Everytime you redisplay your treeview (or screen section), you have to re-call this method.

Hope this helps (more to follow),
Merlin
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] AcuCobol tips & tricks

Yes I am working on MS Windows platform and yes I can get a C++ compiler if need be, though I am not profitient in C++.

When you say it forces me to use the release version of the vendor suplied libraries, I am not sure what you mean. Are you suggesting that we rebuild AcuCobol dll's?
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] AcuCobol tips & tricks

Originally posted by SRFish
When you say it forces me to use the release version of the vendor suplied libraries, I am not sure what you mean. Are you suggesting that we rebuild AcuCobol dll's?


At my company we had a situation where our application relied on some non standard behavior in one of the older versions of the AcuCobol runtime. AcuCorp graciously compiled a version of the runtime which was based on the current version but also had our custom behavior. However, they did not give us the library files necessary to rebuild the runtime ourselves. Becuase of that, at our company we tend not to rebuild the runtime so we are not dependant on the released versions of the .lib files.

Merlin
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] AcuCobol tips & tricks

Originally posted by MerlinM
At my company we had a situation where our application relied on some non standard behavior in one of the older versions of the AcuCobol runtime. AcuCorp graciously compiled a version of the runtime which was based on the current version but also had our custom behavior. However, they did not give us the library files necessary to rebuild the runtime ourselves. Becuase of that, at our company we tend not to rebuild the runtime so we are not dependant on the released versions of the .lib files.

Merlin


Thanks for the clarification. We don't rebuild the runtime either. That limits us to a perticular version which we do not want to do. We would rather use seperate dll's and use the call function or make use of ActiveX controls.
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] AcuCobol tips & tricks

I could used some good info about the drag and drop


Thank you!
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] AcuCobol tips & tricks

I am sure interested to have some info.
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] AcuCobol tips & tricks

Thanks so much to MerlinM for his contributions to the forum, I do however have some comments.

There is no such thing as "Visual BasicIsh" method of calling DLLs.

There are two ways one may link to libraries in Windows, those are static link and dynamic link. The latter which is using those libraries with the extension DLL (Dynamic Linked Library). This technology is not founded in VB, it is not even founded in Windows, but were first introduced in Windows in version 2.0 providing as a means to reduce the load on memory.
A DLL is in fact from the OS perspective considered a normal executable, with the one major exception that it cannot "live on its own". It's only way of loading is through an application.

It is true that using DLLs does not require a VC++ compiler. Even so, if you were doing a static link with a .obj or .lib file it does not have to be Visual C++. It may as well be Borland Delphi, Borland C++ Builder, Visual Basic. All of these also support static linking, as ACUCOBOL-GT does it. ACUCOBOL-GT for Windows is built with Visual C++, but that doesn't mean it is the only language supporting static link.

If you want to learn more about DLLs, sign up for the training on January 19th.

One may as well keep in mind that the entire Windows API and thus also its functions are not object oriented, so we are speaking C, not C++.

All languages that do a dynamic load, be it Visual C++, Visual Basic, ACUCOBOL-GT, Borland Delphi uses an API function named LoadLibrary to load the DLL. This provides the smooth gate to use functions and features on demand.

With the services of the Windows API and COM, there is very little, that you cannot do from ACUCOBOL-GT, in most cases, no need for a C compiler.

A couple of things I would like to mention regarding your examples:

! Do remember that most of the Windows API utilizes the pascal
calling convention, e.g. you must:
SET ENVIRONMENT "DLL-CONVENTION" TO 1.
This because the runtime is default to the cdecl parameter passing convention.

! Do remember that the datatypes signed-int, unsigned-int are COBOL datatypes, e.g. they are not native to the platform. Thus, you cannot use them directly on the Windows API. If you choose to go by these datatypes, you will need to compile your applications using the compilerswitches: -Dw32 -Dl4. So the compiler provides the correct size and alignment. I myself prefer to use PIC 9(9) COMP-5 for this, avoiding the need for compiler switches.

! Also note that all Windows API functions are not necessarily using a 32 bit integer, some use 16bit integer, some even a byte.

If you want to learn more about Windows data types and their counterparts in ACUCOBOL-GT or how to interface API functions, check out the training in San Diego on january 19th.

Regarding your Treeview background color example. For those interested in this, the RGB macro he refers to, is a C construct. If you look in the sample directory of your ACUCOBOL-GT installation, you will find the program GraphPrn.cbl, in which there is a CALC-COLORREF section. This will show you how to construct a color with this kind of data. And, btw, COLORREF is really a DWORD, hence, a PIC 9(9) COMP-5 will transport your data back and forth safely.
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] AcuCobol tips & tricks

Originally posted by gforseth
.....If you want to learn more about Windows data types and their counterparts in ACUCOBOL-GT or how to interface API functions, check out the training in San Diego on january 19th.


For those of us who will not be able to get to San Diego it would be very valuable to have a list of Windows data types and their counterparts in ACUCOBOL-GT. Could this list be made available on this forum?:cool:
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] AcuCobol tips & tricks

QUOTE-START
For those of us who will not be able to get to San Diego it would be very valuable to have a list of Windows data types and their counterparts in ACUCOBOL-GT. Could this list be made available on this forum?
QUOTE-END

I am very tempted to say that is your punishment for not attending... But I suppose I am soft at heart 🙂

Here is the most common ones:

WINDOWS, ACUCOBOL-GT
DWORD, PIC 9(9) COMP-5.
LONG, PIC S9(9) COMP-5.
ULONG, PIC 9(9) COMP-5.
WORD, PIC 9(4) COMP-5.
BYTE, PIC X.
LPxxx, PIC 9(9) COMP-5.

Where xxx in LPxxx is any variable. The clue here is that the LP is an abbreviation for Long Pointer. In Windows Long Pointers (LP) is in fact a DWORD, thus PIC 9(9) COMP-5.

Having said this, there is still a lot to learn, so if you are thinking about serious Windows API programming, you should think twice before you let such an opportunity pass. There is a lot of information and not at least sample code of both simple and extensive use of the Windows API included in this training, which will not be released for general availability outside of this training.
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.