Delphi 2010 compatibility

[cariad]

Hello,

I didn't see anything in rev679, so here's a quick patch to allow Delphi 2010 compilation.

I didn't check everything, but design time packages install fine, compilation is Ok, and the test application I use seems to works fine with both Firebird 2.1 and PostgreSQL 8.3

[peha84]

I have an error:
[DCC Fatal Error] ZConnection.pas(83): F1026 File not found: 'ZDbcOracle.dcu'

Embarcadero RAD Studio 2010 (14.0.3513.24210)

I copied all files *.dcu in a folder 'lib', but...

[cariad]

You can try to force the search path ; either from your projet (Project->Options->Delphi Compiler->Search Path) or for Delphi (Tools->Options->Library Win32->Browsing Path) to include the various subdirectory of ZEOS src (plain, core, dbc, ...)

[peha84]

no, again the same error
I do not understand why so, a file is in fact...

(sorry to my English, but I badly talk in English)

System:
Intel Core i7 920
RAM 4Gb
OS -> Windows 7 x64 (7600 RTM)

[cariad]

I'm sorry, but I have no idea what might cause this problem. You can always disable Oracle support (in Zeos.inc change {$DEFINE ENABLE_ORACLE} to {.$DEFINE ENABLE_ORACLE}), but this file should be found anyway.

Did Zeos use to work with an older version of Delphi ? What does your project search path looks like ?

[peha84]

before I worked on delphi 7 all was normal
now I want to update to 2010, and I need access to PostgreSQL


now build all normally, but i can't install - error:
"The start of the program is impossible, because Zdbc140.bpl not exist absents on a computer. Make attempt reinstall the program."

But I have this file!

[peha84]

all installed

[geert]

First, I want to confirm that the patch by cariad above (with the VER210-section in zeos.inc, and the modified tfieldtypes-array in the $IFDEF VER210 in ZAbstractRODataSet.pas) is also necessary for compilation and installation in c++builder 2010, which then goes fine with the projects in the packages/cbuilder12 - directory.

Note about bpl/dcu-path

