Modular Application in D5 ?

It depends on what you want the individual exe's to do.  If their use is fairly independent of each other and you don't need to communicate between them to keep things synchronized, then the separate apps may be the best way to go.   Another way is the use of plugins or separate dll's referenced when needed by the master application.  

What is the primary use of the application? Is it for a single desktop or networked multi- user?  Does it use a database, if so what kind?

The app is a Financial Management Reporting System, multi user, using Paradox 7 Tables as a backend.

The Modules would be fairly independant, although they would access the same tables (although not all the same tables at the same time), and therefore possible the same Data Module (or would it be better to create a seperate Data Module for Each Module ?)

Have very little experience in DLL's and was turned away by diffilculty in using/creating.

1. I think the DLLs are the real solution. They are the only way to use just one DataModule. And you have much more control. And that's the way MS recommends to be done
2. If you make a bunch of executables, every .exe you start will have it's own private 4GB memoryspace and it will be very dificult to comunicate between them and the main program.
3. There are many ways to see if a program is open. I, personaly, prefer GlobalAddAtom (when starting the program), GlobalDeleteAtom (when terminating) and GlobalFindAtom (to see if it is started). The real problems is close the .exe - TerminateProcess is a solution, but very crude.

1,2.I think it is not the best way to create separate EXEs because every EXE will load probably the same units many times. Better is to write the modules in one ore more DLLs
disadv: u need to manipulate and keep track of many files when installing or so
wht is the problem if recompiling the entire EXE?
some porblems when exchanging data between EXEs
3. U can check for an EXE for example (since the EXE has a main window (form)) calling "findwindow" API function
good luck
gika

Hmm.. Sounds like your asking the wrong question. I think what you should be asking is "Why should I split the application up into multiple components". IE: What is it about the application or it use that would require this.

IMHO, if there is not a compelling reason to do so, you are just making life hard for yourself.

Cheers,

Raymond.

I think you should look at delphi packages. A package has the advantage like a dll that it can be dynamically loaded. But you don't have to work with pointers to functions. You can develop your project like an exe project, that is 1 project. Then at the end (or at regular intervals) organize your units in packages and choose the option 'compile with run-time packages'. You will have a small exe and a number of packages. Loading packages dynamically gives you the opportunity to sell functionallity separately. You will have to design and build a frame work in order to enable the packages to register their functionality. (For example adding a menu item to the main menu of the (small) exe.

I am only giving directions, so there is a lot to work out. I am sure it can be done. Mark Miller writer of CodeRush of Eagle software has done it. Maybe he can help.

 One good reason for splitting the code is to put dialogs into dlls. This way the dialogs can be called from multiple applications, and best of all, when they are updated, you simply release a new dll and all the applications smoothly update without having to recompile them all.

Hi,
I'm developing a Modular application with separate EXEs one DLL to share functions.
To communicate between EXEs I use WM_COPYDATA, there are many problems to share Handle...
Every EXE have his datamodule because open different Database.
If you put the DataModule in DLL I think you get many trouble... Make one datamodule and add it to every project, but if you modify it you must rebuild all projects.

bye and goodluck Max

p.s. Excuse me for my poor english

Yes, WM_COPYDATA is very useful. However, there are some restrictions you should be aware of. And there are some anothers messages (WM_SETTEXT and WM_GETTEXT) which are handled by windows so they can ACTUALY do interprocess data exchange (Uau! That sound dificult)
Anyway, sharing handle between proceses is easy. But using it is extremly dificult :)
A good way to share large amounts of informations is using memory-mapped files.

But it is not necesary. In that case, pjelias, it is much less headache do learn to implement DLLs. StevenB gave you a good example.

I agree with rwilson regarding your current app.  You might want to consider what headaches it's currently giving you and correct them rather than split it up.  My experience with paradox in a multi-user has been difficult. If one of the current users machines locks ups or crashes while tables are open, it will cause the famous "Index out of date" error on bootup. Also, it leaves those messy lock (*.lck) files active which of course causes confusion to other client apps using the database.  

However, these problems can be solved, and may be simpler than trying to rewrite all the code.

Here's some good links on solving paradox corruption issues:
http://community.borland.com/article/0,1410,15247,00.html
http://www.thedelphimagazine.com/samples/paradox/paradox.htm#Paradox
http://community.borland.com/article/0,1410,15005,00.html

StevenB,

Tried your code, looks OK.

Question - Are you able to Add Forms into DLL's or CALL them through the DLL ?

Also in relation to Question re: Why split up into different modules/exes, I thought that it might be easier to add/modify/delete seperate modules as needed, rather than one big app.

>>Are you able to Add Forms into DLL's

  Absolutely, simply create a new form in the dll's project and then utilise it as you would in a normal application.

  For example, modify the above example by creating a new form in the dll's project and then change the dll code to read something like

library MyDll;

uses
  SysUtils,
  Classes,
  {ADD THE NEW FORM'S UNIT HERE IF NEEDED, BUT DELPHI SHOULD ADD IT ANYWAY};

{$R *.RES}

procedure MyDllProcedure;
begin
  Application.CreateForm(TMyNewForm, MyNewForm);   {REPLACE WITH APPROPRIATE VALUES FOR YOUR FORM}
  MyNewForm.ShowModal;
end;

exports
  MyDllProcedure;

begin
end.

StevenB,

When I try to add the code with the form, I get an error message re: Undeclared identifier 'Application'

I have checked previous code, where I have used Application.CreateForm, and it appears OK. The only difference is that I have not used this in a DLL before. Could this be why the error ?

 Ooops, you'll need to add 'Forms' to the uses clause also.

 Actually this has set me thinking. I'm not absolutely convinced that the application object will clean up its forms when they are created with CreateForm within a dll. It is probably safest to clean them up yourself with a call to FreeAndNil when you're finished with them. It can't hurt to do something like this which will ensure that the forms are cleaned up:

procedure MyDllProcedure;
begin
  Application.CreateForm(TMyNewForm, MyNewForm);
  try
    MyNewForm.ShowModal;
  finally
    FreeAndNil(MyNewForm);
  end;
end;

  Hmm, I might ask a question myself about this.

  Steven

StevenB,

Have tried, works OK.

Thanks for that

 No problem, good luck with the project.