Solved

MDI program and DLL's

Posted on 1998-10-18
7
235 Views
Last Modified: 2010-04-06
I want to write a D4 program which has 4 major sections (Customers, Catalog, Orders, Sales Staff).  I'd prefer to write it as one big MDI program, with each section having it's own window(s).  However, I'd ALSO like to be able to incrementally upgrade it, i.e., if I write an improvement for the Catalog section, I don't want to have to replace the ENTIRE program.

I've tried looking through D4's help files, and can't find out if this is do-able.  Could y'all please tell me-
1.  Is it even possible?
2.  Is it discussed in D4 help, or in some other source?
3.  Any suggestions you might have would be appreciated...

Thanks in advance!!
 Jim 8^}
0
Comment
Question by:Raven1155
  • 3
  • 2
  • 2
7 Comments
 
LVL 3

Expert Comment

by:philipleighs
ID: 1343300
Hi,

There are many ways of doing this, but you have to give ample thought into you architecture before hand.

You are effectively talking about plugins (I think). You have to design a standard interface that each dll will have, and have some way of registering them. If you're a COM hotshot then this is perfect.

If not, then have a "PlugIns" menu on your main form, and in the FormCreate event enumerate your DLLs and call the "GetPlugInName" function that each dll will have so that you can populate the menu. The function returns a string that will added to your menu.
When a menu item is clicked, call your "DoIt" function which is in each DLL with a pointer to some data. You'll have to find out about dynamically loading DLLs.
Use LoadLibrary, GetProcAddress, FreeLibrary.

You could have many types of "DoIt" functions (unique names of course) that take different types of data.

If the updates are not really plugin-like, but more like bug fixes and new features or UI changes, then this approach is not suitable.

It you want something like PhotoShop where other people (or you) can extend your app by adding their own image filters, then this approach is good.

Remember, anything is possible with Delphi.

Food for thought,
Phil.
0
 

Author Comment

by:Raven1155
ID: 1343301
Thank you for your comments, but I'm >not< talking about Plugins!

I already know that I can write a large program, with many units, with MDIChild forms whose units hold the code for the various program segments.  However, this results in one LARGE executable.  To fix a problem, or change a capability, in any of the sections (Customer, Catalog, etc.), I have to replace the whole thing!

