🚀 go-pugleaf

On 3 Aug 2004 05:49:49 -0700, Andrue Cope [TeamB] 
   <no.spam@spammy.com> wrote:

> Chris Croughton wrote:
> 
>> Hmm, it won't let me give the focus to an invisible component, it pops
>> up an error box telling me so.
> 
> Sounds like you are ignorning my earlier advice and setting "Visible"
> to false. Don't. Leave "Visible" set to true and put the component
> underneath another one (Right click, Control.., Send to back). It'll
> still be visible as far as Windows is concerned but the user won't be
> able to see it because it's covered up.

No, it did it when I just hid it under something (it seems that panels,
labels and TPaintBox won't hide a TEditBox, but buttons will).  However,
it will now get the focus, underneath a button...

>> Personally, I'd rather have a progress bar which is accurate
>> (it's amazing how many aren't accurate).
> 
> You're right that most are pretty bad and it's another pet hate of
> mine. A progress bar should give the user an idea of how long before
> they can give the next command. Most of the time this is the point at
> which the process stops but it doesn't have to be. Just so long as it
> gives me a good idea when to put my book down and reach for the
> keyboard :)

I often put in an audible indication if something is really going to
take a long time.  Something like setting the volume to max and playing
a WAV file saying "WAKE UP, IDIOT!" <g>.

>> If I have a
>> button (and the one I clicked to start the operation will do as well
>> as any), force everything else to give it the focus, and use the
>> OnKeyDown event of that
> 
> Yeah but then we're back to losing [Space] activation on a button plus
> users can see the focus border around the button and might wonder
> what's going on.

True.  What I'd really like in that case would be a 'sticky' button to
indicate that it is running.  Basically it's modal, either it's running
in which case special keys apply, or it's stopped and ordinary rules
apply.  I could, for instance, grey out (disable) all of the other
buttons.  Or, just thinking about it, I could use radio buttons to start
and stop, and it would make sense if they kept the focus...

>> TEdit boxes seem to interpret keys themselves, though, to do their own
>> editing.  Or can that be stopped?
> 
> /That's/ why I've set the form's Keypreview to true (knew there was a
> reason <g>). By setting that it gets first dibs on keypresses..but only
> grabs them when the TEdit has the focus:

Aha!  Yup, that works and I can intercept every key (except F12, at
under the IDE that invokes the debugger but run separately it's fine).

Thanks, that does it.

> If the viewer doesn't have the focus the function does nothing and the
> keypress gets handed on to someone else to deal with.

Yup, that makes more sense.

> Ah..it's all coming back to me now :)
> 
>> I know a number of sysadmins who
>> don't understand how I get SCSI to work without sacrificing a goat
>> <g>...
> 
> Or Windows networking, or RS232 connections :)

Oh, RS232 conections are easy.  Soldering, on the other hand...

Thanks,

Chris C