Hi Andrew:

AG>  TB> The thing that has been bugging me about point 1 is that it requires
AG>  TB> me to boot my PC.  I'm getting to the point where I get really annoyed
AG>  TB> whenever I have to boot my PC.  The user INI file would allow me to
AG>  TB> solve this problem, but feel weird about messing with it.

AG> I am told that much of the data could be re-digensted by a restart
AG> of the desktop. I would like to see docs on (a) what needs a truye
AG> reboot  and what jsut needs PM restarted. (b) how to restart PM
AG> manyually and from an Ap. 

I'm thinking that the CONFIG.SYS file will only be read during system
startup.  This makes it difficult to design an install procedure that
puts an environment variable definition into the CONFIG.SYS, that
doesn't want to reboot the machine.  I've tried calling my applications
from batch files which contain the environment variable definitions,
but this makes it inconvenient to change the location of an
application, because you have to hunt down a batch file that was stuck
somewhere in the path.  Also, I used to use a CRON that had difficulty
running batch files.  INI files are always dynamic, so there is never a
need to boot.


AG>  TB> My problem with point 2 is that the code I wrote to handle this (3 C++
AG>  TB> classes: Profile, ProfileSection, and ProfileEntry) really bloat out
AG>  TB> my code.  The first 2 classes inherit from ISequence, which makes them
AG>  TB> fairly expensive in terms of code size.  The OS/2 API adds roughly
AG>  TB> nothing to my executible size and probably executes faster.  BTW, I
AG>  TB> would be happy to share this code with anyone who is interested.

AG> Perhaps you could offer it to the DevCon program.

I would, but I'm not sure that it would be appropriate for widespread
use.  The source is quite small (it creates about 23K of object code),
but a simple test application that does nothing more than instantiate
this object ends up being 120K (this is with /EXEPACK:2).  For my part,
all I care about is programming productivity.  The code is fast and
easy to use.  Frankly, though, if IBM sent me this code, I would think
that it was pretty bloated.


AG> I have written this as plain old C instead of C++ and it takes
AG> very little space, but in its present form is (C) my clients. When
AG> the  contract is finished, I may do a total re-write and submit it.  

I have C code to do most of this, as well.  The problem with C is that
it is not as nice to work with.  I wanted something that was object
oriented.  A profile is a container of sections and a section is a
container of entries.  This way, I can pass a section to other objects
at instantation time, such as this:

{
    TProfile        profile;

    TDeviceModem        modem (profile.getSection ("Modem"));

    modem.initialize;
}

The point here is that TDeviceModem will have a constructor that
accepts a profile section.  This section might be called anything,
depending on the application.  It won't matter.  Everything is nice and
neat in one profile, but I can distribute sections anywhere I want.  If
modem decides to tinker with any of the entries (or add some) in the
section, a changed flag will be set in the entry or section.  When
TProfile destructs, it searches all sections and entries for changes to
see if anyone has changed anything.  If it has changed, it will save
the changes if the save flag has also been set (the default).

My thinking is that C++ makes this sort of thing very easy to work
with (for me), because it makes it easier to think about (for me).  As
best I can tell, my biggest problem is that TProfile and
TProfileSection inherit from ISequence.  This makes them _BIG_.  They
are suprisingly fast.  In fact, they execute much faster than my C code
which stores nothing in memory, it reads the file every time it looks
up an entry.  Of course, I think that the C code adds less than 10K to
my application and speed has never been a problem.  Its just that the C
stuff seems more complicated.  For me the whole value behind C++ is
being able to hide complexity.


AG> Submitting to DevCon would make your stuff the 'Dev Facto'
AG> standard, since few programmers would not have access to it. 

I'm flattered, but I'm not sure that my code is up to DevCon speed. 
Its quite complete, but if I got some code which added this little
functionality and made the .EXE this much larger, I would think that
the guy had written a bloated piece of crap.  This is why I'm not sure
that its up to DevCon speed.

Now, I want to add the ability to find out where the .EXE was executed
from and default to this path.  This is Mike Bilow's idea and it seems
to be a good one.  I'm still struggling with figuring out how to
implement it, though.  On the bright side, I would imagine that 20 or
so lines of C code to add this function will not make any noticeable
difference on the size of my executable.  :)


Best wishes,

Tom

 * KWQ/2 1.2g * PROFANITY: The language ALL programmers know...

--- GEcho/2 1.20/Pro