On Sun, 04 Jun 2006 23:30:29 +0200
darekm <[EMAIL PROTECTED]> wrote:
>
> repair patch
> change typo
> remove change in DestroyWIndow
Applied. Thanks.
I replaced the KeyPress with KeyDown and set Key:=VK_UNKNOWN, so other parts
know, that the key was handled.
Why is a LM_CHANGED message sent, but a OnClickChecked triggered?
Why not OnChange?
Mattias
>
> Mattias Gaertner wrote:
>
> >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.
> >
> >
> Should then be
> added {$IFDEF TRACE} (or something similar) ?
>
>
> Darek
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
