User Tools

Site Tools

Navigation:  Upgrading from prior Clarion versions >====== Clarion Win32 Migration Tips ====== Previous pageReturn to chapter overviewNext page


This topic is designed as a quick reference for developers and programmers who are migrating applications to Clarion Win32 from versions prior to Clarion 6.

The following changes were documented in the Clarion 6 release notes and should be reviewed by developers migrating applications from versions prior to Clarion 6.

Change of EVALUATE Error Codes

Default Splash Procedure Icon

DLL Initialization

Embedding code when closing a Process procedure

General Rules regarding your data and the new Thread Model

Global EIP Classes

Global Pools and GROUPs

Heap Overflow Error when migrating applications

ISAM File Access Performance

Large Window structures

Migrating Large Dictionaries and Data Paths

Migration of hand coded project files


Remove MDI attribute from dockable toolbar windows

RTF Text Control and RTF Control Templates

TXA Comparison Technique

Use of Error Managers during DLL Initialization

Use of ABC Classes with the Clarion template chain


trumpet.jpg Change of EVALUATE Error Codes

The error codes posted by the EVALUATE statement have been modified in Clarion 6:

1010 - formerly 800: Bad expression syntax

1011 - formerly 801: Unknown identifier in the expression

1012 - formerly 802: Mismatched POPBIND


trumpet.jpg Default Splash Procedure Icon

Loading a C55 application into Clarion 6 that uses the default splash screen will produce a link error that says 'C55.GIF' not found.

The best workaround is to simply change the icon, or just delete the old splash procedure and add a new one using the Clarion 6 default.

trumpet.jpg DLL Initialization

Enforcement of threaded variables in multi-DLL applications is critical in Clarion 6 and later versions. In versions pior to Clarion 6 if your file definitions are set to “open in current thread” in the dictionary (the THREAD attribute is set in the FILE definition), your file definitions in your DLLs must match that definition. To ensure this, examine each application's global file control section, and make sure that all of your files are set to 'ALL THREADED' in the Threaded drop list.

Regarding files that are defined across multiple DLLs (e.g., a Customer file defined in a data DLL and again in another DLL), you CANNOT mix thread and non-threaded attributes on the same files in a multi-dll application. Although this programming style was permitted in earlier versions of Clarion, the initialization of preemptive threads will not allow this in Clarion 6.

You can use either setting, thread or non-threaded, as long as it's consistent across all DLLs and your executable. And, of course, mixing the threaded and non-threaded attributes among different files is still permitted.

trumpet.jpg Embedding code when closing a Process procedure

The Process procedure used with the ABC templates calls ThisProcess.Close() after ThisWindow.Kill has fully completed. Consequently, any object created in the scope of the process window which is called inside ThisProcess.Close() will cause a GPF since the destructor for that object will already have completed during ThisWindow.Kill.

In Clarion 6, the ViewManager class destructor used with the ProcessClass is now calling ThisProcess.Close() to make sure that the VIEW is closed. This was not needed in previous versions of Clarion because local VIEWs were automatically closed when a procedure exited. With the new threading model, local VIEWs are now not automatically closed until the thread is destroyed.

There is a distinct chance that any call to a local object inside ThisWindow.Close() will cause a GPF when exiting the process procedure, because it has already been disposed by the time the final ThisProcess.Close() call happens.

Anyone embedding source code in the ThisWindow.Close() method needs to add some kind of condition surrounding any call to a local object that stops it happening after ThisWindow.Kill() has occurred.

trumpet.jpg General Rules regarding your data and the new Thread Model

1.  Use the THREAD attribute on global Data (file, class, group, queue or simple types).

2.  Use the THREAD attribute on module Data (file, class, group, queue or simple types).

3.  Avoid the use of static variables.

4.  Don't pass the address of anything within a START command - this was a

common trick used by people to communicate between threads.

If you do any of the above you must make them thread safe. Refer to the Multi Threaded Programming PDF for detailed information on this process.

Local data (including classes that are normally instantiated locally) is automatically threaded (unless you put the STATIC attribute on it).

See Also:

Data Initialization Schema

Special Considerations for One-Piece (Single) Executables

OLE Controls and the new thread model

trumpet.jpg Global EIP Classes

Some applications that use edit-in-place in prior versions will migrate to Clarion 6 with the EditClass defined as the default edit-in-place class. In Clarion 6, this class needs to be changed to the EditEntryClass. To do this, access the Global Properties in the Application Generator. In the Classes tab, press the Browser button and change the default edit in place class from EditClass to EditEntryClass.




trumpet.jpg Global Pools and GROUPs


In Clarion versions prior to 5.5H, if a GROUP were defined in the dictionary's Global Pool without using a prefix, the prefix of the Global Pool (which is required) would be used in its place.


For example:


GLOB:GROUPONE GROUP,PRE() !`GLOB' is the prefix of the Global Pool





With Clarion 6, this same group will be generated without the Global prefix, and would appear as follows:

GLOB:GROUPONE GROUP,PRE() !`GLOB' is the prefix of the Global Pool




Since it is possible to define multiple Global Pools in your dictionary, a second Global Pool could be created as follows:


GLO2:GROUPTWO GROUP,PRE() !`GLO2' is the prefix of the 2nd Global Pool





Which in Clarion 6 will be generated as follows:


GLO2:GROUPTWO GROUP,PRE() !`GLO2' is the prefix of the 2nd Global Pool





