Power Point, I would advise you to divide your project into several parts
but as most of us pointed here, dividing your modules won't help you much
technically...
Even if you have common libraries used in all the modules, the same library
will be compiled more than once with each exe, as pointed out already, the
sum of all the exes will be larger than 1 exe. Take into consideration also
that its not very practical to update many exes. In case you modify a small
function in Unit1.pas used in all the modules, you have to rebuild all the
modules and send them all to the client for example
As I speak, our two applications have 24MB and 8 MB of size and they never
raise memory problems because all the modules are controlled by some
licensing mechanism, components and forms are created and destroyed only
when needed, etc...
Is your main goal to control the licensing of the client or managing your
memory in the best way possible?
-----Original Message-----
From: [email protected] [mailto:[EMAIL PROTECTED] Behalf
Of Jangita
Sent: Tuesday, April 25, 2006 11:45 AM
To: [email protected]
Subject: Re: [delphi-en] Re: Dividing a large program in parts
you might want to use shared memory or a process check if the main
program is running instead of using command lines that can be sniffed.
good idea tho
Steve wrote:
> Hi Roberto
> 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]
> Yahoo! Groups Links
>
>
>
>
>
>
>
-----------------------------------------------------
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]
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.
