Install 4.1.3.3 XE3 x64 can't find designide

[Mark G]

I've just started a port to x64 and have installed XE3 Upd. 2 onto my machine.

I installed 4.1.3.3 with default setting and then tried a clean / build of my code for 32 / 64 bit.

For the 32 bit I had to add to the library path users\public\documents\RAD studio\10.0\bpl to get doa41dxe3

when I switch to a 64 bit compile it complains it can't find package designide. I can only find this under \Program files (x86)\Embarcadero\RAD Studio\10.0

Am I missing a path to the x64 version ?

Should I have expected these libaray paths in XE3 to have been set during the install ?

Mark

 

[Marco Kalter]

No extra configuration is required after installing Direct Oracle Access for XE3, neither for 32 bit nor for 64 bit applications.

What exactly did you try to compile?

 

[Mark G]

It's a package that has my code in which wraps the DOA layer. It's code that was fine in XE2, but not done XE3 / x64 before.
Also moved to a new machine.

It has 5 packages which I use for my applications, 4 of which install fine, it's the DOA one in x64 that gives me the can't find designide error.

 

[Mark G]

I had the previous DOA version installed with XE3 Upd 1 (4.1.3.2 I think) - could it be something left over from that ?

My package is dependent on another of my packages which clean/build/installs ok for 32/64 and the other three packages are also dependent on that.

I've checked for paths in the 32/64 options for that package and there don't seem to be any specific things I've added beyond the default.

So I scrapped the package and rebuilt from scratch, the Win32 installed fine, same problem with 'designide'. It added all it's 'requires' automatically. All I've changed from the default is the 'Description' of the package and the search/output files which are in a .\bin\$(CONFIG)\$(PLATFORM) folder, so should pick up the right 32/64 combos.

Only building under "DEBUG" configuration at the moment.

Any ideas. I'm throwing this at you as it's only the package with DOA that seems to be the problem.

Mark

 

[Marco Kalter]

I'm not sure what could cause this. Can you open one of the DOA demo projects and compile it for the 64 bit platform?

 

[Mark G]

I think DOA might have been a red herring. I've taken out some of the units in the package, and left the simpler ones and it now builds. So the offending code is likely to be a non-DOA component. Nothing is obvious at the moment, but I think it's not DOA.

So my apologies. I thought it might have been something in configuration as this code has been stable for several iterations of Delphi and DOA.

I'll report back here the solution - if it's not too embarassing.

Thanks for the support.

Mark

 

[Mark G]

It would appear that if I do a build of my package as x64 after a clean and remove all the "requires" from the package it builds (there are warnings so I'm not sure it's a good build, but the designide problem does not occur).

I then change the target platform to 32 bit and it adds the requires section : the following DCPs

dbrtl
doa41dXE3
rtl
vcl
vclx
XRGDGen (one of mine)

..and it builds the 32 bit version.

If I now switch back again to the 64 bit the "can't find designide" returns and the cursor stops on the source code line for the package
for requires doa41dXE3 which makes DOA look guilty again.

I've got a work round in terms I have created two packages one for 32 and one for 64 bit, and I should be able to continue with my 64 bit testing.

However the finger is now pointing back at DOA

To recap

- new default package
- added in my modules
- set the package output directory / seach path / unit output directory to bin/$(PLATFORM)/$(CONFIG)
- changed the description of the package
- built x64
- changed to x32
- build brings in requires packages
- x32 builds ok
- x64 now fails to build with can't find designide

Any ideas ?

Mark

 

[Carlo Sirna]

My two cents:
1) the DOA package requires the designide package. this is a fact.
2) designide is a package that should never be deployed because it is part of the delphi ide. I belive that even the embarcadero licensing denies you the right to deploy that bpl.
3) since designide is only meant to run inside the delphi ide, and since there is no 64 bit version of the delphi ide (it generates 64 bit code but it is not a 64 bit application) there is absolutely no 64 bit version of the designide package, since it would be pointless to build one.

