Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.


Welcome, Guest
Guest Settings
Help

Thread: XE5 paths revisited.....



Permlink Replies: 10 - Last Post: Jan 28, 2015 7:29 PM Last Post By: Jeff Overcash (...
Bo Berglund

Posts: 757
Registered: 10/23/02
XE5 paths revisited.....
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 28, 2015 5:41 AM
I have opened an old D7 utility project in XE5 from the dpr file.
The cfg and dsk files were removed first.
All looks good and dandy, syntax check finishes successfully.

But when I try to build for debug there is an error complaining:
[dcc32 Error] E1026 File not found: 'EasyListView.DCR'
[dcc32 Error] E1026 File not found: 'FolderDialog.DCR'

Both of these are used in custom components built into a package,
which is in the library path.
I have tried adding the paths to the source directory of the
components to the global browsing path, but this does not help at all.

So what is the reason for this message in the first place? The DCR
files just hold the images used on the Delphi component palette, and
should not be used at all in a compiled program, right?
And the thumbnails for these components show up just fine in the
palette with only the path to the package file in the library path.

If I add the path to the DCR file into the project's path setting then
the error message disappears!
But why should I have to enter the path to all of my component source
directories in each project when they are compiled into a package???
And when the path to the components is actually in the global browsing
path setting, too....
Olivier Sannier

Posts: 424
Registered: 8/26/01
Re: XE5 paths revisited.....
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 28, 2015 5:44 AM   in response to: Bo Berglund in response to: Bo Berglund
Did you split your package in two, one for design and one for runtime?
If you did not, then please do.
If you did, then please make sure design elements are not included in
the runtime package, directly or via $R directives.
Bo Berglund

Posts: 757
Registered: 10/23/02
Re: XE5 paths revisited.....
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 28, 2015 5:59 AM   in response to: Olivier Sannier in response to: Olivier Sannier
On Wed, 28 Jan 2015 05:44:07 -0800, Olivier Sannier
<olivier at obones dot com> wrote:
THanks for the quick response!
I am new to XE5 even though I have had it for 18 months.
Only recently did I take the step from D7/D2007 to XE5 to get Unicode
support for some real-world project.

Did you split your package in two, one for design and one for runtime?
If you did not, then please do.

I don't know it was possible/available or how splitting can be done...

In this package there are a lot of components collected/created over
the years and I think this was what I did when installing them into
XE5:
- I copied the D2007 package file to a new one with XE5 in the name
- I opened the package file (dpk) in XE5
- I had to enter a lot of path stuff into the project settings to make
it compile etc.
- Then I selected the Debug target and built it, then the Release
target and built that and finally I selected the Install command.
All from right-clicking the project name in Project Manager.
The install went without a hitch, just told me that a lot of
components had been added.

If you did, then please make sure design elements are not included in
the runtime package, directly or via $R directives.

How is this done? And what exactly is "design elements"?
Olivier Sannier

Posts: 424
Registered: 8/26/01
Re: XE5 paths revisited.....
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 28, 2015 6:28 AM   in response to: Bo Berglund in response to: Bo Berglund
Bo Berglund wrote:
On Wed, 28 Jan 2015 05:44:07 -0800, Olivier Sannier
<olivier at obones dot com> wrote:
THanks for the quick response!
I am new to XE5 even though I have had it for 18 months.
Only recently did I take the step from D7/D2007 to XE5 to get Unicode
support for some real-world project.

Did you split your package in two, one for design and one for runtime?
If you did not, then please do.

I don't know it was possible/available or how splitting can be done...

Well, I believe this started with D6 when you could no longer ship the
"designide" package to third parties.
So basically, all code that uses designide, desingintf elements as to be
placed inside a separate package.
Have a look at the JVCL for instance, the R packages contain anything
related to runtime, and the D packages contain anything related with
integration in the IDE.
This way, one can build an application "with runtime packages" and
deploy the R package while leaving the D package only available on the
development machine.
In the end, you have this:

MyPackageR (Runtime only)
MyPackageD (Designtime only)
MyApplication

MyPackageD lists MyPackageR in its uses section and MyApplication has
MyPackageR in its list of runtime packages.

- Then I selected the Debug target and built it, then the Release
target and built that and finally I selected the Install command.
All from right-clicking the project name in Project Manager.
The install went without a hitch, just told me that a lot of
components had been added.

If your application is not built with runtime packages, you don't need
to build your package twice, you just click Install and the IDE will
know about it.

And what exactly is "design elements"?

Design elements are custom editors, the DCR files and the Register
procedures that actually register the components with the IDE.
Bo Berglund

Posts: 757
Registered: 10/23/02
Re: XE5 paths revisited.....
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 28, 2015 6:56 AM   in response to: Olivier Sannier in response to: Olivier Sannier
On Wed, 28 Jan 2015 06:28:09 -0800, Olivier Sannier
<olivier at obones dot com> wrote:

If your application is not built with runtime packages, you don't need
to build your package twice, you just click Install and the IDE will
know about it.
I have never ever created an application with Delphi that is using
runtime packages. My philosophy is that everything should be contained
in the exe file...
I switched from Visual Basic to Delphi back in 1996 precisely because
I could not stand the difficult deployment of the software when a
zillion OCX components needed to be shipped and installed onthe
targets.
Have used single exe applications ever since....

So this explains my ignorance about these package types.
However, given that I do not want to use runtime packages is there a
way for me to switch on/off something that stops the compile time
errors from being generated AND lets me not need to include the
paths to the used components in every single project???

Currently the global DelphiOptions.Library.BrowsingPath includes all
of the component source directories as well, something I had to do in
order to get another application convert from D2007 to XE5.
It really is no good either, when one has all of the components
compiled into a package, right?
Carl-Henrik Nil...

Posts: 53
Registered: 3/26/02
Re: XE5 paths revisited.....
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 28, 2015 9:58 AM   in response to: Bo Berglund in response to: Bo Berglund
Bo Berglund wrote:
I have never ever created an application with Delphi that is using
runtime packages. My philosophy is that everything should be contained
in the exe file...
I switched from Visual Basic to Delphi back in 1996 precisely because
I could not stand the difficult deployment of the software when a
zillion OCX components needed to be shipped and installed onthe
targets.
Have used single exe applications ever since....

So this explains my ignorance about these package types.
However, given that I do not want to use runtime packages is there a
way for me to switch on/off something that stops the compile time
errors from being generated AND lets me not need to include the
paths to the used components in every single project???

Currently the global DelphiOptions.Library.BrowsingPath includes all
of the component source directories as well, something I had to do in
order to get another application convert from D2007 to XE5.
It really is no good either, when one has all of the components
compiled into a package, right?

Modern Delphi forces you to have separate component Designtime packages and Runtime packages.

The IDE uses the component Designtime package.
The application should not use anything from the component Designtime package.

The compiler should use what's in the component Runtime package when it compiles the application,
irrespective of whether or not you have chosen to build the application with
Runtime packages and deploy the Runtime library (normally you have a standalone *.exe
and don't deploy the *.bpl.)

It's very important to get the paths right.
I discussed this in my final post in the 'Search path working differently in XE5 from D2007' thread:
https://forums.embarcadero.com/thread.jspa?threadID=111072&tstart=45
Please reread it carefully :-)
--
C-H

Edited by: Carl-Henrik Nilsson on Jan 28, 2015 12:03 PM
Jeff Overcash (...

Posts: 1,529
Registered: 9/23/99
Re: XE5 paths revisited..... [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 28, 2015 1:05 PM   in response to: Carl-Henrik Nil... in response to: Carl-Henrik Nil...
Carl-Henrik Nilsson wrote:

The compiler should use what's in the component Runtime package when it compiles the application,
irrespective of whether or not you have chosen to build the application with
Runtime packages and deploy the Runtime library (normally you have a standalone *.exe
and don't deploy the *.bpl.)

This part is incorrect. If run time packages are off the compiler/linker works
only from dcu and the resource files directly. It can not treat the bpl as if
it is the equivalent of a C static library.

Run time packages on, it uses the dcp at link time.

Run time packages off it uses dcus (and resources like .res, dfm, .dcr which are
not compiled into the dcu itself but used by the dcu). dcp and bpl are not used
at all and if not needed in the IDE itself can actually be fully deleted and you
can still statically link in the code. Whereas if you remove the dcu's it will
complain it can't find the .dcu file to try and recompile.

bpl/dcp are not treated as static libraries where the code is pulled from them
to link into your standalone exe.

You can try this. Create a new project and drop a TEdit on it. Go to your
lib\win32 release and debug directories and rename Vcl.StdCtrls.dcu. Important
that you ahve not added the source directories to your library path which you
should never be doing in the first place.

With runtime packages on it will compile (because has access to the run time
package's dcp). Turn it off and it no longer compiles because the DCU is missing.

Remember to rename them back afterwards :).

--
Jeff Overcash (TeamB)
(Please do not email me directly unless asked. Thank You)
And so I patrol in the valley of the shadow of the tricolor
I must fear evil. For I am but mortal and mortals can only die.
Asking questions, pleading answers from the nameless
faceless watchers that stalk the carpeted corridors of Whitehall.
(Fish)
Carl-Henrik Nil...

Posts: 53
Registered: 3/26/02
Re: XE5 paths revisited..... [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 28, 2015 1:52 PM   in response to: Jeff Overcash (... in response to: Jeff Overcash (...
Jeff Overcash (TeamB) wrote:
Carl-Henrik Nilsson wrote:

The compiler should use what's in the component Runtime package when it compiles the application,
irrespective of whether or not you have chosen to build the application with
Runtime packages and deploy the Runtime library (normally you have a standalone *.exe
and don't deploy the *.bpl.)

This part is incorrect. If run time packages are off the compiler/linker works
only from dcu and the resource files directly. It can not treat the bpl as if
it is the equivalent of a C static library.

Run time packages on, it uses the dcp at link time.

Run time packages off it uses dcus (and resources like .res, dfm, .dcr which are
not compiled into the dcu itself but used by the dcu). dcp and bpl are not used
at all and if not needed in the IDE itself can actually be fully deleted and you
can still statically link in the code. Whereas if you remove the dcu's it will
complain it can't find the .dcu file to try and recompile.

bpl/dcp are not treated as static libraries where the code is pulled from them
to link into your standalone exe.

You can try this. Create a new project and drop a TEdit on it. Go to your
lib\win32 release and debug directories and rename Vcl.StdCtrls.dcu. Important
that you ahve not added the source directories to your library path which you
should never be doing in the first place.

With runtime packages on it will compile (because has access to the run time
package's dcp). Turn it off and it no longer compiles because the DCU is missing.

Remember to rename them back afterwards :).

Sorry about the the confusion. Believe it or not, but I actually meant it the way you describe!
My original wording came out wrong in the dinner rush, and the edit wasn't much of an improvement.
Thanks for explaining things better!!
Hopefully this will be of help to Bo.
--
C-H
Bo Berglund

Posts: 757
Registered: 10/23/02
Re: XE5 paths revisited..... [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 28, 2015 2:29 PM   in response to: Carl-Henrik Nil... in response to: Carl-Henrik Nil...
On Wed, 28 Jan 2015 13:52:18 -0800, Carl-Henrik Nilsson <> wrote:

Sorry about the the confusion. Believe it or not, but I actually meant it the way you describe!
My original wording came out wrong in the dinner rush, and the edit wasn't much of an improvement.
Thanks for explaining things better!!
Hopefully this will be of help to Bo.

I will go over this on Saturday when I am back from a funeral trip...
Right now I entered the paths into the Project path dialog so it would
not throw the errors. I have just mailed away the test application so
I am now shutting down shop.

But I will for sure go back on Saturday and check up on all of the
paths and probably re-install the custom packages too.
I am not sure I actually set a common folder for the dcu's so that is
one thing I will do too. I believed that the dcu content was
incorporated in the bpl file and thus it should be the only thing
needed.
Now I know better and will reconfigure my environment accordingly.

Thanks for all the information I have received!
I was not completely deaf but I had to complete the application
before going away so I just read the posts....
Jeff Overcash (...

Posts: 1,529
Registered: 9/23/99
Re: XE5 paths revisited..... [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 28, 2015 7:29 PM   in response to: Carl-Henrik Nil... in response to: Carl-Henrik Nil...
Carl-Henrik Nilsson wrote:

Sorry about the the confusion. Believe it or not, but I actually meant it the way you describe!
My original wording came out wrong in the dinner rush, and the edit wasn't much of an improvement.
Thanks for explaining things better!!
Hopefully this will be of help to Bo.
--
C-H

No problem. A common question since packages were introduced in D3 has been why
can't I just give someone the bpl and dcp to develop with.

--
Jeff Overcash (TeamB)
(Please do not email me directly unless asked. Thank You)
And so I patrol in the valley of the shadow of the tricolor
I must fear evil. For I am but mortal and mortals can only die.
Asking questions, pleading answers from the nameless
faceless watchers that stalk the carpeted corridors of Whitehall.
(Fish)
Jeff Overcash (...

Posts: 1,529
Registered: 9/23/99
Re: XE5 paths revisited.....
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 28, 2015 9:50 AM   in response to: Bo Berglund in response to: Bo Berglund
Bo Berglund wrote:
I have opened an old D7 utility project in XE5 from the dpr file.
The cfg and dsk files were removed first.
All looks good and dandy, syntax check finishes successfully.

But when I try to build for debug there is an error complaining:
[dcc32 Error] E1026 File not found: 'EasyListView.DCR'
[dcc32 Error] E1026 File not found: 'FolderDialog.DCR'

Both of these are used in custom components built into a package,
which is in the library path.
I have tried adding the paths to the source directory of the
components to the global browsing path, but this does not help at all.

Global browsing path is for the ctrl-click type features for code navigation.
It is not what the compiler/linker uses. It is where source files belong.

So what is the reason for this message in the first place? The DCR
files just hold the images used on the Delphi component palette, and
should not be used at all in a compiled program, right?
And the thumbnails for these components show up just fine in the
palette with only the path to the package file in the library path.

If you only have a single package (design/runtime) then the dcr is probably
being picked up by a unit doing both design and runtime functionality even if
you are only statically linking your app which also means the images will be in
your resulting exe.

If I add the path to the DCR file into the project's path setting then
the error message disappears!

All needed resources (dcr, res, dfm type files) must be in the library path +
dcu's. Adding it to the browsing path will not impact compile time at all.

But why should I have to enter the path to all of my component source
directories in each project when they are compiled into a package???
And when the path to the components is actually in the global browsing
path setting, too....

A package is not the same as a C static lib file. Even the .dcp file (sorta an
import lib file for the package) is not enough. dcu and resources are what the
compiler/linker needs when statically linking your code into the app. If using
run time packages then they are not, but they can not be extracted from the bpl
when statically linking in.

Here is an article I wrote back in the D8 timeframe when they started enforcing
the license agreement about not distributing IDE design time code (this was
always forbidden but people still did it by accident but as of D6 it was made
impossible to do). Even if you are not using run time packages it is not a bad
idea to properly separate them so unneeded stuff like your images do not get
accidentally pulled into the exe unnecessarily.

http://edn.embarcadero.com/article/27717

--
Jeff Overcash (TeamB)
(Please do not email me directly unless asked. Thank You)
And so I patrol in the valley of the shadow of the tricolor
I must fear evil. For I am but mortal and mortals can only die.
Asking questions, pleading answers from the nameless
faceless watchers that stalk the carpeted corridors of Whitehall.
(Fish)
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02