OK guys, it seems to me that, when all is said and done, we've reached the heart of matter.

"code" asked a question: how to enable greyed buttons: beside, he/she laid down a condition: by hiew. Although the condition sounded senseless to me at first, I considered the question, starting from fairly reasonable assumptions:

1) code wanted to enable some disabled functions in an app
2) A fully functional version of that app really exists


I said "fairly reasonable assumptions" because if they proved false, this shoud mean someone enjoys writing application with disabled buttons that do nothing, and code would enable them
only to tease him; so, let's assume that we're talking about a demo.

beside

3) The code intention was tampering with the code (I apologize for the pun); so, the condition "by hiew" had to be interpreted in broad sense, as "by a disassembler/hexeditor" (and not "by any resource editor/hook installer").

This said, let's consider the different possibilities we could meet with:

1) The demo and the full version are totally different programs (highly improbable)
2) The demo is the full version compiled with some conditional directive (fairly improbable - the programming magazines are crammed with articles about the use of conditional directives to compile demos, sign it's uncommon practice)
3) The demo is the full version compiled with conditional statements in code (fairly probable)
4) the demo is the full version that needs to be activated (unlikely, because the code question would be different,I guess)

In case 3), the program will call EnableWindow in order to disable the controls; in case 2), the program might not call EnableWindow, but only if the directives ADD the code for the full version, and this is unlikely too. Actually I've seldom met with app that didn't use EnableWindow. For these reasons, I replied (EARLIER, xobor, not later) "Win32 API exposes the "EnableWindow" function in order to enable or disable windows".

Anyway, even if should the program create disabled controls, a breakpoint on CreateWindow(Ex) would lead towards the involved code; and this is the sense of my reply to LOUZEW, i.e. it isn't so hard (usually at least) detecting the code we're concerned.

So far, the discussion is pretty straightforward, I guess.

LATER, Xobor said:

"it is possible that code for button is not connected to button (maybe it is not in exe at all ) and here can be problem pointed by LOUZEW"

and this started the "polemical" part of the thread. And my question is still unanswered: how can a piece of code "not connected to button" control the state of the button? Or, in other words, what does exactly mean your statement, Xobor?

I've got the impression of a low information content about it, Xobor, and so I asked my "really sarcastics and silly" question; and, yes, it was "really sarcastics and silly" because, as stated in my reply to Manko, "supplying with further elements is information, but criticizing with no information sounds insulting".

Am I wrong, Xobor? If I'm wrong, I certainly apologize, and you'll be so kind as to explain to me how the code "not connected to button" can control the button. But if not, please, be aware of my posts' meaning: they were intended as an incitement, a starting point for an in-depth analysis (because, I say it again, the code's question has little sense IMHO) about the way Win32 manages controls. But what was the significance of your post, Xobor? How can it help code?

And don't worry about your English; mine is even worse

Regards