So -> there is no way of building DOA as a 64 bit *package* until designide is among its required packages.

Solution -> Doa should be split in two separate packages: one that contains the actual DOA runtime (and does not require any designide or dcldb package) and a second designtime-only package that contains these units: OracleReg OracleDesign , OracleDefaults ,OracleTools and is meant only to be installed (and only 32 bit compiled)

I already did it when I noticed that my application required me to redistribuite designide150.bpl when linked with runtime packages.

Regards,
Carlo Sirna

EDIT: maybe I have been too cryptic...
the problem here is that you have developed a package that has, among its required packages, also the doa package.

if you want to build a 64 bit version of your package, you need also a 64 bit version of the doa *package*.

but, doa, since it is distribuited as a monolitic package that contains both design time code and runtime code, can be compiled as a 64 bit runtime package for the simple fact that it would require the 64 bit versions of the designide and dcldb packages which will never exist because they are integral and non redistributable part of the delphi development environment.

the most polite solution would be to have doa being split in two separate packages: and YOUR package should have in the "require" list only the doa package that contains the runtime units, which would be compilable also with the 64 bit architecture.
the only purpose of the other package would be to have it installed in delphi: it would not be part of the applications developed with delphi. so you don't need and you don't want to compile this second package with the 64 bit architecture, since there is no 64 bit delphi ide.

I just finished to do this job with the most recent sources:
I created a package named "doa" for the runtime and a package named "dcldoa" to be installed.

these are the two sources:

package doa;

{$RUNONLY} // this package is not meant to be installed in the ide
// other compiler directives omitted

requires
vcl,
vcldb,
vclx;

contains
OracleTypes in 'OracleTypes.pas',
OracleLogon in 'OracleLogon.pas',
OracleData in 'OracleData.pas',
OracleNavigator in 'OracleNavigator.pas',
OracleConstraintsEdit in 'OracleConstraintsEdit.pas',
Oracle in 'Oracle.pas',
OracleCI in 'OracleCI.pas',
OracleFilter in 'OracleFilter.pas',
OracleQB in 'OracleQB.pas',
OracleSelForm in 'OracleSelForm.pas',
OracleCompress in 'OracleCompress.pas',
OracleVisual in 'OracleVisual.pas';

end.

package dcldoa;
{$DESIGNONLY} // this package is only meant to be installed
// in delphi (i am omitting the other directives)
requires
rtl,
designide,
dcldb,
doa;

contains
OracleReg in 'OracleReg.pas',
OracleDesign in 'OracleDesign.pas',
OracleTools in 'OracleTools.pas',
OracleDefaults in 'OracleDefaults.pas' {OracleDefaultsForm},
OracleSeqFldEdit in 'OracleSeqFldEdit.pas' {SequenceFieldForm},
OracleExplorer in 'OracleExplorer.pas' {ExplorerForm},
OraclePreferences in 'OraclePreferences.pas' {PreferenceForm},
OracleSQLEdit in 'OracleSQLEdit.pas' {SQLEditForm},
OracleVarEdit in 'OracleVarEdit.pas' {VariablesForm},
OracleQBEEdit in 'OracleQBEEdit.pas' {QBEEditForm},
OracleDPColumnsEdit in 'OracleDPColumnsEdit.pas' {DirectPathColumnsForm};

end.

 

[Mark G]

Thanks. That's what I ended up doing - but good to have it confirmed. Much appreciated.

 

[Mike Z]

I have same problem with Delphi XE2
I downloaded registered version of doa41dXE2.exe from website for Delphi XE2
After I installed, I was able to compile doa41dXE2.dproj package using Win32 platform, but not if I switched to Win64.
Is there upgrades/fixes available for Win64 for Delphi XE2?
Thank you.

 

[Carlo Sirna]

Same problem, same solution: you have to split the XE2 sources in 2 packages. This is a long time problem. it should have been this way also in delphi 7.