Mattias Gaertner wrote:
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
there is problem with names,
we have Dochange and lmChange
and
change and changed
and second
Delphi has OnClickChecked
and
we must different between change selection and toggle check box
Darek
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
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
