Board index » delphi » DBRadioGroup - {*word*193} - bug lives

DBRadioGroup - {*word*193} - bug lives

Howdy,

This is NOT a new issue. A search shows this bug back at least to 1997.
Probably been around longer. It appears to never have been fixed or even
addressed.

I'm using D6 update 1, win xp.

REALLY need a fix. Spend a new record, for me, amount of time before finally
tracking to the component and not my code.

The effect is the control "changes" data without users knowledge. Is "{*word*193}
bug" not correct name for this? :)

I need not write a new description since this has been done. Will just
re-post a well written description from: Bill Friedrich,
1997/07/13,comp.lang.pascal.delphi.databases, Subject: Interesting BUG in
DBRadioGroup.

"
Here's a Major bug in the TDBRadioGroup Component (Delphi I AND Delphi
II) I haven't tried it in Delphi III, but i suspect it will be there
also.

The Effects of the Bug:

 DBRadioGroup's value has the ability to change, on the screen
and in the DataSource, without the knowledge of the user.

To See the bug in Action:

 Create a new form & add these components:

 TDBRadioGroup
 TTable
 TDataSource
 TDBNavigator

Link it all up so you can navigate the table and view the RadioGroup
values.

NOW:

 Give focus to any one of the Radio Buttons.

 Use the mouse on the navigatator to move a couple of records
away from the current one.  NOTICE how the Dot moves from one radio
button to another as you change records.  NOTICE how the Focus
Rectangle does NOT move with the Dot.

Now for the kicker, Continue scrolling through the records until you
land on a record where the Dot and the Focus Rectangle are not
together on the same Radio Button.  Use the Mouse or Alt-TAB to change
to a different program, basically take the focus away from your test
application.  Now bring the focus back to your application (make it
the forground task).

What has just happened?!, I'll tell you in case you didn't notice...

 The Dot has just moved from the Radio Button where you left it
-- to the RadioButton that had the Focus Rectangle before the task
switch!!

Now if you scroll to the next record, the current record will be
posted, and you didn't even notice that the value was changed.

Note: you can also get the Focus Rectangle to reside on a different
RadioButton than the one with the Dot by: clicking the RadioButton --
holding the mouse button down and dragging to another
location on the screen then letting go.

Note: the actual bug seems to reside in TRadioButton itself, (this
phenomenon occurs for all of the components that use Radio Buttons,
but it is particularly lethal in Database Applications because of the
ability of the Dot to move without the Focus Rectangle also moving.)
Also, this bug is in delphi Delphi, the standard windows controls do
not do this.

--------------

I called Borland about this, and they were stunned... (well not THEY,
but the tech support guy anyway)

Does anyone know if there's a fix for this component anywhere... I can
fix the problem on a form level (by forcing the Focus Rectangle to go
to the Radio Button that has the Dot - when the form receives a
WM_ACTIVATE), but not on a component level,, anyone?
"

Thanks for all suggestions.

Regards,
Jim

 

Re:DBRadioGroup - {*word*193} - bug lives


Quote
"J Tabor" <den...@taborsoft.com> wrote in message

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

Quote
> This is NOT a new issue. A search shows this bug back at least to 1997.
> Probably been around longer. It appears to never have been fixed or even
> addressed.

Interesting.  Compare & contrast with recent thread in this group -

Subject: Radiobutton checked when form focused
Date: 15 October 2002
From: Markus Spoettl

--
Regards,
Chris Luck.

Re:DBRadioGroup - {*word*193} - bug lives


Hi Mr Wizard,

Thanks for the suggestion. I'll have a go at your suggestion.

Regards,
Jim

"Peter Below (TeamB)" <100113.1...@compuXXserve.com> wrote in message
news:VA.00009485.009e8909@antispam.compuserve.com...

Quote
> In article <3db1d...@newsgroups.borland.com>, J Tabor wrote:
> > This is NOT a new issue. A search shows this bug back at least to 1997.
> > Probably been around longer. It appears to never have been fixed or even
> > addressed.
> -description snipped-
> > Does anyone know if there's a fix for this component anywhere... I can
> > fix the problem on a form level (by forcing the Focus Rectangle to go
> > to the Radio Button that has the Dot - when the form receives a
> > WM_ACTIVATE), but not on a component level,, anyone?

> You can try this: derive a new component from TDBRadioGroup and override
the
> protected Change method and add a private FInChange field to guard against
> recursion:

>   private
>     FInChange: Boolean;
>   protected
>     procedure Change; override;

> Procedure TMyDBRadioGroup.Change
> Var
>   i: Integer;
>   hasFocus: Boolean;
> Begin
>   If FInChange Then Exit;
>   FInChange := true;
>   try
>     hasFocus := false;
>     for i:= 0 to Controlcount-1 do
>       if (controls[i] as tRadiobutton).Focused Then begin
>         hasFocus := true;
>         break;
>       end;
>     if hasFocus then begin
>       for i:= 0 to controlcount-1 do
>         if (controls[i] as tRadiobutton).checked and
>            not (controls[i] as tRadiobutton).Focused
>         then begin
>           (controls[i] as tRadiobutton).Setfocus;
>           break;
>         end;
>     end;
>   finally
>     FInChange := false;
>   end;
>   inherited;
> End;

> Untested, not even compiled! The FInChange check may be unnecessary, but
> better safe than sorry...

> --
> 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

Re:DBRadioGroup - {*word*193} - bug lives


Hi,

Thanks for the suggestion. Perhaps I should have described the component
flaw myself. Could anyone possibly argue this isn't a component flaw?

This flaw is not caused from some tricky developer. It is straight out of
the box Delphi and anyone using TDBRadioGroup in the simplest way is
vunerable.

The TDBRadioGroup places the dataset into edit mode and changes current
record field to match one that was previously being viewed. There is no
editing by user involved, just browsing records and switching form focus.

The TDBRadioGroup component flaw is easy to reproduce. You have a form with
TDBRadioGroup properly connected. You have a TDBNavigator setup to browse
records. You click the navigator to change records then shift focus away
from the form and back.

Apparently the TDBRadioGroup "remembers" the value from the previous record
you were viewing and changes the current record to match. Your data is now
incorrect. It seems TDBRadioGroup simple just does not stay current.

I don't wish to be argumentative, but it would seem after 5 years and
numerous releases this would have been fixed. HOWEVER, it may be a win xp
issue - that would releave a small part of the responsibility but obviously
not all.

The "AppDeactivate" solution doesn't seem fitting for this case, as it can
be caused by switching forms within the app  <G>.

Regards,
Jim

Re:DBRadioGroup - {*word*193} - bug lives


Would you agree "the simplest fix is often best"? <G>

The problem is TDBRadioGroup "focused" item is NOT forced to be same as the
current/selected item. So, when focus is moved away from the form containing
TDBRadioGroup control and then focus is returned, RadioGroup changes
current/selected item to match the focused item. It probably should be the
other way around.

In any case it appears the fix is simple enough.  In RadioGroup controls
OnChange event handler:

procedure TForm1.DBRadioGroup1Change(Sender: TObject);
begin
  DefocusControl(DBRadioGroup1, False);
end;

Appears to work without side effects.

Thanks Again,
Jim

Re:DBRadioGroup - {*word*193} - bug lives


Howdy,

Thanks for all your comments. I agree on the focus change - to nil. Thought
of that later last night. :)

Anyway this work around will have to do, for my junk, until a proper fix
appears. :)

Regards,
Jim

Other Threads