I have done and still do the way that you are trying to do.
I have created a School Information Network System and call it Hermes,
In Hermes there are Behavior, Stock Control, Call Logging, Asset, Special
Needs, Computer information collection programs and lots more.
All controlled by a single logon program and MSSQL
How it works:
The main program has a logon screen, so users logon with a user name and
password, as they logon the main program checks their security and access
against the MSSQL and then displays the icons that they are allowed to use
in an outlook type row of buttons on the left hand side of the screen.
Then when they click onto these buttons the other program that they require
then open and run, I use command lines to run the programs which holds their
logon number, this lets the program run, if the program does not have a
command line then it displays a logon screen,
So anyone can run my exe but each one shows a logon screen unless it is run
through the main logon program,
Also each program when it is run checks the user security and access and
allows or disallows the buttons on their forms, so if you have a default
user say security 0 then they will/will not be allowed to delete or create
item etc, etc.
Each program has its own security settings which is held in the MSSQL
And when the administrator logs on they get other forms which have the
users, Security and access, program security, etc forms which they use to
setup the users or import them from SIMS,
When the main program run it does some checks, like is the software current,
is the license still valid, 7 days from the expire of the license a message
will pop up telling everyone that they have x days of days left. Does an
automatic backup of the MSSQL
Also checks on the web to see if there is a new version on the web and if
there is will down load it and upgrade the main MSSQL database, sets the
version in the database, then when the main program runs, it knows the
database is different and run the update exe from the server
Thus updating the local files,
I am working on version 3 of Hermes which has a small exe in the task bar,
which will run when the user logons onto the machine and will check the
security etc and show the icons that they use, then when the user right
clicks on the Hermes icon in the task bar they can then select what program
they want and run it without even logging onto Hermes.
Hermes3 is looking at the MSSQL every 30 seconds to see if there any
messages for that user or machine name, if there is it gets the message,
reads the message id and then runs what ever I want the local machine to do.
e.g.
Do a screen dump, reboot the machine, power off the machine, log off the
user, update, and restart, close down Hermes 3, get the files versions of
the Hermes exe
Get the version of Sims .net on the local machine and even run the Sims .net
upgrade on the local machine,
This is like client \ Server but not.
Sorry it a log one but its just to let you know that it can be done
Steve
-----Original Message-----
From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf
Of Roberto Freitas
Sent: 24 April 2006 13:56
To: [email protected]
Subject: [delphi-en] Re: Dividing a large program in parts
Thanks for your explanations.
I'll try the way to use ShellExecute or even another function I saw
somewhere = WinExec.
Following your advise, I should first start reading the helpfiles and
web about them.
The problem is: in Delphi Help (I use Delphi Enterprise 7.0) I could
not find any entry for ShellExecute or WinExec.
So, until now I have no way to read about them, more, I have no idea
how to use them.
Any other advise, please?
--- In [email protected], "Workshop Alex" <[EMAIL PROTECTED]>
wrote:
>
> As I see it, you have multiple options. One way would be by using
runtime
> 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]
Yahoo! Groups Links
-----------------------------------------------------
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.