What I'm trying to figure out is- is it possible to write the code for an MDIChild form as a DLL (i.e., separate from the main program)?!?!  The kind of thing I'm thinking of here is the ability to upgrade PART(s) of a program (e.g., Norton Utilities LiveUpdate, or AOL's Tool Update).

This is the kind of thing I'm asking for, not "anything is possible with Delphi"!

- J. Sky

PS- Also, I apologize if y'all thought I was asking you to write code for me... as nice as that is, I'm trying to find out where I can READ more about the architecture possibilities!
0
 
LVL 3

Expert Comment

by:philipleighs
ID: 1343302
OK, ok,

There is a chapter in the Developer Guide (D3) about wrapping a TForm in a DLL "Building a Dialog Box into a DLL"

Might be helpful.


0
What Security Threats Are You Missing?

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

 

Author Comment

by:Raven1155
ID: 1343303
I don't have the developer's guide, but will see what I can find relating to that general topic.  Thank you very much!

Any other suggestions would be (are) appreciated...
0
 
LVL 2

Accepted Solution

by:
Thaddy earned 200 total points
ID: 1343304
Yes you can. It's very easy, provided you design your application carefully.
Make Shure there are no dependencies between class hierarchies.
Always define a Custom class, that precedes the working class,
implement this custom with as much functionality as possible and almost anything protected (or public, if it should be)
Publish the things you need in the final class.
Then, if you want to implement new functionality, go back to the customclass (that has proven code) and add the new functionality, or improved functionality to the custom class.
What you have now can be a) A new Custom class (if you've added to the class) or b) a new final class ( if just the implementation changed.)
This way you never break existing code and have a clear way of understanding how and why an application has evolved.

Here's code for the mdi child dll:
You might be interest in this little snippet.
Design your form, add action:=caFree to the formclose event!
and compile it in this dll framework. You call the dll form from your main app like so: ShowMDIChildForm(Application);

library MDIForms;
uses
  SysUtils, Classes,Forms,Windows,ChildU in 'ChildU.pas' {ChildForm};
var
  DLLApp : TApplication;
procedure MyDLLProc(Reason: Integer);
begin
  if Reason = DLL_PROCESS_DETACH then
    if Assigned(DllApp) then
      Application := DllApp;
end;
procedure ShowMDIChildForm(MainApp : TApplication);
var
  Child : TChildForm;
begin
  if not Assigned(DllApp) then begin
    DllApp := Application;
    Application := MainApp;
  end;
  Child :=TChildForm.Create(Application.MainForm);
  Child.Show;
end;
exports
  ShowMDIChildForm;
begin
  DllApp := nil;
  DLLProc := @MyDLLProc;
end.
 
 
 



0
 
LVL 2

Expert Comment

by:Thaddy
ID: 1343305
Ofcourse you should DERIVE from the customclass and THEN add your code to the derived new custom class, but I think that was obvious.
0
 

Author Comment

by:Raven1155
ID: 1343306
Since I'm not an expert, and don't feel qualified to become one, I have to put this comment here.  Experts, PLEASE pass it onto others who've asked this question...

To get an MDI app. to recognize child windows from DLLs >FULLY< (i.e., in MDIChildCount, etc.), I simply modified Thaddy's answer to me SLIGHTLY... {my changes are in ALL Caps}

Here's the code for the MDI Child DLL (Put "action:=caFree" in the child forms' "Close Form" event!, and call the DLL form from the main app with "ShowMDIChildForm(Application, SCREEN);")-
---
library MDIForms;


uses
  SysUtils,
  Classes,
  Forms,
  Windows,
  ChildU in 'ChildU.pas' {ChildForm};

var
 DLLApp: TApplication;
 DLLSCRN: TSCREEN;  //MY CHANGE

procedure MyDllProc(Reason:Integer);
begin
 if Reason = DLL_PROCESS_DETACH then
  if Assigned(DllApp) then
  begin
   Application:=DllApp;
   SCREEN:=DLLSCRN;  //MY CHANGE
  end;
end {MyDllProc};

procedure ShowMDIChildForm(MainApp:TApplication; MAINSCRN:TSCREEN);    //added MAINSCRN variable..
var Child:TChildForm;
begin
 If not Assigned(DllApp) then
 begin
  DllApp:=Application;
  DLLSCRN:=SCREEN;   //My Change
  Application:=MainApp;
  SCREEN:=MAINSCRN;  //My Change
 end;
 Child:=TChildForm.Create(Application.MainForm);
 Child.Show;
end {ShowMDIChildForm};
 exports ShowMDIChildForm;
begin
 DllApp:=nil;
 DllScrn:=nil;
 DLLProc:=@MyDllProc;
end.
---
By adding the connection to the Screen global variable, the Forms unit now adds the child form(s) to the MDIForm just as if you'd written the code as a unit that is part of the main app!

Cheers,
 Jim 8^)
0

Featured Post

Free Trending Threat Insights Every Day

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

Join & Write a Comment

The uses clause is one of those things that just tends to grow and grow. Most of the time this is in the main form, as it's from this form that all others are called. If you have a big application (including many forms), the uses clause in the in…
In my programming career I have only very rarely run into situations where operator overloading would be of any use in my work.  Normally those situations involved math with either overly large numbers (hundreds of thousands of digits or accuracy re…
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.
Access reports are powerful and flexible. Learn how to create a query and then a grouped report using the wizard. Modify the report design after the wizard is done to make it look better. There will be another video to explain how to put the final p…

705 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

20 Experts available now in Live!

Get 1:1 Help Now