Re: Preventing pasting in a TEdit
From: Rob Kennedy (me3_at_privacy.net)
Date: 08/04/04
- Next message: Bruce Roberts: "Re: Preventing pasting in a TEdit"
- Previous message: Andrew Skinner: "Re: Delphi 6 personal - download"
- In reply to:(deleted message) not_at_any.adr: "Re: Preventing pasting in a TEdit"
- Next in thread: not_at_any.adr: "Re: Preventing pasting in a TEdit"
- Reply:(deleted message) not_at_any.adr: "Re: Preventing pasting in a TEdit"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 04 Aug 2004 14:02:58 -0500
not@any.adr wrote:
> On Wed, 04 Aug 2004 09:48:58 -0500, Rob Kennedy <me3@privacy.net> wrote:
>>Why would you have to work at the API level? Couldn't you just override
>>the WndProc method or add custom message-handling methods?
>
> Unfortunately that's not possible. Windows controls are Win Classes and each
> is a unique instance, so they have their own message procedures and
> dispatchers.
Have you ever looked in the Controls.pas unit? Take a look at how
TWinControl works. TCustomEdit and TEdit descend from that. TCustomEdit
has its own WndProc method, and handles its own messages. What it
doesn't handle it passes along to its ancenstor methods, and eventually
to DefWindowProc. (I explained this in more detail a couple of weeks
ago.) At the base of it all is the Windows EDIT class.
(Actually, by the time you delve as far into the VCL as TCustomEdit is,
it doesn't need to override WndProc, and it only has one message handler
for an OS-generated message. The rest of its VCL-specific functionality
is implemented by overriding virtual methods. TWinControl is where most
of the action is.)
> Far and away the largest number of messages going into Windows
> controls never get anywhere near the application program's winproc or
> dispatcher... your application could be crippled if they did.
When I suggested overriding WndProc, it was implicit that I was
referring to TEdit.WndProc, not TApplication.WndProc (which can't be
overridden anyway).
> Subclassing is a fairly common and easily enacted way of modifying the
> behaviour of windows classes (not just controls)...
Not in Delphi, it isn't. Not by non-Borland developers, anyway. The VCL
uses Windows subclassing, but it exposes more Delphi-friendly ways for
the rest of us to use.
> Essentially what you do is
> replace the default winproc in the class with your own winproc, you then call
> the default winproc from your own custom procedure.
Thank you, but I understand quite well what subclassing is.
> Most Delphi visual controls are really just heavily subclassed windows
> controls. The advantages are obvious, you can create your own menus, control
> a lot of various features, etc. But the disadvantage is that by subclassing
> *everything* you do slow the system down noticeably and a LOT of extra code
> has to be linked in to support the subclassing.
Since that damage has already been done in implementing the VCL, is
there really any harm in overriding WndProc or adding another message
handler?
Or were you thinking that Joseph should create his "unpastable" edit
control "manually" via CreateWindow and subclass that window? That would
be considerably more work, and the form that he puts that control on
wouldn't recognize it as a normal control anyway. The parent's font
wouldn't propagate, and the control wouldn't be in the tab order. It
wouldn't receive as many notifications from its parent as its
TControl-based siblings, either.
-- Rob
- Next message: Bruce Roberts: "Re: Preventing pasting in a TEdit"
- Previous message: Andrew Skinner: "Re: Delphi 6 personal - download"
- In reply to:(deleted message) not_at_any.adr: "Re: Preventing pasting in a TEdit"
- Next in thread: not_at_any.adr: "Re: Preventing pasting in a TEdit"
- Reply:(deleted message) not_at_any.adr: "Re: Preventing pasting in a TEdit"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|