The defaultw.ico is the icon file for your application’s generated windows. It is the image that you see on the task bar when you minimize your application window. This .ico file resides wherever your CA Gen directory is located. You can replace this default icon with your shop’s icon. That way, your icon will automatically be associated with the system’s windows each time the code is generated. Following this practice will eliminate the need to change any icons in your window design settings. You can see the difference in Figure 33 below.
LOC.EXTERNAL_LIB c:\models\extrn
This is the directory where CA Gen expects to find the external code [stub] used in the model during link time.
If the stub is not in this location, you will receive this type of error during the link step of the build: fatal error LNK1120: unresolved externals
OPT.IEF_BITMAP z:\iefmodel\win\bitmaps
The IEF_BITMAP environment variable set within the operating system specifies where the bitmap directory is located. If there is no IEF_BITMAP environment variable, the token OPT.IEF_BITMAP is used. If OPT.IEF_BITMAP is not enabled within the build tool (default), then the build tool looks in the model’s bitmap subdirectory. If this directory doesn’t exist, the module's source directory is used.
If the bitmaps are not in the specified location, you will receive this type of error during link: error RC2135 : file not found: .\..\BITMAP\<bitmap name>
OPT.BUILD_SRC YES
GUI applications require DBMS specific startup files (stubs). If OPT.BUILD_SRC is set to YES, the build process will copy the DBMS specific stub source to the build directory and precompile, compile, and link the stub. Otherwise, the DBMS specific stub executable will be copied into the build directory and renamed to {Load module}.EXE. If this option is set to yes, the generated window manager resource file is also bound with the {Load module}.EXE to provide the executable with the application icons. Valid values are [YES | NO]. This token is disabled and the default value is set to NO. (please see timestamp of load module executables in this unit)
Clear Screen Transaction Code There is one transaction code for every screen or non-screen transaction. It allows the user to execute the load module from a blank screen by entering the transaction code. If you want the user to be able to execute the transaction from a blank screen, then you must define a transaction code. If not (such as for server transactions), there is no need to define the transaction code – a dialog flow trancode will suffice. The trancode must be defined to the teleprocessing monitor (e.g. CICS, IMS, Transaction Enabler) by the System Administrator in addition to defining it to CA Gen.
Dialog Flow Trancode There is one dialog flow trancode for every screen, server, or non-screen transaction. Each screen/nonscreen must have the same value for its trancode and its dialog flow trancode. The CA Gen dialog flow trancode is internal to the CA Gen-generated application – it is not defined to the teleprocessing monitor.
Q: How does the application know what window to execute first if they are all packaged in one big load module?
“A: By appending the desired TRANCODE at the end of the executable parameter “c:\usdanfc\nfcapps\pods.exe <trancode>” The trancode would be the code entered during packaging of load modules. Remember that each client procedure step is assigned a trancode. Other parameters could be added to the path as shown below: c:\usdanfc\nfcapps\ <load modulename.exe> <trancode> <command> <command> could be up to 80 characters. The value of the last parameter will be in the CA Gen special attributes. You can then use this value after entering the procedure.” Carol Marie Cooper, Computer Associates, Consultant
Expand All Views
When generating, whether it may be window code or cooperative code, ALWAYS select VIEW EXPAND ALL when expanding load modules (Figure 35). Expand would just give you the procedure step level. Expand All will expand all the way down to the action block level. If you don’t properly expand you may get an error stating that it cannot find the components the load module needs to successfully build.
“Remember…MS SQL Server wouldn't work and we had to compare the environment variables? Remember how we wish we could print it out? Well, I found out how. Go to the Start menu and select Windows NT Diagnostics under Administrative Tools (Common). It will bring up different tabs and select the one for Environment. Then at the bottom of the window, there's the Print PB. You can even print to a file…” Catherina Fuh, Computer Associates, Consultant
When functions (i.e. SetVisible, BackgroundColor, etc.) are not working properly, for instance objects you want to be invisible are visible and the colors are not changing, try reregistering the CA Gen .reg files that deal with the CA Gen function and application libraries.
To re-register the CA Gen Functions
1. Register the WROAF.REG file 2. Register the WRU410n.dll (version 4.1) 3. Register the OLEPRO32.dll 4. Register the RTT.REG
The wroaf.reg contains pointers to two important type libraries. WROA0000.tlb (application library) and WROF0000.TLB (function library)
REGEDIT HKEY_CLASSES_ROOT\TypeLib\{0C8F36F1-848E-11CE-9C08-02608CDA5EE3} = COOL:Gen Application Interface Type Library HKEY_CLASSES_ROOT\TypeLib\{0C8F36F1-848E-11CE-9C08-02608CDA5EE3}\4.0 = COOL:Gen Application Library HKEY_CLASSES_ROOT\TypeLib\{0C8F36F1-848E-11CE-9C08-02608CDA5EE3}\4.0\0\win32 = c:\coolgen\WROA0000.TLB HKEY_CLASSES_ROOT\TypeLib\{0C8F36F1-848E-11CE-9C08-02608CDA5EE3}\4.0\HELPDIR = c:\ief HKEY_CLASSES_ROOT\TypeLib\{EBD084A1-E46C-11CE-8F94-0020AF9B5FED} = COOL:Gen Functions Interface Type Library HKEY_CLASSES_ROOT\TypeLib\{EBD084A1-E46C-11CE-8F94-0020AF9B5FED}\4.0 = COOL:Gen Functions Library HKEY_CLASSES_ROOT\TypeLib\{EBD084A1-E46C-11CE-8F94-0020AF9B5FED}\4.0\0\win32 = c:\coolgen\WROF0000.TLB HKEY_CLASSES_ROOT\TypeLib\{EBD084A1-E46C-11CE-8F94-0020AF9B5FED}\4.0\HELPDIR = c:\ief
In order to check what is registered, open the ActiveX Control Test Container (Figure 36) that comes with Microsoft C++. In the main window, click on File… Register Controls to view the control registry. You can even register and unregister files using this utility.
Unfortunately, the ocx controls added to the model during design time are not stored as object files on the encyclopedia. Therefore, like bitmap files, they have to be manually managed. When opening the model that uses ocx controls, make sure that the ocx file is in the model’s OLE directory. It must be in the same path as it was when the control was added during the initial design of the window. Otherwise, the pointer to this file may be lost and will become invalid in your action diagram statement.
The OCX file and SST file must be moved to the directory where the dlls are deployed. The SST file is used by your ole/ocx control to access/manipulate the control. This must be placed in a non-read only directory (local or network), otherwise your ole/ocx will cease to function. With CA Gen 5.0 and higher, the SST file is going to be packaged with the executable file, and therefore does not need to be deployed.
Have you ever wondered why your executables’ program date and time stamps do not change? The system’s load module.exe files are actually just renames of the database stubs that you selected during generation.
If you have DB2 as your target database, CA Gen will “grab” the stubdb2n.exe file and rename it to the name you have assigned to your load module during construction. This stub contains specific database scripts (start, stop, commit) for the database you are using. This is only useful if you have an online application using a local database. Please see build tool setup section for more information on OPT.BUILD_SRC parameter.
stubdb2n.exe 27KB 8/4/97 6:43 AM stubinfn.exe 64KB 8/4/97 6:43 AM stuboran.exe 25KB 8/4/97 6:43 AM stubs95n.exe 28KB 8/4/97 6:43 AM stubsybn.exe 82KB 8/4/97 6:43 AM stubxdbn.exe 28KB 8/4/97 6:43 AM
“In [Cool:Gen] 5.1, some of the default settings have changed from 4.1a. One of the default settings is the OPT.BUILD_SRC in the NT build tool setup. With the default setting of NO, the client executables generated will not have a current timestamp and it will not pickup the defaultw.ico for the icon. To get around this, all you have to do is change the setting in the IT setup [win32itm.tgt] file to YES. This does create a little more work when compiling and building executables, but if you need a custom icon and an accurate timestamp on the executable it is worth the extra work.” David McGrady, MIS Analyst III, Information Resources, Lowe's Companies, Inc.
If your system utilizes external action blocks, CA Gen needs to know which EAB stubs go with which external programs. To create this association, go into the construction… generation and pull up the type of code you being used.
If your system utilizes EABs, the stub will appear in the generation list. If you double click on the stub, and action block properties dialog box will appear (Figure 37). The source name is the name that was used when the external library was built.
LOAD MODULE.EXE ONLY MOVE ONCE
LOAD MODULE.DLL MOVE ALL THE TIME
LOAD MODULE.REG ONLY MOVE ONCE
LOAD MODULE.SST MOVE ALL THE TIME
LOAD MODULE.OCX ONLY MOVE ONCE
The load module.reg file contains the path information for all your executables. When this file is registered, the path inside this file, figure 38, will be the path stored in the registry.
…
HKEY_CLASSES_ROOT\CLSID\{D74E6110-AFD9-11D2-B291-000000000000} = Composer (Ver 4.0) HKEY_CLASSES_ROOT\CLSID\{D74E6110-AFD9-11D2-B291-000000000000}\LocalServer32 = C:\USDANFC\NFCAPPS\PDL0.exe /Embedded HKEY_CLASSES_ROOT\CLSID\{D74E6110-AFD9-11D2-B291-000000000000}\ProgID = PDL0.Composer.Application.1
<!-- wikipage stop -->