geez
[Top] [All Lists]

Re: Got some useful data

To: Byron Short <bshort@AFSinc.com>
Subject: Re: Got some useful data
From: Mark Sirota <msirota@isc.upenn.edu>
Date: Tue, 24 Aug 1999 10:24:56 -0400
Byron Short wrote:
> I'm pretty flexible, as long as I don't have to keep an actual
> stopwatch running...let me know when you've gotten your money's worth!

Sounds fair to me.

>> Last, I frequently get this problem where I have multiple runs
>> displayed, and I want to select one to change its colors or
>> something, and all of a sudden it maximizes and I can't see the other
>> ones.  Is there some way to disable this frustrating behavior?
> 
> Is this from double clicking the title bar?  That behavior is standard
> Windows fare.  I don't think there's a way to disable it.  Of course
> pressing F7, the shortcut for Windows|Tile will put everthing on
> screen and in sight, or better yet, just press the "two box button" to
> restore the window to it's previous mode.

No...  If I am in "Tile mode", and then I single click on any one
titlebar, that window maximizes.  If I go back into tile mode, the
window that was most recently maximized is now in the first tile
position, so the order doesn't even remain.  For example, if I have my
three runs tiled side-by-side, and then want to adjust the map on the
middle run, I'll single-click that titlebar so that I can then hit
"adjust map", but when I click the titlebar the window maximizes.  If
I then minimize it, it's not the right shape, size, or position.  If
I select "Windows|Tile", then that window ends up on the left,
instead of in the middle where it started.  I'm sure you can imagine
that this is frustrating.

I'm not a Windows guru...  Does anyone know of a way to change this
behavior?

Thanks!

Mark
> 
> > (It's also frustrating that the software doesn't understand filenames
> > longer than eight characters...  As a human factors engineer who's been
> > in the software development world, if you'd like more feedback on making
> > this more usable, I'd be happy to provide some -- but be prepared...)
> 
> This is of course a side-effect of us compiling the program as a 16 bit
> application, which is done to try to maintain compatability with older
> 3.1 Windows computers.  Because those that use laptops to record are
> often using ancient old laptops (rather than putting their slick and
> pricey new machines into the race car environment) we are perhaps a bit
> hypersensitive about maintaining 3.1 compatibility.  Heck, when I record
> with a laptop, it's my old trusty (and rusty?) Toshiba 486-50 running
> 3.1.
> 
> But with that said, at some point we'll re-compile the whole thing into
> Delphi 2+ (I think they are up to Delphi 5 now, but everything from
> Delphi 2 on is 32 bit), and pick up the longfilenames at the same time.
> 
> --Byron

<Prev in Thread] Current Thread [Next in Thread>