Preventing pasting in a TEdit

[Joseph McDonnell]

Hi, all.

I've got a very simple problem which I thought I knew the answer to but
it's now obvious to me that I don't. I have a very simple application
which has a number of TEdits. A user wanted to copy a oft recurring
string into a field using cut and paste (control-C and control-V) from
the clipboard. Unfortunately, she forgot her last post to the clipboard
was from a Word document and not the string. When she dumped the large
amount of text in the field, it messed up the formatting of the output.
We discussed this and decided the best thing to do was to disable
pasting within the application. I thought that by setting the Form's
keypreview to true and having this...

procedure TForm1.FormKeyDown(Sender: TObject; var Key: Word;
Shift: TShiftState);
begin
if (ssCtrl in Shift) then Key:=0 ;
end;

as event handler would prevent cutting and pasting (as well as anything
else using Ctrl). However, it doesn't. What am I missing? I seem to
recall doing similar things in other versions of Delphi - I'm now using
D7 on W98/XP.

Regards

Joseph

[Maarten Wiltink]

A user wanted to copy a oft recurring string into a field using
cut and paste (control-C and control-V) from the clipboard.
Unfortunately, she forgot her last post to the clipboard
was from a Word document and not the string. When she dumped the large
amount of text in the field, it messed up the formatting of the output.
We discussed this and decided the best thing to do was to disable
pasting within the application.

Don't mess with standard Windows behaviour. The best thing to do was
to educate your user, with the aid of a wooden implement applied to
the head if necessary. It appears you are in need of some education,
too.

There is something to be said for filtering end-of-lines from text to
be pasted into a single-line edit, or pasting only the first line, or
whatever. I'm not sure if Windows has standard behaviour for this
already; it should. But if you happen to paste the wrong text, you
*press Ctrl-Z*, put the right text on the clipboard, and try again.
This is how Windows works and how it should work. Frivolously changing
that for every case of operator error is counterproductive should you
ever need to support a user who actually knows how Windows works and
expects it to work like it does everywhere else.

I have one burning question left: don't your users _see_ what they're
doing?

Groetjes,
Maarten Wiltink

[n***@any.adr]

On Wed, 4 Aug 2004 11:57:17 +0200, "Maarten Wiltink"

Post by Maarten Wiltink
Don't mess with standard Windows behaviour.

Why not? Windows actually provides all the tools you need to modify the
behaviour of any of it's native controls... It's called subclassing or
superclassing (depending where you intercept message flow) and it's intended
to let you do exactly that.

-----
Laura

[Maarten Wiltink]

Post by n***@any.adr
On Wed, 4 Aug 2004 11:57:17 +0200, "Maarten Wiltink"

Post by Maarten Wiltink
Don't mess with standard Windows behaviour.

Why not?

Because people then have to learn about it before they can become
productive again. I do not have much illusions about the skill
level of the average user, but I'll be damned if I let the few who
are worth working for be amputated like this.

Post by n***@any.adr
Windows actually provides all the tools you need to modify the
behaviour of any of it's native controls... It's called subclassing
or superclassing (depending where you intercept message flow) and
it's intended to let you do exactly that.

That it's possible doesn't necessarily make it a good idea.

I'm not saying sub/superclassing doesn't have its place. But the
problem in this case was user stupidity (I mean "operator error"),
not wildly unreasonable behaviour enforced by Windows.

Groetjes,
Maarten Wiltink

[n***@any.adr]

On Wed, 4 Aug 2004 17:57:26 +0200, "Maarten Wiltink"

Post by Maarten Wiltink

Post by n***@any.adr

Post by Maarten Wiltink
Don't mess with standard Windows behaviour.

Why not?

Because people then have to learn about it before they can become
productive again. I do not have much illusions about the skill
level of the average user, but I'll be damned if I let the few who
are worth working for be amputated like this.

Almost every program for windows uses subclassing... right click on this
message in OE, Agent, whatever and you're going to see a much larger than
normal edit menu, giving lots and lots of extra activities in addition to the
normal cut/copy/paste offered by the control. THAT is done by subclassing the
edit control, whether transparently by VCL tools or overtly in WinApi
programming it's the same thing.

