Colleagues,

I used to be very comfortable writing and installing components in D7 but am having a problem in XE-5 Professional. I'll outline clearly as possible.

1 -  I have a source library (let's call it "MySRC" in which I have developed an extensive vector graphing component (TCustomControl) named "vGraph.pas". It USES four other units (Unit1.pas ... etc.). Being a visual component it is visible on  hosting application form at design time where you can resize the canvas area and initialize the numerous properties affecting graph appearance. (This is solid code and working for over a decade.)

To bring this all into the XE-5 "Pro" world here are my steps:

2 - Create my own package named "STR" and for purposes of backup/editing, save it in folder "\MyPackages". This goes just fine. I see a .dpk and a .bpl after Build.

3 - Install the empty package to the IDE just to see how the process goes. I now get a tab up top saying "STR". Good, but the name it gets on the "Install Packages" window is the *path* to STR (in text form), not it's actual name "STR", which seems odd. Anyway, I press on.  (BTW - I get same results if I populate the package with a component before installing the package).

4 - I now ADD my component unit "vGraph.pas" to this "STR" package and in Project Options for the package point the search path to "MySRC" so Compile/Build can find those additional 4 units "vGraph" will want to use. Note that "vGraph.pas" has the "Register" procedure naming "STR" as target package.

5 - Compile to check things and then do a Build. There are zero errors but four Warnings identifying each of the additional units as "Implicitly Imported". This seems normal - informative and of no concern.

6 - Check the package and see the vGraph icon there. I re-install the package to the IDE to make sure everything is really there.

7 - Click the STR tab on the IDE toolbar and sure enough, vGraph component is there.

8 - Now I define a "TEST" project of type "VCL forms". I drop the vGraph component onto the form and a graph appears. I can re-size, reposition and edit values for all 40 - 50 properties and watch them change on the graph in real time. Nice. Just how it should be. Design phase is flawless.

9 - Now for trouble. I click "Run". Compilation fails with a message "vGraph.dcu" cannot be found in "C:\Users\MyName\Documents\RAD Studio\Projects".   Huh? Why is it looking there? My understanding was that an installed component is self-contained sort of like a DLL. Everything should be in there. No matter how I rebuild the package or fiddle with search paths I cannot get the IDE to do anything else. Compile fails.

In search for clues I try this ... In test project "TEST" I edit Project Options to make a search path to my source Library "MySRC" which is where all units for the component are located. The compile now works and the test is 100% successful. Zero errors and no warnings. The graph works perfectly on the form and I have an application .exe..

This is OK as a temporary workaround but what if I create an application where I use 5 or 6 of my components? That's a lot of search paths to supply and clearly not the way this should work. If I drop a component on a form I expect it to become part of the app with everything it needs already there.

I welcome suggestions, fully expecting I have overlooked the obvious :~

best wishes,
gk

Garth Klatt wrote:
> 9 - Now for trouble. I click "Run". Compilation fails with a message "vGraph.dcu" cannot be found in "C:\Users\MyName\Documents\RAD Studio\Projects".   Huh? Why is it looking there? My understanding was that an installed component is self-contained sort of like a DLL. Everything should be in there. No matter how I rebuild the package or fiddle with search paths I cannot get the IDE to do anything else. Compile fails.
> 

You do not have run time packages checked and if checked your runtime package is 
not in the list of them so it is trying to statically linking the dcu in.  For 
it to find it the location of your dcu needs to be in the library path (library 
path is for binaries, do not put the source path there).

> In search for clues I try this ... In test project "TEST" I edit Project Options to make a search path to my source Library "MySRC" which is where all units for the component are located. The compile now works and the test is 100% successful. Zero errors and no warnings. The graph works perfectly on the form and I have an application .exe..
> 

Do not put the source paths into the library path, your binaries belong in their 
own directories separated by platform.  That is the directory you put in the 
library path.

> This is OK as a temporary workaround but what if I create an application where I use 5 or 6 of my components? That's a lot of search paths to supply and clearly not the way this should work. If I drop a component on a form I expect it to become part of the app with everything it needs already there.
> 

You should have a common location for your binary outputs and put that common 
location in your global library path for each platform you support.

> I welcome suggestions, fully expecting I have overlooked the obvious :~
> 
> best wishes,
> gk


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

Hi Jeff ... some small success ...

Thanks for the response. I mostly have what you recommend in terms of file organization with one exception that's now changed.

You were right, "Compile with runtime libraries" was not checked. So I did that but then, no matter what program I tried to compile there was failure with this message:

E2202 - Required package 'DataSnapCommon' not found. 
--------------------------------------
With experimentation discovered the unfound package name can safely be deleted from the runtime list. That got rid of above problem but then the IDE still could not find required references in the package even though I see it in the list of packages. I can get the application to compile with the component but like before, only by pointing to the folder of dcu's in my own library. It's as if the runtime isn't there(???) even though the package installer list shows it present and with the component in there
.

Will fiddle with some more things later today.

This just in ... I may have it working. There's an excellent site going into details and pitfalls of packages and components:

http://mc-computing.com/languages/delphi/Packages.html 

I went step by step and got a clean compile without any need for custom paths to my own libraries.

Quite frankly, there's a lot of confusion on the subject but the site mentioned is a big help. I'll mark this solved tomorrow if more tests look good.


best wishes,
gk





> {quote:title=Jeff Overcash (TeamB) wrote:}{quote}
> Garth Klatt wrote:
> > 9 - Now for trouble. I click "Run". Compilation fails with a message "vGraph.dcu" cannot be found in "C:\Users\MyName\Documents\RAD Studio\Projects".   Huh? Why is it looking there? My understanding was that an installed component is self-contained sort of like a DLL. Everything should be in there. No matter how I rebuild the package or fiddle with search paths I cannot get the IDE to do anything else. Compile fails.
> > 
> 
> You do not have run time packages checked and if checked your runtime package is 
> not in the list of them so it is trying to statically linking the dcu in.  For 
> it to find it the location of your dcu needs to be in the library path (library 
> path is for binaries, do not put the source path there).
> 
> > In search for clues I try this ... In test project "TEST" I edit Project Options to make a search path to my source Library "MySRC" which is where all units for the component are located. The compile now works and the test is 100% successful. Zero errors and no warnings. The graph works perfectly on the form and I have an application .exe..
> > 
> 
> Do not put the source paths into the library path, your binaries belong in their 
> own directories separated by platform.  That is the directory you put in the 
> library path.
> 
> > This is OK as a temporary workaround but what if I create an application where I use 5 or 6 of my components? That's a lot of search paths to supply and clearly not the way this should work. If I drop a component on a form I expect it to become part of the app with everything it needs already there.
> > 
> 
> You should have a common location for your binary outputs and put that common 
> location in your global library path for each platform you support.
> 
> > I welcome suggestions, fully expecting I have overlooked the obvious :~
> > 
> > best wishes,
> > gk
> 
> 
> -- 
> 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)

