[DUG] Program design question

Wilkin, Kurt Kurt.Wilkin at fnzc.co.nz
Thu Jun 9 18:36:04 NZST 2005


on Thursday, 9 June 2005 6:09 p.m. delphi-bounces at ns3.123.co.nz wrote:
> A program design question: whether to put extra functionality into
> one program or several. 
> 
> I have written a monitor program (automated time recording).
> Ideally I want
> it as slim as possible since its running all the time.  Hence
> my idea is to
> have one small 1-form program, and when I click on any of the
> report or
> setup buttons, it actually fires up a separate and much
> larger program using
> shellexecute, and suspends itself (closes the logfile) while the
> other program runs. 
> 
> Question 1 - what is the best way for two separate programs
> to exchange
> information - the monitor program needs to be told when the
> setup program
> finishes in order to start running again, and also there is some other
> information such as setup options I need to communicate back
> and forth (eg
> which program and/or form fired up the setup program so it
> can give it focus
> again at the end).  Now I can write this information in a
> disk data file,
> but I reckon there has in Windows to be a better way to do it - using
> some kind of message.  Or is the simplest to use parameter strings in
> the comandline when starting the second program?
> 
> Question 2 - if I put all code in one program and don't
> create the extra
> forms/Windows till needed, I am pretty sure I still will have
> a much bigger
> program than option 1.  Any comments?
>



Have tried this, and in my case, came to the conclusion that 
1 program was easier. Mostly the separation between the 2 was
too brutal - ended up needing to duplicate a lot of functions
(in your case something like sortlogbyName, sortLogByDate etc),
or else manage calling multiple instances of the 2nd app
while suspending the first. 

Doable, but I figured get it going first (the easy way) 
then rewrite it in multiple apps, and never bothered 
rewriting.

YMMV, if you are better adapted to calling multiple processes
than I.

Cheers, Kurt.






-- 
This electronic message together with any attachments is confidential and
intended for the named recipient's use only.  If you are not the intended
recipient (i) do not copy, disclose or use the contents in any way, (ii)
please let us know by return email immediately then destroy the message, and
any hard copies of the message, and any attachments.  The sender of this
message is not responsible for any changes made to this message and/or any
attachments and/or connection linkages to the Internet referred to in this
message after it has been sent.  Unless otherwise stated, any pricing
information given in this message and/or attachments is indicative only, is
subject to change and does not constitute an offer to buy or sell securities
or derivatives at any price quoted.  Any reference to the terms of executed
transactions should be treated as preliminary only and subject to separate
formal written notification.  Where reference is made to research material
and/or research recommendations, the basis of the provision of such research
material and/or recommendations is set out in the relevant disclaimer.



More information about the Delphi mailing list