Not only is subclassing common practice, it's *expected*... produce an
application with no subclassing at all and people will be asking you what's
wrong with the menus within a couple of hours. Others will be crabbing that
Enter doesn't lock text into an edit window or activate a pulldown list
selection... and on and on... all these things are done by subclassing.

Post by Maarten Wiltink

Post by n***@any.adr
Windows actually provides all the tools you need to modify the
behaviour of any of it's native controls... It's called subclassing
or superclassing (depending where you intercept message flow) and
it's intended to let you do exactly that.

That it's possible doesn't necessarily make it a good idea.

But it's done, literally all the time.

I don't think I've ever written a single windows program (well, except
"HelloWorld") that hasn't subclassed at least one window.


-----
Laura

[Jeremy Collins]

Post by Joseph McDonnell
I've got a very simple problem which I thought I knew the answer to but
it's now obvious to me that I don't. I have a very simple application
which has a number of TEdits. A user wanted to copy a oft recurring
string into a field using cut and paste (control-C and control-V) from
the clipboard. Unfortunately, she forgot her last post to the clipboard
was from a Word document and not the string. When she dumped the large
amount of text in the field, it messed up the formatting of the output.
We discussed this and decided the best thing to do was to disable
pasting within the application.

Diabling cut & paste is a bit extreme - and it could annoy your
users. How about setting the MaxLength property of the TEdit?

Or how about writing your own clipboard code which checks the length
of the text before pasting?

[Duncan McNiven]

On Wed, 04 Aug 2004 10:27:05 +0200, Joseph McDonnell

Post by Joseph McDonnell
I've got a very simple problem which I thought I knew the answer to but
it's now obvious to me that I don't. I have a very simple application
which has a number of TEdits. A user wanted to copy a oft recurring
string into a field using cut and paste (control-C and control-V) from
the clipboard. Unfortunately, she forgot her last post to the clipboard
was from a Word document and not the string. When she dumped the large
amount of text in the field, it messed up the formatting of the output.
We discussed this and decided the best thing to do was to disable
pasting within the application.

Oh dear. User once has a problem using a very useful feature and you
decide the best way to prevent repetition of the problem is to disable
the useful feature. Your users must have very different expectations to
mine. My users would say that they find it useful to be able to insert
standard entries into this field so they would like to have this
automated. We would then look at converting the edit to a combo, or
having standard phrases inserted via a button or menu, or converting
from free text to, say a logical field using a checkbox, or having a
macro facility, or .... Still, each to his own.

If you are determined to remove the possibility of pasting, I suggest
you create your own TEdit-based component to handle the WM_PASTE message
and do nothing with it. That way your changes will only impact the
specific controls you change, and will not stop other key combinations
using Control. Think carefully before doing this though.

[J French]

On Wed, 04 Aug 2004 10:27:05 +0200, Joseph McDonnell

Post by Joseph McDonnell
Hi, all.
I've got a very simple problem which I thought I knew the answer to but
it's now obvious to me that I don't. I have a very simple application
which has a number of TEdits. A user wanted to copy a oft recurring
string into a field using cut and paste (control-C and control-V) from
the clipboard. Unfortunately, she forgot her last post to the clipboard
was from a Word document and not the string. When she dumped the large
amount of text in the field, it messed up the formatting of the output.
We discussed this and decided the best thing to do was to disable
pasting within the application. I thought that by setting the Form's
keypreview to true and having this...

Just a little work in the TEdit's OnChange event would prevent real
horrors

[n***@any.adr]

Post by Joseph McDonnell
as event handler would prevent cutting and pasting (as well as anything
else using Ctrl). However, it doesn't. What am I missing? I seem to
recall doing similar things in other versions of Delphi - I'm now using
D7 on W98/XP.

Cut Copy and paste operations are native to the underlying windows EDIT
control, the parent window or application doesn't even see them.

The most straightforward way to disable the paste operation would be to
subclass the EDIT control, blocking the right click menu and ctrl-v
operations.

With a little added code you could unblock the paste operation when an
*internal* copy or cut operation has occurred in your application --set a
flag when copy or cut is performed, clear it after pasting-- thus blocking
pastes from outside the application.

