Solved

Modular Application in D5 ?

Posted on 2001-06-12
18
210 Views
Last Modified: 2010-04-06
I am looking at redeveloping a previous app written in Delphi 5, due to user requests for certain modifications, which was previously in a single EXE file.

I have thought about totally redeveloping the app, and creating it in a modular format, ie. a different EXE file for each of the modules, which are called by a MAIN MENU Module.

As I have not done this before, there are a number of questions I need to ask.

1. Would this be the best way to do this, ie. 1 exe for each of the modules, about 7-8 in all ?

2. Advantages, disadvantages, problems etc. with doing it this way ?

3. How do I check if an EXE is open, and therefore close it if needed ?

Any alternatives ?


Any advice would be greatly appreciated.
0
Comment
Question by:pjelias
  • 6
  • 4
  • 2
  • +5
18 Comments
 
LVL 1

Expert Comment

by:martin_g
Comment Utility
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?



0
 

Author Comment

by:pjelias
Comment Utility
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.
0
 
LVL 2

Expert Comment

by:FrodoBeggins
Comment Utility
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.
0
 
LVL 2

Expert Comment

by:gikam
Comment Utility
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

0
 
LVL 4

Accepted Solution

by:
StevenB earned 200 total points
Comment Utility
 Dll's are probably the way forward. You needn't fear them, they're really easy to create and use in Delphi. Once you've started you'll grow to love them. As a starting point try this ...

  1) Create a new application and drop a button on the main form. Put this code as the button's handler:

procedure TForm1.Button1Click(Sender: TObject);
type
  TMyProcedure = procedure;
var
  AProcedure : TMyProcedure;
  DLLHandle : THandle;
begin
  DLLHandle := LoadLibrary ('MyDll.dll');
  if DLLHandle <> 0 then
  try
    @AProcedure := GetProcAddress(DLLHandle, 'MyDllProcedure');
    if @AProcedure <> nil then
    begin
      AProcedure;
    end;
  finally
    FreeLibrary(DLLHandle);
  end;
end;

  2) Compile the application to create an executable.

  3) Next create a new dll from the Delphi File menu. Save the dll project as MyDll. Paste this code into the dll project unit:


library MyDll;

uses
  SysUtils,
  Classes,
  Dialogs;

{$R *.RES}

procedure MyDllProcedure;
begin
  ShowMessage('Hello World');
end;

exports
  MyDllProcedure;

begin
end.


  4) From the Delphi Run -> Parameters menu, browse to the executable created in step 2 and enter it as the host application.

  5) Run the Dll project and click the button. You should see the message 'Hello World'

  Hope this example code helps with the dll writing.

  Steven
0
 
LVL 12

Expert Comment

by:rwilson032697
Comment Utility
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.


0
 
LVL 1

Expert Comment

by:WiseGuy
Comment Utility
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.
0
 
LVL 4

Expert Comment

by:StevenB
Comment Utility
 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.
0
 
LVL 1

Expert Comment

by:MaxSCZ
Comment Utility
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
0
IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

 
LVL 2

Expert Comment

by:FrodoBeggins
Comment Utility
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.
0
 
LVL 1

Expert Comment

by:martin_g
Comment Utility
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

0
 

Author Comment

by:pjelias
Comment Utility
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.
0
 
LVL 4

Expert Comment

by:StevenB
Comment Utility
>>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.
0
 

Author Comment

by:pjelias
Comment Utility
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 ?
0
 
LVL 4

Expert Comment

by:StevenB
Comment Utility
 Ooops, you'll need to add 'Forms' to the uses clause also.
0
 
LVL 4

Expert Comment

by:StevenB
Comment Utility
 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

0
 

Author Comment

by:pjelias
Comment Utility
StevenB,

Have tried, works OK.

Thanks for that
0
 
LVL 4

Expert Comment

by:StevenB
Comment Utility
 No problem, good luck with the project.
0

Featured Post

How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

Join & Write a Comment

This article explains how to create forms/units independent of other forms/units object names in a delphi project. Have you ever created a form for user input in a Delphi project and then had the need to have that same form in a other Delphi proj…
In this tutorial I will show you how to use the Windows Speech API in Delphi. I will only cover basic functions such as text to speech and controlling the speed of the speech. SAPI Installation First you need to install the SAPI type library, th…
This demo shows you how to set up the containerized NetScaler CPX with NetScaler Management and Analytics System in a non-routable Mesos/Marathon environment for use with Micro-Services applications.
This video shows how to remove a single email address from the Outlook 2010 Auto Suggestion memory. NOTE: For Outlook 2016 and 2013 perform the exact same steps. Open a new email: Click the New email button in Outlook. Start typing the address: …

762 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

7 Experts available now in Live!

Get 1:1 Help Now