Re: Advice needed for a proposal

From: Bill Mogk (wmogk_at_whmsoftware.com)
Date: 12/21/03 

Date: Sun, 21 Dec 2003 14:02:23 -0500

Hi Jim,
Here are some random thoughts,

I wrote a similar app for a client. The original version had two programs a
"server" program that collected, stored and displayed data, and a "client" app
that was basically the display portion of the server application, so it could
not modify any settings or database tables, but the client application could
acknowledge alarms.

The server application is a standard delphi application, that runs all the time
and collects data a specific (user configurable) intervals. The data is stored
in an Advantage database. I used Advantage because the local server version is
free and it is easy to upgrade to the commercial remote server versions. As
mentioned elseware, if encryption is necessary Advantage can do that as well,
although I haven't used it. I used database tables because that is the way I
think, and I found it easier to let the database do the ordering, be it by site,
date/time, or some other criteria. This application can also do semi-real time
display of values by polling the connected unit at user-configurable time periods.

The database tables are handy for alarm logging and reporting and also for
playing back the real-time data. Also, I use the database system for creating
simple "user profiles" to controls access to certain parts of the application
and the database tables.

As far as alarm logging, this application can receive incoming calls from remote
units and can also connect to the unit to get the alarms as necessary.

The client is happy with this setup (and continues to use it) but in my free
time, I rewrote the server part of the application into four modules:
        1. The Data Collector, which is a Windows service that does only what it says
it does.
        2. The Management application which controls the all the system wide settings,
and configuring the sites (ID, name, phone number, connection stuff, etc), and
controls the service.
        3. The Display application, which is pretty close to the old client application.
        4. A "Service Simulator", which accesses all the parts of the service
application, but runs as standard Delphi application, and provides some display
functions. This simplified debugging of the service related code. The "Service
Simulator" could also be used to create simple, demos of the system, or be
delivered as a "lite" version.

The service application was certainly a lesson learned, since I had never been
too cautious about splitting the data handling from the GUI parts of an
application. It was quite a task to rip the data parts from the GUI parts of
the old application, but it is well worth it in the end, I think. Since that
revelation, I always split the GUI and data, except in very simple paps.

This system has never been delivered - I did it mostly for my own benefit, and
as a prototype for a version 2.

On the display side, I have used a couple of free ware and mostly standard
windows controls for the instrument display, but I like the GUI stuff from some
of the vendors that make instrument-type controls (like TMS). If the client
ever goes ahead with a version 2, I may talk him into upgrading the display
application with these professional controls.

Finally, I when I did the rewrite, it built the help file as I coded the
programs. It seemed to make the help file job less onerous, if I could complete
a screen, and use the help writer (I use H&M) to document it right away. I
found it helped me write the application, because if I wrote in the help file,
"The user must do X in order for Y to happen.", then I would sometimes question
why I put this limitation on the program, and then I would go back and remove
that limitation if necessary.

To keep the help file simple, my context sensitive help goes only to the screen
level - if you press F1 anywhere on a particular screen, the the help for that
screen pops up. I agree, as stated elseware in this thread, that help writing
takes as least as long as writing the application.

I think I have restated a lot of what Wayne has said, but I hope I have given
you a bit of insight.

You can email directly, if you think I can help any more.

Bill

Relevant Pages

  • Re: Help with first VB application - Data Entry form
    ... I assumed a desktop / winform client application ... time' stamp from the database machine - control machine ... ... problem solved - web server is control system. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Help with first VB application - Data Entry form
    ... I assumed a desktop / winform client application ... time' stamp from the database machine - control machine ... ... problem solved - web server is control system. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Remobjects v KBM
    ... >> client query components) follow from that. ... Then, connections can be created to say SQL Server, Oracle, Interbase and ... can then be created from the abstract dataset definition in 'customers' to ... implicitly - this makes your code not be database connection specific). ...
    (borland.public.delphi.thirdpartytools.general)
  • Re: Help with first VB application - Data Entry form
    ... stamp from the database machine - control machine ... ... unnecessary data to the client ... ... and when building a database independent UI / Client - Server application, ... JavaScript, for example) and thus, will get the time from the web server, ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Opinions needed about the best "Middleware suite" kbmMW vs. RODA
    ... kbmMW supports cross db in such way that all you need to do in your application is to set one property to switch to ... What one have to concentrate about is minimizing the amount of data moved from the app server to the client. ... C/S setup's usually have a quite active chatter going on between the client and the database, ...
    (borland.public.delphi.thirdpartytools.general)