As a nice aside, this would also let you create a customized right click menu
with application specific functions listed out for your users.

Subclassing isn't all that hard to do (it's explained in the SDK) but you
gotta work with the windows edit control right at the winapi level, TEdit's
are one step removed.

I would make a small separate unit with my subclassed/customized edit control
in it, that way the whole thing's reusable.


-----
Laura

[Rob Kennedy]

Post by n***@any.adr
With a little added code you could unblock the paste operation when
an *internal* copy or cut operation has occurred in your application
--set a flag when copy or cut is performed, clear it after pasting--
thus blocking pastes from outside the application.

It would also block multiple pastes of the same text from inside the
application. Instead, you'd need to monitor the clipboard for copy
operations, noticing who the clipboard owner is at the time. It could
also be done by putting data on the clipboard in a custom format (even
if it's meaningless data) and only pasting data from the regular format
if the custom format is also available -- the presence of custom data
acts as the flag you described, and Windows would clear it automatically
when appropriate.

Post by n***@any.adr
As a nice aside, this would also let you create a customized right
click menu with application specific functions listed out for your
users.

Simply assigning the PopupMenu property will do that. No need for
subclassing.

Post by n***@any.adr
Subclassing isn't all that hard to do (it's explained in the SDK) but
you gotta work with the windows edit control right at the winapi
level, TEdit's are one step removed.

Why would you have to work at the API level? Couldn't you just override
the WndProc method or add custom message-handling methods?

[n***@any.adr]

Post by Rob Kennedy
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. 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.

Subclassing is a fairly common and easily enacted way of modifying the
behaviour of windows classes (not just controls)... 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. You have the choice of
calling the default winproc before, after or at some mid-point in your custom
code which lets you really and thoroughly change the behaviour of a window
class (again, any class, not just a control).

In pseudocode...

// subclass winproc
Procedure MyProc (...)
begin
case message of
...
else
callwindowproc(oldproc,...);
end;
end;

begin
// make window
hwind := Createwindow('edit' .... );
// subclass window
Oldproc := setwindowlong(hwind,swl_windproc,@myproc);
end;

Now what happens is that instead of the messages for the Edit control going
directly to the edit control itself, they run through your custom procedure
first... you can intercept, change, delete or ignore messages... then it
passes control to the old window process letting things happen there as
normal.

Any time you right click a control in windows and get a different than default
menu that window has been subclassed to provide it's own menus. But
subclassing can do *anything* including inserting bitmaps into text controls,
changing the mouse or keyboard behaviour for a control even changing the
appearance of the control itself. Skinning is a common subclassing activity,
intercepting WM_NCPaint to draw custom borders...

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. A normal windows control
occupies only about 32 bytes of application space (enough to call it from the
DLL) but when you subclass as heavily as Borland does you end up linking in 10
or 20 kb for each control.

MSDN Main topic here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/userex/subclassingcontrols.asp

MSDN Search List here:
http://search.microsoft.com/search/results.aspx?qu=subclassing&View=msdn&st=b&c=0&s=1&swc=0


-----
Laura

[Duncan McNiven]

Post by n***@any.adr

Post by Rob Kennedy
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. 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.

You are mistaken there. Take your C/C++ hat off for a moment and look at
things the Delphi way <g>

You can add a method to handle the WM_PASTE message (yes, it _does_ go
to the TEdit) and prevent pasting that way. Very easy to do, using very
obvious, isolated/self-contained code that is easy to maintain, and
avoids having to go anywhere near the windows procedure for the control.

Post by n***@any.adr
Subclassing is a fairly common and easily enacted way of modifying the
behaviour of windows classes (not just controls)...

In C/C++ this is true. In Delphi, it is rare. How rare? Well I have been
using Delphi since it was launched, and I have never done it that way.
There has always been a better way using the Delphi approach.

[n***@any.adr]

Post by Duncan McNiven
You are mistaken there. Take your C/C++ hat off for a moment and look at
things the Delphi way <g>

I wouldn't know how to write the first line of code in C++ ... so lets not go
there, ok?

