packages. This will result in a small executable but it will be dependant of
the Delphi runtime packages which will also become part of your product. And
you would have to install them on any system that your application is
installed on.
A second solution is by putting all processing logic in DLLs and just keep
all the forms and visible parts in the main executable of your application.
(You can put forms in DLLs too but they will behave a bit unexpected
sometimes.) The DLL would perform most of the business logic of your
appliction while all your executable does is display input screens, options
and call the appropiate DLL methods.
A third option is by building a multi-tier application. Again, here you
divide the user interface from the business logic. There are quite a few
techniques to do this but in general this means you will have one system
that contains the business locig and multiple clients that will connect in
some way to this system and call this business logic. Methods to do this can
be simple TCP/IP communication, DCOM or COM+ components or even more
complicated techniques like SOAP. Yet this technique can be over the top if
all you want to make is a simple desktop application.
But your solution is a good one too. A simple executable that uses
ShellExecute to start other applications. If ShellExecute succeeds you have
a handle to the new process that you can use in
WaitForSingleObject/WaitForMultipleObjects calls to see if the process has
ended again. Both functions are a bit complex API calls and I would suggest
you start reading the helpfiles and web first about them before using them.
Of course, the application would need to have a list of executables that it
can start and offer the appropiate menu-option if that executable is
available.
--
With kind regards,
\/\//\ Wim,
W.A. ten Brink
On 4/24/06, Roberto Freitas <[EMAIL PROTECTED]> wrote:
>
> Hi,
> Sometimes a program becomes so large (and actually with many different
> interconnected functions) that it would be interesting to divide it
> into parts or modules.
> For example, a management enterprise application. It has accounting,
> payroll, stock, etc, each one is an application itself.
> I would like to have a very small PROGRAM1.EXE with just a menu: after
> calling this first program, the user could choose on the menu the
> actual application he is interested on. Then, PROGRAM1.EXE, someway,
> would call accounting program, or payroll program, etc
> It's interesting because not ALL clients want to use ALL functions, so
> we can dispose modules accordingly.
> How to do it using Delphi?
>
[Non-text portions of this message have been removed]
-----------------------------------------------------
Home page: http://groups.yahoo.com/group/delphi-en/
To unsubscribe: [EMAIL PROTECTED]
SPONSORED LINKS
| C programming language | Computer programming languages | Java programming language |
| The c programming language | C programming language | Concept of programming language |
YAHOO! GROUPS LINKS
- Visit your group "delphi-en" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
