On Fri, 02 Jun 2006 08:31:18 +0200
DarekM <[EMAIL PROTECTED]> wrote:
> Vincent Snijders napisa__(a):
> > DarekM wrote:
> >> Vincent Snijders napisa__(a):
> >>
> >>> darekm wrote:
> >>>
> >>>> Hi
> >>>> attached patch added:
> >>>> ChecklistBox.onClickCheck (for GTK and GTK2)
> >>>> publish property TCheckBox.font
> >>>> remove tCustomLabel.FontChange(Sender: TObject); (default is
> >>>> fontchanged)
> >>>>
> >>>>
> >>>
> >>> Thanks for the patch. I have the following questions:
> >>>
> >>> Why is the following debugln commented out? Doesn't calling
> >>> DestroyHandle, if the handle is not allocated, mean that there is a
> >>> bug somewhere? Raising the exception is maybe too harsh, but
> >>> silently ignoring it, doesn't seem a good idea to me.
> >>>
> >>>> @@ -3287,7 +3292,8 @@
> >>>> AWinControl: TWinControl;
> >>>> begin
> >>>> if not HandleAllocated then begin
> >>>> - DebugLn('Warning: TWinControl.DestroyHandle
> >>>> ',Name,':',ClassName,' Handle not Allocated');
> >>>> + //DebugLn('Warning: TWinControl.DestroyHandle
> >>>> ',Name,':',ClassName,' Handle not Allocated');
> >>>> + exit;
> >>>> //RaiseGDBException('');
> >>>> end;
> >>>>
> >>
> >> Delphi don't claim when handle =0
> >
> > In that case, IMHO Delphi is too tolerant for component writers.
> >
> > But maybe other developers see valid reasons for calling DestroyHandle
> > when a handle is not allocated (anymore).
> problem is with DestroyWindow. Under Delphi I call it many times (to
> free resources). why testing if was painting before or not (under
> Delphi i dont have to). And for me: its not problem try to destroy
> object second time (enough test), but when we try to create it twice or
> use not initialized
The debugln was there, because the LCL controls do free the Handle only for
good reason. If the handle is already freed, you found a bug. This helped to
find a lot of bugs and overhead in the last years.
Of course this 'only for good reason' rule is only valid for LCL controls.
Programmers using the LCL are of course free to release as often they want.
The debugln should give them only a clue, that they could reduce some
overhead.
Mattias
> >
> >>
> >>>
> >>> <snip>
> >>>
> >>>> @@ -132,6 +139,12 @@
> >>>> FItemDataOffset := inherited GetCachedDataSize;
> >>>> end;
> >>>>
> >>>> +
> >>>> +procedure tCustomCheckListBox.DoChange(var Msg);
> >>>
> >>>
> >>> <snip>
> >>>
> >>>> +procedure tCustomCheckListBox.ClickChecked;
> >>>
> >>>
> >>> Why not TCustomCheckListBox.DoChange and
> >>> TCustomCheckListBox.ClickChecked?
> >>
> >> I'm not undestand.
> >> ClickChecked - name the same like in Delphi
> >> DoChange - Lazarus use LM_Change message (the same like in
> >> tCheckBox), Delphi don't use messages
> >
> > Sorry, this maybe a bit nitpicking:
> > Your patch:
> > tCustomCheckListBox.ClickChecked
> > My proposal:
> > TCustomCheckListBox.ClickChecked
> >
> > Note the capitalized first letter.
> Of course. Have I send patch once more.
> >
> > Vincent
> >
> > _________________________________________________________________
> > To unsubscribe: mail [EMAIL PROTECTED] with
> > "unsubscribe" as the Subject
> > archives at http://www.lazarus.freepascal.org/mailarchives
> >
>
> _________________________________________________________________
> To unsubscribe: mail [EMAIL PROTECTED] with
> "unsubscribe" as the Subject
> archives at http://www.lazarus.freepascal.org/mailarchives
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
