Known Problems & Limitations


4D interpretor

In interpreted mode, some variables are retyped after a call to a plugin. In their routines definitions, plugins tell 4D what kind of parameters they expect, and 4D changes the type of parameters according to that. This concerns every plugin, not only DynamicStructure.

For instance: the routine RoutineOfThePlugin accepts a Long Integer as parameter #1:

C_REAL($aReal)
RoutineOfThePlugin($aReal)
=> After the call, $aReal has became a Long Integer.

You may loose information, since a long integer is 4 bytes long, and a real is 8 bytes long. In fact, if after the call you write in $aReal a number greater than MAXLONG, 4D will « troncate » the value to fit in a Long Integer (4 bytes).

It could be really problematic in case of array: imagine a routine that expects an integer as parameter. You want to use the current selected element of an array as the parameter, so you write something like:

ARRAY TEXT(theArray ;10)
. . . later in the code . . .
RoutineOfThePlugin(theArray)
=> after the call, theArray became a Long Integer !

The array theArray has became a Long Integer variable: we have lost the acces to its previous content.

In such situation, it could be very usefull to use a temporary buffer:

ARRAY TEXT(theArray ;10)
. . . later in the code . . .
$buffer:= theArray
RoutineOfThePlugin($buffer )

Please, note that when a plugin needs an array, and not a fixed-size variable, there is no typecasting: an Integer array does not become a Text array or a something else.

Also, note that in compiled mode, there is no problems.


Known limitations of particular routines (see the documentation of the routines)

4D must be reloaded after using these routines:


Not allowed in compiled environment:


Not allowed on 4D Client:


Not allowed on 4D Server:


About every routine of the plug-in: