Favourites

Search

C++ Builder

Q: No file header access factories have been registered" problem in BCB. What now?

In BCB, developing an Embedded Server App, I got a "NexusDb: No file header access factories have been registred. You may need to include nxseAllEngines in your USES Clause.[$3C36/15414]."

Add to the project source, or one of the cpp files of your project, the following line:

#pragma link "nxseAllEngines"

Alternatively, you can add this OBJ directly to the Project, using the Project Manager.

Q: I'm getting a strange error (AV, or it is simply not working) when using a function declared virtual in the Delphi source. What to do?

A: In BCB5 and BCB6 there are some compiler bugs that end up screwing up the class virtual table, but, fortunately, the solution is pretty simple. In the classes that you have discovered this problem, move the public part before the private/protected part of the class. Be aware that the propierties, in most cases, should stay after the protected and private parts (as they usually depend on private functions). Another solution is to change the "virtual" keyword to "dynamic" for those functions. Doing this will impact the performance of the functions, but, hopefully, in most cases this won't be noticed, and less if you are working with a unmodified compiled server (in a client/server setup, of course). For both ways, the packages must be recompiled with the changes made.

Q: When using a function that has as parameter a PnxByteArray I'm getting a linker error.

When compiling the Delphi unit, the compiler doesn't do the same as the header creation engine when dealing with the unit. The compiler creates the binary taking a PnxByteArray as an unsigned char[2147483647] *, as the following dump from the compiled OBJ shows:

The problem here is that a PnxByteArray is not an unsigned unsigned char[2147483647] *, as the translator correctly does, in nxlltypes.hpp:

typedef Byte *PnxByteArray;

but only a unsigned char *. So, the solution here is to create an alias for the correct function. The way to create this is, as found in the

borland.public.cppbuilder.vcl.components.writing:

<==quote===

a) tdump both sides or the unsresolved external problem:

tdump -m myhintwindow.obj myhintwindow.dmp

tdump -m C:\Windows\System32\VCL60.bpl VCL60.dmp

b) find the name-mangeled names:

grep -i hintwindow.*ncpaint *.dmp > manglednames.txt

c) paste the names correction into an alias in the .cpp source:

//place in myhintwindow.cpp

#pragma alias "@Controls@THintWindow@NCPaint$qqrpv" =

"@Controls@THintWindow@NCPaint$qqrui"

===quote===>

In this case, instead of vcl60.bpl, you will dump the obj from the nexus delphi unit wich defines the problematic function. If you use this function

in several cpp files, then you can add the #pragma alias in the header file for the delphi unit. Thanks to Craig Farrell, from the borland.public.cppbuilder.vcl.components.writing newsgroup, for pointing out the solution.