Note about the posts of peha84 : the standard 'bpl output directory' AND ALSO the standard BPL-search-directory for c++builder 2010 is ${BDSCOMMON}/bpl (which goes somewhere in the public folders. In order to be able to install zeoslib, I had to change the 'final output directory' for each of the subprojects (zplain, zcore, ...) to ${BDSCOMMON}/bpl. Otherwise, I got the same error as you did, most likely because c++builder2010 found another (the stable one) version of the bpl's in my path.

Workaround for c++ builder 2010

Anyway, when compiling the delphi source for C++ Builder 2010, the compiler generates '.hpp'-include files. But both the VString (type String) AND the VUnicodeString (type String for DELPHI12_UP), in the TZVariant packed record shown below, defined in ZVariant.pas , are translated into a UnicodeString.

Code: Select all

{** Defines a variant structure. }
  TZVariant = packed record
    VType: TZVariantType;
    VBoolean: Boolean;
    VInteger: Int64;
    VFloat: Extended;
    VString: String;
    {$IFDEF DELPHI12_UP}
    VUnicodeString: String;
    {$ELSE}
    VUnicodeString: WideString;
    {$ENDIF}
    VDateTime: TDateTime;
    VPointer: Pointer;
    VInterface: IZInterface;
  end;

The constructor of TZAnyValue

Code: Select all

    constructor Create(const Value: TZVariant);

takes a TZVariant argument. This results in multiple overloaded constructors in the generated zvariant.hpp, OF WHICH two are the same :

Code: Select all

 ...
	__fastcall TZAnyValue(System::Extended Value);
	__fastcall TZAnyValue(const System::UnicodeString Value);
	__fastcall TZAnyValue(const System::UnicodeString Value);
	__fastcall TZAnyValue(System::TDateTime Value);
...

This results in a compilation error (not when building zeoslib, but when building a C++-project with zeoslib). When one of both is removed in the generated .hpp-file, compilation is fine.
A quick test with a mysql-database and a tzquery reveals that showing a table and editing it, works fine.

Suggestion/question

I am not sure how to correct this in the pascal code without breaking anything. Are the definitions for both vstring and vunicodestring required ? Would it be OK to move the vstring-definition (supposedly not required for 2010) in the 'else' part of the $IFDEF, as shown below?

Code: Select all

{** Defines a variant structure. }
  TZVariant = packed record
    VType: TZVariantType;
    VBoolean: Boolean;
    VInteger: Int64;
    VFloat: Extended;
    {$IFDEF DELPHI12_UP}
    VUnicodeString: String;
    {$ELSE}
    VUnicodeString: WideString;
    VString: String;
    {$ENDIF}
    VDateTime: TDateTime;
    VPointer: Pointer;
    VInterface: IZInterface;
  end;

[mdaems]

Hi,

I'm sorry, this last suggestion doesn't work at all as there are references to <a variant>.VString all over the code. Same for VUnicodeString. So plenty of Compilation Errors.
Would providing the edited *.hpp header in the zeoslib distribution be useful and practical?

Another question (for Cariad) : is there any practical reason for naming Delphi2010 delphi 14 instead of delphi 13?


Mark

[cariad]

is there any practical reason for naming Delphi2010 delphi 14 instead of delphi 13?

Most certainly, but I'm afraid only Embarcadero can explain why

I used 14 to match the exe version and identification string. A co-worker suggested it might be because of superstition (MS Office had no v13 either, WordPerfect Office was renamed X3, Norton Ghost skipped from 12 to 14, ...)

[sapoku]

Hi there
I'm triying to install your patch under delphi 2010 and ZEOSLIB_TESTING_REV692
I got same error as peha
"The start of the program is impossible, because Zdbc140.bpl not exist absents on a computer. Make attempt reinstall the program."

I'm kind of a noob on this. Can anyone please post some instruccions on how to fix this?

Also, can anyone post the latest zeos lib on wich these patch works.

Thanks

PD:
I have the build directory as library path
PD2: i have also tried ZEOSLIB_TRUNK_REV693 but it seems that the file ZDbcPooled it's no longer on the proyect, ant it keeps getting errors.

PD3:
Finally figure out how to get revision 679 from svn... but still same error

[sapoku]

Hi everyone.

Finally i coud install under revision 679.
all the trick was in change the outputs directory of every subproyect to:
$(BDSCOMMONDIR)\Bpl

After that, everithing goes ok.

For noobs..
Go to the project explorer.
Under each sub proyect theres a Build configuration
Edit the configuration on Bold (The darkest one)
Under the option delphi compiler, paste $(BDSCOMMONDIR)\Bpl into the next fields:
DCP Output directory
Package Output directory
Unit output directory

Press OK

Repeat process for all subproyects.

And thats all folks.

[cariad]

Thanks for the info, I've updated the patch with the output path correctly set.

[geert]

Hi, all,

Mark, you suggested :

Would providing the edited *.hpp header in the zeoslib distribution be useful and practical?

Would this not be quite cumbersome to maintain ?

I found this link http://edn.embarcadero.com/article/10281, which at first sight explains the translation of C-headers to pascal-interfaces, but the section titled

EXTERNALSYM, HPPEMIT and NODEFINE

describes the translation from these generated pascal files back to .hpp-files for c++builder. And apparently EXTERNALSYM can be used to have delphi compile a declaration, but not output it to the .hpp-file. If I understand correctly, this would mean we can have

Code: Select all

{$EXTERNALSYM VString}

in the packed record declaration. I will try it, and report back.

Geert.

[geert]

Hi, again,

first I should correct what I stated in my first post from 24/9:

• Both a String and a UnicodeString are translated to UnicodeString by dcc when generating hpp files for c++builder 2010 as I said before. But it's not the packed record TZVariant that is the problem. I thought that for TZVariant (containing both a String and a UnicodeString) as a parameter in the constructor TZAnyValue.Create, DCC generated constructors for all types in the packed record. Which is not true, my fault.
• The problem are the multiple constructors, with different names, in the TZAnyValue class, more specifically : CreateWithString(Value : String) and CreateWithUnicodeString(Value : UnicodeString). Again, both parameter types are translated to UnicodeString by dcc, and in C++, constructors can not have different names (C++ determines which one to use based on the parameter signature).

Hence we are running into the problem described here :
https://forums.codegear.com/thread.jspa?messageID=65681

The proposed solution is to add a (default) parameter to one of the constructors, e.g.

Code: Select all

    constructor CreateWithString(const Value: String);
constructor CreateWithString(const Value: String);
    {$IFDEF DELPHI12_UP}
    constructor CreateWithUnicodeString(const Value: String; unicodeType: Boolean=true);
    {$ELSE}
    constructor CreateWithUnicodeString(const Value: WideString);
    {$ENDIF}

Note that

• this parameter has to be added further below in the TZVariant.pas-file, in the declaration of the constructor, too.
• I left the CreateWithString-method intact (since I guess it is the oldest of both ?)
• I left out the extra parameter from the {$ELSE} part of the {$DELPHI12_UP} directive, in order to not break code created with c++builder-before-2009, but I am not sure if that is the right thing to do: maybe it is more consistent if it is added there too?

The name 'unicodeType' and the boolean type are arbitrary, but a meaningfull name may be interesting in the generated .hpp-file, which will now contain

Code: Select all

class PASCALIMPLEMENTATION TZAnyValue : public Zclasses::TZAbstractObject
{
...
	__fastcall TZAnyValue(const TZVariant &Value);
	__fastcall TZAnyValue(bool Value);
	__fastcall TZAnyValue(__int64 Value);
	__fastcall TZAnyValue(System::Extended Value);
	__fastcall TZAnyValue(const System::UnicodeString Value);
	__fastcall TZAnyValue(const System::UnicodeString Value, bool unicodeType);
	__fastcall TZAnyValue(System::TDateTime Value);
...

From a Delphi-program, nothing will change, since the unicodeType-parameter has a default value, and it does not have to be specified when calling the constructor.

From a C++ program, one has to specify a second parameter if one wants to use the Unicodestring-constructor This results in a call to (see TZVariant.pas) SetAsUnicodeString, which copies the data and sets the variant type to vtUnicode

Code: Select all

Value.VType := vtUnicodeString;
  Value.VUnicodeString := Data;

while using the standard constructor, will set the data eventually in the same way, and the Value.VType to vtString.

I do not know if applying this patch would be an option for you, Mark, but it seems to solve it, and it is not as problematic as distributing a (machine generated and then hand edited) .hpp file ?


Geert.