In article <3dac2...@newsgroups.borland.com>, Markus Spoettl

You are lumping radiobuttons and checkboxes here in a most confusing
manner.

Get Delphi 7. I could not reproduce your problem with it.

--
Peter Below (TeamB)  
Use the newsgroup archives :
http://www.mers.com/searchsite.html
http://www.tamaracka.com/search.htm
http://groups.google.com
http://www.prolix.be

"Markus Spoettl (toolsfactory)" <mar...@toolsfactory.com> wrote in message
news:3dac2acb@newsgroups.borland.com...

I'll assume the 'check boxes' was a typo.

I looked at RadioButton behaviour in Word & Excel 2000.  Here the behaviour
seems to be as you require it but I'm far from convinced that this MS model
shows 'correct' or desirable functionality.  For instance, once the form gets
focus again the keyboard behaviour is now faulty, hit any arrow-key and the
only effect is for the selection to always go to the focused button (even when
playing with 3 buttons).  This rather confirms my previous thought, that
selection should be where the focus is.

Personally, I think you are working hard at inventing a problem (people who
kill a click when half-way through deserve what they get).

However....

On further reflection, ISTM that both the MS and Borland buttons exhibit the
same defect in functionality by not shifting the selection immediately the
mouse goes down.  When using the keyboard the focus and selection change
immediately you hit the key but, when mousing, the button waits for MouseUp
before changing selection.

Solution:

procedure TForm1.RadioButton1Enter(Sender: TObject);
begin
  RadioButton1.Checked := true;
end;

Does that generate any undesired side-effects for you?  Can't see any at this
end using Win98.

--
Regards,
Chris Luck.

I'm sorry, I meant RadioButtons.

I can (using TRadioButtons) and the steps I provided.

Sorry again for the confusion.

Markus

--
______________________________________________________________________
Markus Spoettl,
toolsfactory
mailto:mar...@toolsfactory.com
http://www.toolsfactory.com

Chris,

Yes, sorry about that.

The steps I provided were for showing a case where the focus and the
checked state are not on the same radio button. This can happen - for
instance - if you have an application setting the state of a group of
radio buttons programatically while one has the focus, and the focused
is no longer the checked one.

This is not a solution for the real problem, the radio button changing
it's check state when activating the application, see above.

Markus

--
______________________________________________________________________
Markus Spoettl,
toolsfactory
mailto:mar...@toolsfactory.com
http://www.toolsfactory.com

"Markus Spoettl (toolsfactory)" <mar...@toolsfactory.com> wrote in message
news:3dac8b02@newsgroups.borland.com...

This problem is generated entirely by your apparent dis-inclination to set the
focus at the time you set the selection.  I don't understand you aversion to
doing this.

If you create a descendant with an overridden DoEnter you could set the
selection just by setting the focus.

--
Regards,
Chris Luck.

Let me explain in more detail, perhaps I was unclear previously. Assume
you have a scenario where your application has a configuration that can
be loaded from files. A certain set of options is displayed using (among
others) TRadioButtons. Now the user clicks some controls and therefore
changes configuration settings. Say he clicks one radio button, so the
focus changes and so does the check mark.

NOW! Imagine what happens if the user loads another set of configuration
settings and the application changes the checked state of the
radiobuttons in a way that the currently focused radio button is
unchecked. Note that there is nothing wrong with this setup so far, only
the focused radio button - because the user has focused it previously -
and the checked state - because the application has changed it during
loading of the new configuration - do not match.

SO? Try switching task and go back. The setting that was loaded from
into the controls is suddenly lost because the radio button that is
focused is now checked too, which is not what was loaded programatically.

Don't you see the problem here?

Markus

--
______________________________________________________________________
Markus Spoettl,
toolsfactory
mailto:mar...@toolsfactory.com
http://www.toolsfactory.com

"Markus Spoettl (toolsfactory)" <mar...@toolsfactory.com> wrote in message
news:3daca37f$1@newsgroups.borland.com...

Yes.  Override SetChecked and set the focus there.

--
Regards,
Chris Luck.

news:3dacc257@newsgroups.borland.com...

Oops.  No, not a good place to mess with focus!  Though it is specifically a
focus issue.  If no RadioButton is focused then swapping apps does not cause a
problem and it works as expected/desired.  I have concluded that it has to be
handled at the Application level.  I tried first with Application.OnActivate
but that is much too late in the process and it needs to be handled in
Application.OnDeactivate.  See if this helps at your end.

type
  TForm1 = class(TForm)
....
    procedure AppDeactivate(Sender: TObject);
  private
    { Private declarations }

procedure TForm1.AppDeactivate(Sender: TObject);
var
  I: Integer;
begin
  if Screen.ActiveControl is TRadioButton then
  for I := 0 to Screen.ActiveControl.Parent.ControlCount-1 do
  if (Screen.ActiveControl.Parent.Controls[I] is TRadioButton)
    AND (TRadioButton(Screen.ActiveControl.Parent.Controls[I]).Checked) then
    ActiveControl := TWinControl(Screen.ActiveControl.Parent.Controls[I]);
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  Application.OnDeactivate := AppDeactivate;
end;

--
Regards,
Chris Luck.

Markus,
Just an idea- instead of Checking the RB's with the usual OnClick event,
do it half the way, on the OnMouseDown event Handler. implement
for both RB's one Handler and check (sender as TRadioButton).
i believe it will bypass the problem + the user is aware for each press.
-----
hth
jacob

"Markus Spoettl (toolsfactory)" <mar...@toolsfactory.com> ??? ??????
news:3dac2acb@newsgroups.borland.com...