Edited by: Garth Klatt on Feb 2, 2014 9:26 AM

Edited by: Garth Klatt on Feb 2, 2014 9:45 AM

Edited by: Garth Klatt on Feb 2, 2014 10:55 AM

Edited by: Garth Klatt on Feb 2, 2014 2:44 PM

Garth Klatt wrote:
> Hi Jeff ... some small success ...
> 
> Thanks for the response. I mostly have what you recommend in terms of file organization with one exception that's now changed.
> 
> You were right, "Compile with runtime libraries" was not checked. So I did that but then, no matter what program I tried to compile there was failure with this message:
> 
> E2202 - Required package 'DataSnapCommon' not found. 
> --------------------------------------
> With experimentation discovered the unfound package name can safely be deleted from the runtime list. That got rid of above problem but then the IDE still could not find required references in the package even though I see it in the list of packages. I can get the application to compile with the component but like before, only by pointing to the folder of dcu's in my own library. It's as if the runtime isn't there(???) even though the package installer list shows it present and with the component in the
re

You will sometimes find that ahppening when packages are removed when upgrading 
a project from one version to the next.  A unit is moved between packages or a 
package is just removed.

Your other problem of not finding it is the dcp file must be in your library 
path for the package.  Also if you have resources in your package like dfm's 
then they belong in that directory too.

If this is a run time error, the .bpl must be in the OS loading logic path. 
Unchanged the default is basically the working directory.  <windows>, 
<windows\system32> and finally the OS path.  Note that in 64 bit windows 
systme32 is for 64 bit dlls and SysWOW64 is for 32 bit dlls.

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

OK. Think I am in business. I recall having trouble like this over 10 years ago with D7. IMHO the package feature, while extremely useful, was not well designed in the first place and we (meaning also Embarcadero) are now stuck with it. There is a house-of-cards feel to it and despite the wizards it's not very intuitive. I am presently putting together my own web page in step-by-step fashion in case I have to re-educate myself yet again some day.

One other thing I note. In the application project/options/runtime packages it was necessary not only to remove the Datasnapcommon item but to manually insert the name of my package (which you rightly suspected might be another problem). The best way was to copy the whole colossal mess to Clipboard, edit in my text editor and then paste it all back (then keep a copy for other projects). You have to uncheck the inherit box or when you exit that panel the unedited packages list is restored. At least the pro
ject Save keeps it all.

Your information got me going in the right direction and ultimately led to success. I appreciate your patience and expertise in dealing with this. Apart from getting things working, the upside is I learned a lot.

Best wishes,
gk


> {quote:title=Jeff Overcash (TeamB) wrote:}{quote}
> Garth Klatt wrote:
> > Hi Jeff ... some small success ...
> > 
> > Thanks for the response. I mostly have what you recommend in terms of file organization with one exception that's now changed.
> > 
> > You were right, "Compile with runtime libraries" was not checked. So I did that but then, no matter what program I tried to compile there was failure with this message:
> > 
> > E2202 - Required package 'DataSnapCommon' not found. 
> > --------------------------------------
> > With experimentation discovered the unfound package name can safely be deleted from the runtime list. That got rid of above problem but then the IDE still could not find required references in the package even though I see it in the list of packages. I can get the application to compile with the component but like before, only by pointing to the folder of dcu's in my own library. It's as if the runtime isn't there(???) even though the package installer list shows it present and with the component in t
here
> 
> You will sometimes find that ahppening when packages are removed when upgrading 
> a project from one version to the next.  A unit is moved between packages or a 
> package is just removed.
> 
> Your other problem of not finding it is the dcp file must be in your library 
> path for the package.  Also if you have resources in your package like dfm's 
> then they belong in that directory too.
> 
> If this is a run time error, the .bpl must be in the OS loading logic path. 
> Unchanged the default is basically the working directory.  <windows>, 
> <windows\system32> and finally the OS path.  Note that in 64 bit windows 
> systme32 is for 64 bit dlls and SysWOW64 is for 32 bit dlls.
> 
> -- 
> 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)