views:

282

answers:

3

Hi dudes, I'm trying to divide my monolithic, Delphi-Win32 app in libraries, so I get some questions around how to share global variables and object among my libraries using Delphi 2009. For example, I have 3 global objects (derived from TObject): for user info, for current session info, and for storing the active database connection and managing operations with this database. My libraries require to work with these objects. Moreover certain libraries would give an object derived from TForm to be hosted for another parent control into the main form. Every object derived from TForm passed to main form has its own methods and properties, that is, their classes are different each other.

I'm thinking to put the global objects into a separate library but I guess that it would make things more difficult, but consider it, please.

How to get to work this situation?

One question more, which is better to use: static or dynamic loading for libraries? Can you recommend some books or sites to learn more about this?

Thanks in advance.

+1  A: 

It seems that by "libraries" you mean BPL Packages, so here are the guidelines:

Each BPL, when it gets loaded, loads all the units in it. No unit can be loaded more than once. That means that if more than one package needs access to one of the globals, then it has to either be in one package that the other(s) have in their Requires list, or in a separate package that all the others Require.

As for static vs. dynamic loading, if your program absolutely needs it, make it statically linked. Dynamic loading is for optional features, such as plug-ins. (If you want to go that route, take a look at JVPlugin in the JVCL. It's a very useful system.)

Mason Wheeler
Thanks friend, but I mean libraries made by me, where I set my custom methods, forms, etc. that will be used for my program. These methods, forms, objects, etc. used to be part of my main app, but because the EXE size was almost 16MB, I thinked to separate its parts into libraries. Do you get it more clear now my situation? Thanks anyway
Billiardo Aragorn
A: 

I do NOT understand why is people mentioning the Delphi version for a simple question like this, the answer is yes it is better to put shared variables in a separate unit before the implementation keyword. Every object(form, class, control) is derived from TObject, even if you define a class like

type TMyClass = class
  // no inheritance ?
end;

the above class is still derived from TObject(read Delphi help). Your global variables could be declared of type TObject or Pointer and when you access them use hard cast TForm(MyPointerVariable).Method, i.e.

var MyPointerVariable: Pointer; // I presume it is already initialized and is a pointer to a TForm descendant
...
begin
     TForm(MyPointerVariable).Caption := 'Stack Overflow';
end;

For more information read Delphi tutorial on my blog it should be very simple to understand.

delphigeist
Thanks for your answer. I answer you now, I mention the Delphi version for getting a correct answer, because someone can give a solution that works perfectly in Delphi 8 or early but not in Delphi 2009, or it may be a obsolete solution. Thanks anyway once again.
Billiardo Aragorn
+2  A: 

What we have done in the past to share variables between modules (we used BPLs) was to pass them through a shared TStringList. Generally speaking it is best to have a global shared object with all your shared variables in it.

Anything that is going to be referenced between more then one library must be in its own library. Mason's advice was sound.

Go with static loading, unless you really need dynamic for some specific reason (which it doesn't sound like). Let the windows memory manager swap out unneeded libraries from memory.

One tip from someone who managed a large application split into multiple libraries. We had our components in packages, the VCL, some application common routines, and then a library for each "screen" or segment of the application. For changes to the screens, it was possible to just release that one updated library, but for changes to any of the other types of libraries, we found we usually had to redeploy everything. So it was rare we enjoyed an advantage from the configuration.

Jim McKeeth