Post by Duncan McNiven
You can add a method to handle the WM_PASTE message (yes, it _does_ go
to the TEdit) and prevent pasting that way.

In the underying code that amounts to the same thing I was suggesting.

Post by Duncan McNiven
Very easy to do, using very
obvious, isolated/self-contained code that is easy to maintain, and
avoids having to go anywhere near the windows procedure for the control.

Well, actually not true... the TEdit control subclasses the underlying windows
Edit control for you.

Post by Duncan McNiven
There has always been a better way using the Delphi approach.

And, for many things, there has always been a better way THAN using the Delphi
approach [grin]. No one approach or language is ever adequate to all tasks.

-----
Laura

[Duncan McNiven]

Post by n***@any.adr

Post by Duncan McNiven
You are mistaken there. Take your C/C++ hat off for a moment and look at
things the Delphi way <g>

I wouldn't know how to write the first line of code in C++ ... so lets not go
there, ok?

Yet you are writing your code with mindset, ignoring the benefits of the
RAD tool you are using. For the vast majority of tasks that is simply
inefficient and not necessary. Fast forward a decade or so and come up
to the present.

Post by n***@any.adr

Post by Duncan McNiven
You can add a method to handle the WM_PASTE message (yes, it _does_ go
to the TEdit) and prevent pasting that way.

In the underying code that amounts to the same thing I was suggesting.

The effect is certainly the same, but it is achieved in quite a
different way. Anyone maintaining apps written with your approach would
find it harder to locate the code in question, would require a greater
knowledge of Windows, and risk introducing bugs into other
functionality. Your approach is expensive up front and asking for
problems and costs down the line.

Post by n***@any.adr

Post by Duncan McNiven
Very easy to do, using very
obvious, isolated/self-contained code that is easy to maintain, and
avoids having to go anywhere near the windows procedure for the control.

Well, actually not true... the TEdit control subclasses the underlying windows
Edit control for you.

Exactly; you don't have to bother with all that crap yourself. You just
add a procedure to handle that one message. Very easy, very clear,
maintainable by any junior programmer who picks up your code without
risk to the mountain of code that would inevitably get put into WndProc
if you do anything major via the sub-classing route.

Post by n***@any.adr

Post by Duncan McNiven
There has always been a better way using the Delphi approach.

And, for many things, there has always been a better way THAN using the Delphi
approach [grin]. No one approach or language is ever adequate to all tasks.

No tool is best for everything, obviously, but ignoring the benefits of
the tools you use is, shall we say, perverse. Then to say that the
normal Delphi approach used by just about every other Delphi programmer
on the planet is not possible ... oh I get it, this is a troll. OK, you
got me.

[Rob Kennedy]

Post by n***@any.adr

Post by Rob Kennedy
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.)

Post by n***@any.adr
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).

Post by n***@any.adr
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.

Post by n***@any.adr
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.

Post by n***@any.adr
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.

[n***@any.adr]

Post by Rob Kennedy
Have you ever looked in the Controls.pas unit?

Yep.

Post by Rob Kennedy
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.

Yep... that's Borland subclassing the windows edit control. Adding a couple
of hundred kb of code to something I can do in less than a k...

Post by Rob Kennedy

Post by n***@any.adr
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.

Actually... it is. You described it very nicely just above.

Post by Rob Kennedy
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.

Exactly... no matter what they plop on top of it, it's still subclassing the
control.


-----
Laura

[Rob Kennedy]

Post by Rob Kennedy
Have you ever looked in the Controls.pas unit?

Yep.

Sure fooled me. Claiming it's not possible to override WndProc, and all.

Yep... that's Borland subclassing the windows edit control. Adding a couple
of hundred kb of code to something I can do in less than a k...

What part of the code are you objecting to? Just how much of the VCL's
functionality do you claim to be able to provide in 1024 bytes of code?
And how easy will it be for others to take advantage of your work when
writing descendants of your classes?

Post by Rob Kennedy

Post by n***@any.adr
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.

Actually... it is. You described it very nicely just above.

Subclassing is not a common way of modifying a window's behavior, by
non-Borland developers, in Delphi. Subclassing is done in Delphi, but
not commonly, and I don't consider it easy, when compared to the
object-oriented alternatives.

