The confusing thing is your terminology. Your control is an textfield, and textfields don't do anything in response to single clicks, so setting an empty onClick handler isn't going to change it's behaviour.

If you said "I want to stop the user from being able to edit the text displayed in the Textfield", then it would be fairly obvious that you don't want to 'disable the control', you want to 'set the TextField readonly', which is a fairly common thing to want to do to edit fields and there is therefore an option for doing exactly that (called -readonly :). Try this

use strict;
use Win32::GUI;
use Win32::API;
our $mainform = Win32::GUI::Window->new(
    -name=>'main',
    -text=>'main',
) or die "window creation failed: $!\n";

our $test = $mainform->AddTextfield(
    -name=>'test',
    -text=>'test',
    -left=>200,-top=>200,
    -width=>100,-height=>20,
    -readonly => 1,
) or die "control creation failed: $!\n";

$mainform->Show();

Win32::GUI::Dialog;
[download]

I really did mean that I wanted to disable it. It's not just for a textfield but for any control. I wanted to turn off all responses for any given control (clicks, cursor changes, etc.) just like it was disabled. I just didn't want it to look like it was disabled. My guess was that the method Win32::GUI uses to disable a control calls multiple functions in the underlying api to achieve the final result. I was just looking for a way to do this without the steps that change the appearance of the control. I just don't know how this is done. I have looked win32.pm and gui.pm but just can't seem to figure it out.

Update:
Setting the -readonly property changes the appearance of the control by making the background gray. The idea is to keep it looking the same but non-functional.

The greying of disabled controls is performed by the OS itself. You say it's disabled and the OS uses the appropriate colors as defined in the system palette to display them. These colors are system wide and whilst you can change them, you would affect all other apps on the desktop which isn't very freindly.

The second alternative is to create your own application palette that has the same colors for disabled controls as for enabled, and then realize that palette when required. This is a lot of work, and Win32::Gui doesn't support these functions, so you would have to use Win32::API to get at them.

A third alternative would be to place a transparent window that does nothing over the top of the control that you wish to disable. This transparent window would serve to prevent the user from clicking on the control, by intercepting the clicks and discarding them. Teh fly in that ointment is that you would also have to arrange for focus changes caused by keyboard input (tabbing) to be intercepted. Again, quite a lot of work involved, though I think Win32::Gui gives you most of what you need to do this.

A fourth possibility would be to intercept the WM_DISABLE message for the control, do a grab of the bits of the window, pass the disable message through to the system so that all it's associated functions happen. You would also intercept the WM_PAINT message and blit the bits you grabbed earlier back onto the screen when the control redraws. This is fairly simple to do, though again, I think you would probably need to use Win32::API to get at some of the functions required. It may also cause some flashing of the disabled controls when they are redrawn unless you do it correctly.

There may be another simpler method, but I am not aware of it.

All in all, doing any of these is non-trivial, and of course prompts the question, why? Why would you want to have a disabled control masquerade as enabled?

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.