Zeoslib Portal

Posted: **16.09.2009, 14:29**

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

Posted: **17.09.2009, 12:15**

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...

Posted: **17.09.2009, 12:48**

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, ...)

Posted: **17.09.2009, 15:02**

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)

Posted: **17.09.2009, 15:45**

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 ?

Posted: **17.09.2009, 16:03**

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!

Posted: **17.09.2009, 16:42**

all installed

Posted: **24.09.2009, 09:15**

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;

Posted: **29.09.2009, 20:44**

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

Posted: **30.09.2009, 08:15**

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, ...)

Posted: **01.10.2009, 03:58**

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

Posted: **01.10.2009, 23:58**

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.

Posted: **02.10.2009, 08:03**

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

Posted: **02.10.2009, 14:52**

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.

Posted: **02.10.2009, 16:28**

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.

Zeoslib Portal

Delphi 2010 compatibility

Delphi 2010 compatibility

Workaround for c++builder 2010 + note about bpl/dcu-path