This will cause the compiler to generate “Duplicate Label” warnings when migrating your applications.


The solution to this is to add a prefix to each of your GROUPs that share common label names across Global Pools.


For example:


GLOB:GROUPONE GROUP,PRE(GLOB) !`GLOB' is the prefix of the 1st GROUP





GLO2:GROUPTWO GROUP,PRE(GLO2) !`GLO2' is the prefix of the 2nd GROUP







trumpet.jpg Heap Overflow Error when migrating applications

During the early testing phase of Clarion 6, it was noted that some applications would post a “Heap Overflow” error when attempting to load applications of prior Clarion versions into the Clarion 6 IDE.

In nearly all cases, the solution is to first export the application to a text file (TXA), and then import it as text into the Clarion 6 environment.


trumpet.jpg ISAM File Access Performance

Some users have reported that if there is any experience of slow file accesses when using ISAM files, switching off the Defer opening files until accessed in the application's Global Properties - File Control will improve the performance.

trumpet.jpg Large WINDOW structures

In each control that is populated in a WINDOW structure in Clarion 6, there is now extra information for each control that takes about 10 extra bytes per control. This may cause some large and complex windows to not import properly from prior versions.

You may need to shorten some use variables or remove controls and create/destroy them at runtime or redesign the window to make it a bit more efficient.

trumpet.jpg Migrating Large Dictionaries and Data Paths

One of the nice new features of this release is a new system property:


With this, you can set your data file names in the dictionary to have no path in them, and then set the data path once in the program start up. From there, each file will inherit the common data path.

With that in mind, dictionaries created in a prior version will continue to work. The only issue is where file names and structures are stored exclusively in a DLL and referenced from the EXE. In prior versions, you had to define these objects in the EXE as EXTERNAL, and did not care if the files in this object were threaded or not. In this release, any objects that contain threaded data must add the THREAD attribute to the object definition.

Mixing threaded and non-threaded data in an object is dangerous and likely to cause problems.

trumpet.jpg Migration of hand coded project files

All projects compiled in Clarion 6 are 32-bit. Prior to loading older project files (.PR or .PRJ) into the Clarion 6 environment, load them into your favorite text editor and make sure that the following pragma entry is set properly:

#system win32

You can also load the project into the project editor. When you press OK to close the project, the #system pragma will be automatically updated.

trumpet.jpg POINTER(File) and POSITION(File)

The behavior of POINTER(File) is different for different file systems. For example, the first record in a TopSpeed file doesn't have a pointer value of 1.

It may still be safe to use for certain file systems, but for code portability, POSITION(File) is the way to go.

trumpet.jpg Remove MDI attribute from dockable toolbar windows

In Clarion 6, the MDI attribute is no longer permitted on any toolbar window that is dockable (windows with the DOCK and TOOLBOX attributes).


trumpet.jpg RTF Text Control and RTF Control Templates

To all developers that used the RTF Control template in prior versions of Clarion, this template has been deprecated, and is now replaced by the new RTF Text Control template.

The RTF Control template is still included for users who wish to migrate their applications to Clarion 6, and avoid unnecessary template warnings or errors. Upon migration to Clarion 6, you will notice a message in the Actions tab of the control's properties that notifies you that this template should be replaced. You will also see a warning at source generation time that notifies you that this template has been deprecated.

trumpet.jpg TXA Comparison Technique

If you are having troubles with applications converted to Clarion 6 using DLLs, there is a possibility that the DLL that was converted contained hidden information (like a third party library) that was not detected by the conversion process.

To confirm this, try the following:

Export the old DLL application to TXA format (Export Text)

Export a new Clarion 6 DLL application to TXA format (Export Text)

Next, compare the TXA's up through the first procedure (i.e., the program/global area). This might give you some ideas regarding information converted from an old application that may not be compatible, or does not exist in Clarion 6.

trumpet.jpg Use of Error Managers during DLL Initialization

A change has also been made in the DLL initialization of ABC-based applications. During initialization, the DLL uses a LocalErrors Class rather than the Global executable's GlobalErrors Class.

For example, in a multi DLL application and during initialization of the DLL containing Global data, if errors need to be posted to the error manager, they will be posted to the DLL's local error manager (LocalErrors) instead of the application's global error manager. The reason for this is that the DLL's error manager is not set to use the application's error manager until after initialization of the DLL. During initialization, the DLL uses the LocalErrors Manager rather than the executable's GlobalErrors Manager. Inside the DLL Init procedure, extra code is generated to assign GlobalErrors, and also assign the passed error manager to the already initialized file managers and relation managers.

Developers who modified the global error manager in their applications using DLLs will now need to be aware of the new local error managers that are applied.

trumpet.jpg Use of ABC Classes with Clarion template based applications

This release of Clarion includes many new template features that are now supported in the Clarion template chain, but rely on the use of the ABC Library Classes. Examples of this are the support for RTF Text Controls, Pop-up Calendars, and the new enhanced edit-in-place.

The linking of the ABC class support requires the following default pragmas settings to be included in the project system:



Template support to automatically include these pragmas can be found in the Global Properties Classes tab by checking the Enable the use of ABC Classes check box.

migration_issues_to_clarion_6.htm.txt · Last modified: 2021/04/15 15:57 by