Phil


>So then I took to slowly putting certain ones back until I found the ONE
>culprit which was the last one I tried of course.

By definition - at that point you stop looking

>It was a DBCheckBox of all things that has an OnClick Event... Well that
>makes no logic, it's not being clicked by the user, but is still firing
>off when the record is deleted. Go figure?
>
>I'll have to set a flag in the OnClick event to test if I've pressed the
>cancel button.
>
>Am I missing something, why would an OnClick event fire from a
>DBCheckBox when deleting a record.

From memory I think DBCheckBox.OnClick is fired every time the record changes. Makes no sense to me either and I never did track down if that's so and if so why. All my DBCheckBoxs got replaced by the TMS version which does things "properly".

Roy Lambert [Team Elevate]

>> So then I took to slowly putting certain ones back until I found the ONE
>> culprit which was the last one I tried of course.
>
> By definition - at that point you stop looking
>
>> It was a DBCheckBox of all things that has an OnClick Event... Well that
>> makes no logic, it's not being clicked by the user, but is still firing
>> off when the record is deleted. Go figure?
>>
>> I'll have to set a flag in the OnClick event to test if I've pressed the
>> cancel button.
>>
>> Am I missing something, why would an OnClick event fire from a
>> DBCheckBox when deleting a record.
>
>  From memory I think DBCheckBox.OnClick is fired every time the record changes. Makes no sense to me either and I never did track down if that's so and if so why. All my DBCheckBoxs got replaced by the TMS version which does things "properly".
>
> Roy Lambert [Team Elevate]


Hi Roy,

No I didn't stop looking, but I was able to locate it down to that one
DBCheckBox in the end as it calls some code that sets a 'date based'
Filter on q ListSource of one of the DBLookupComboBoxes, thus the date /
time error message.

I use TMS components too, so maybe I can switch those few over,
generally I try to use standard components where I can and use TMS stuff
if I need something more flexible.

Apparantly the OnClick event runs on a few other standard components
when its not actually been clicked and no one seems to understand why it
was setup this way.

http://delphi-kb.blogspot.com.au/2010/11/how-to-override-standard-onclick-event.html

Thanks again,

Phil.

Phil

This is normal, as the state of the checkbox changes to the NULL-State. So
if your existing record is a checked Checkbox and you delete that one
recrod, the checkbox changes to unchecked or grayed state for null values.
As of this change, this will trigger a click event of the Checkbox
component. Thats normal Windows behaviour. You must handle this in your
Event.

Regards
Rolf

Rolf


>This is normal, as the state of the checkbox changes to the NULL-State. So
>if your existing record is a checked Checkbox and you delete that one
>recrod, the checkbox changes to unchecked or grayed state for null values.
>As of this change, this will trigger a click event of the Checkbox
>component. Thats normal Windows behaviour. You must handle this in your
>Event.

A very good explanation but my own view is that an OnClick event should fire when the component is clicked. The event that fires when it changes is called .... wait for it ....  OnChange.

Very confusing nomenclature.

Roy Lambert

Roy

Yes, it would make more sense, if it isn't fired for this case, but this is
as designed this way since Delphi 1 and changing this would break much, much
of exisitng code. As of that, Borland did never fix this.

Regards
Rolf

"Roy Lambert" <roy@lybster.me.uk> schrieb im Newsbeitrag
news:190B295C-9E92-4910-91C9-54F674EADFE4@news.elevatesoft.com...
> Rolf
>
>
>>This is normal, as the state of the checkbox changes to the NULL-State. So
>>if your existing record is a checked Checkbox and you delete that one
>>recrod, the checkbox changes to unchecked or grayed state for null values.
>>As of this change, this will trigger a click event of the Checkbox
>>component. Thats normal Windows behaviour. You must handle this in your
>>Event.
>
> A very good explanation but my own view is that an OnClick event should
> fire when the component is clicked. The event that fires when it changes
> is called .... wait for it ....  OnChange.
>
> Very confusing nomenclature.
>
> Roy Lambert

Roy,

I did just a quick read of the Windows SDK and it seems, that Microsoft has
designed the Checkbox control in this way, that the control sends a
BN_CLICKED notification message (CM_COMMAND) whenever the state changes. It
doesn't make any difference if the user has clicked the button or something
different changed the button state with an BM_CLICK message. So the root of
the problem may lay in the MS implementation of that control.

Regards
Rolf

"Roy Lambert" <roy@lybster.me.uk> schrieb im Newsbeitrag
news:190B295C-9E92-4910-91C9-54F674EADFE4@news.elevatesoft.com...
> Rolf
>
>
>>This is normal, as the state of the checkbox changes to the NULL-State. So
>>if your existing record is a checked Checkbox and you delete that one
>>recrod, the checkbox changes to unchecked or grayed state for null values.
>>As of this change, this will trigger a click event of the Checkbox
>>component. Thats normal Windows behaviour. You must handle this in your
>>Event.
>
> A very good explanation but my own view is that an OnClick event should
> fire when the component is clicked. The event that fires when it changes
> is called .... wait for it ....  OnChange.
>
> Very confusing nomenclature.
>
> Roy Lambert

Rolf


MS to blame - that wouldn't surprise me in the least. But the old Borland developers could have at least named the event OnChange

Roy Lambert

Roy,

<< A very good explanation but my own view is that an OnClick event should
fire when the component is clicked. The event that fires when it changes is
called .... wait for it ....  OnChange. >>

FYI, EWB does it correctly.  Actually, there's no OnChange, but for
dataset changes you would use OnRowChanged anyways, and for user stuff you
would use OnClick.  If you change it yourself in code, then you're on your
own...

Tim Young
Elevate Software
www.elevatesoft.com