🚀 go-pugleaf

"Miem Chan" <miemchan@yahoo.com> wrote in message
news:3efd9295@newsgroups.borland.com...

> (1) In the both examples, the PACKAGE macro was not recognized without
> including #include <System.hpp> line

Actually, what you probably missed was the first line in the CPP file of
each package's unit.

  #include <vcl.h>

In BCB6 it no longer adds that line in certain situations (which I have yet
to completely figure out).  In the examples I posted you will see that I
have added these lines just prior to the #pragma hdrstop (which you should
do anyway to maintain the correct pre-compiled header design ... but that's
a different story).  If you want to add #include <vcl.h> to the H files you
can do so as well or leave your <System.hpp> ... it doesn't matter for the
purposes of these examples.

> (2) In the second examples, I had to add the BaseClass.cpp to the
> Project1, otherwise it complains with the following two Linker Error
> messages

This is due to not adding BasePackage to the EXE's "Runtime packages" list.
I neglected to mention that step in my outline.  So, the revised example to
the outline for the application should read:

  - Created a new Application, saved as Project1
  - Saved the form unit as MainForm
  - Added BasePackage to the "Runtime packages" list in "Project Options"
  - Added facility to load/unload the package
  - Added call to create the object and call to virtual method

> (3) It is important to make sure that in the project options for the
> Project1, the Linker/ Use Dynamic RTL is selected.

Correct, I usually neglect to mention this sort of information since it is
set by default for new projects.

> I would like to ask few more questions;
>   ( i ) Is it okay to unload the package in FormDestroy method in the
>   main app. instead of in the destructor?

FormDestroy() is frowned upon in the C++Builder world.  Delphi makes use of
it but C++Builder developers should stick to using the
constructor/destructor of forms rather than using FormCreate/FormDestroy.
There are other posts that explain the reasons better than I can get into
here.

>    (ii) How to use InitializePackage and define the corresponding
> initialization code?

In the help for InitializePackage you will find this line:

  Note: InitializePackage is called internally by the LoadPackage function.

So, I don't believe there is any need to call InitializePackage()
explicitly.  AFAIK the initialization code is an automated process that you
don't really perform any extra steps to achieve.

>   (iii) How to define  "interface" in BCB ?

Okay, that is a different question dealing with COM implementation.  Delphi
has native support for it and C++ must use the ATL to support it.  I've only
played a little with COM and so cannot comment on how to do certain
elements.  Sorry.

>   (iv) How to use GetPackageInfo ?

Okay, add this to the code from the second example.  I added a third button
that when clicked does the following:

  void __fastcall TForm1::Button3Click(TObject *Sender)
  {
    if (!fPackageModule)
      throw Exception("Module hasn't been loaded yet");

    class Collector
    {
      private:
        static void __fastcall PackageInfoProc(const String Name,
          TNameType NameType, Byte Flags, void* Param)
        {
          static const char* containsMap[] = {
            "ContainsUnit", "RequiresPackage", "DcpBpiName" };
          ShowMessage(Name + " : " + String(containsMap[NameType]));
        }

      public:
        Collector(HMODULE Module)
        {
          int flags = 0;
          GetPackageInfo(reinterpret_cast <unsigned> (Module),
            this, flags, &PackageInfoProc);
        }
    } collect(fPackageModule);
  }

I've never personally used GetPackageInfo so can't comment on what the Flags
property ends up telling us.  Of course, you can change the PackageInfoProc
method to perform whatever actions you require with this information.  I
merely printed the routine to the screen.

>   (v) By adding the following RC file (MyRC.rc) I think it is possible to
> add bitmap resources to the package.

Correct.

>   If it were the DLL instead of package we would use LoadImage.  BUT how
> to load these bitmap resources (or any other resource) from the package
> in the main app.?

You should be able to use the same routines to load resources from the BPL
that you do from the DLL since a BPL is just a DLL with support for the VCL
package structure.  However, using your example I just added the following
to a fourth button handler:

  Graphics::TBitmap*  bm = new Graphics::TBitmap;
  bm->LoadFromResourceID(
    reinterpret_cast <unsigned> (fPackageModule), 108);
  Canvas->Draw(0, 0, bm);
  delete bm;

In this example you would have to know the id of the bitmap to load but you
might make that part of your design requirement for the plug-in package.
Or, you can just add a pure virtual method to TBaseClass that returns a
resource that you want:

  enum TResourceType { rtMain, rtSub1, rtSub2 ... }

  class TBaseClass
  {
    public:
      virtual void LoadResourceImage(
        Graphics::TBitmap* Img, TResourceType Type)=0;
  };

You are free to do whatever you want.

>   ( vi ) Would some one comment on the differences between packages and
> DLLs?  When/why to use package and when/why DLL ?

A package is a DLL with VCL support added on top.  If you require a BPL in
your application then only packages created by the same VCL version can be
loading using the LoadPackage scheme.  Normal DLLs cannot be loaded using
LoadPackage since they don't contain the correct hooks.  So this limits your
application in many ways the number one being that if a third-party wants to
design a plug-in for your product then they must do so using C++Builder 6
(assuming you used C++Builder 6 to create the application).  I only use BPLs
as plug-ins when my company will be the only party supplying the plug-ins.
COM is better suited for compiler independent plug-in designs ... but, as I
said above, I am unable to help you with COM design.

Hopefully this helped,
- Clayton