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
- 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.