When you write controls, do you call SetWindowLong or override
CreateParams to provide your own window procedure? I have never seen
that in any other control (except of course for TWinControl).

Post by Rob Kennedy
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.

Exactly... no matter what they plop on top of it, it's still subclassing the
control.

And since Borland has already done it, why do it again? With the VCL
already in place, the need for us to subclass controls is very, very rare.

Writing descendant controls is done all the time, but that does not
require the developer to know anything about Windows subclassing. The
subclassing takes place in the ancestor control, behind the scenes.

[n***@any.adr]

Post by Rob Kennedy

Post by Rob Kennedy
Have you ever looked in the Controls.pas unit?

Yep.

Sure fooled me. Claiming it's not possible to override WndProc, and all.

I never said it wasn't possible, Rob. What I said was the Delphi is
subclassing the controls very heavily already.

Post by Rob Kennedy

Yep... that's Borland subclassing the windows edit control. Adding a couple
of hundred kb of code to something I can do in less than a k...

What part of the code are you objecting to?

None of it... I think we're debating at crossed purposes here. I'm not
dumping on Delphi... I'm talking about how it actually works.

Post by Rob Kennedy
Just how much of the VCL's
functionality do you claim to be able to provide in 1024 bytes of code?

Hmmmm... huge chunks of the VCL's functionality is dormant in most
applications... i.e. you could do the same job with big chunks of code
removed. As it is set up the entire class and all it's ancestors have to be
linked into each and every program for any control to work. (typically 40 to
100k)

At the api level you only include the needed functionality and thus need a few
hundred bytes to subclass the control and a few bytes to call the control in
it's DLL (if memory serves this is less than 40 bytes).

Just about any program you can write in a meg by RAD/VCL/OOP methods, I can do
in under 100k by procedural methods. That's a huge pile of code linked in
with no real increase in functionality at all.

Post by Rob Kennedy
And how easy will it be for others to take advantage of your work when
writing descendants of your classes?

I don't write classes. I write traditional pascal units... using them is as
easy as adding them to your Uses list and calling the functions in the
interface sections.

As I explained before I'm something of an anachronism in the programming world
as I still program 99% by procedural methods.

Post by Rob Kennedy
When you write controls, do you call SetWindowLong or override
CreateParams to provide your own window procedure? I have never seen
that in any other control (except of course for TWinControl).

Generally I use setwindowlong.

Do you remember the "HelloWorld" example I posted? That's how I work, right
down and dirty with winapi calls. I don't even load the VCL, objects or
Classes units most of the time. (Why do you think I wanted the SEH to work
without exception objects?)

Post by Rob Kennedy
Writing descendant controls is done all the time, but that does not
require the developer to know anything about Windows subclassing. The
subclassing takes place in the ancestor control, behind the scenes.

My point exactly... It's programming without really knowing what code you are
generating. I view this as "less than optimal" because I definitely like
knowing exactly what's going on in my code.

-----
Laura

[Bruce Roberts]

Post by n***@any.adr
The most straightforward way to disable the paste operation would be to
subclass the EDIT control, blocking the right click menu and ctrl-v
operations.

I think it would be easier to override the wm_Paste message for the
subclassed edit control. Something like:

tNoPasteEdit = class (tEdit)
protected
procedure wmPaste (var Msg : tMessage); message wm_Paste;
end;

procedure tNoPasteEdit.wmPaste (var Msg : tMessage);
begin
Msg.result := 0;
end;

Or perhaps have wmPaste look at the clipboard and decide if it wanted to
paste the contents or not, or even filter the pasted contents.

[Michal Borsuk]

Post by Joseph McDonnell
Hi, all.
I've got a very simple problem which I thought I knew the answer to but
it's now obvious to me that I don't. I have a very simple application
which has a number of TEdits. A user wanted to copy a oft recurring
string into a field using cut and paste (control-C and control-V) from
the clipboard.

I had a similar problem - masked edit helped. Or maybe try OnKeyPress/Down?

Post by Joseph McDonnell
Regards
Joseph