enable buttons

how to enable greyed buttons. by hiew

Win32 API exposes the "EnableWindow" function in order to enable or disable windows.
Once you've localized the proper function, you can use hiew or any other hexeditor to alter the code

[LOUZEW]

Right Vox Humana, but maybe you have to find the associated code to link to this button in your App !
Enabling Buttons are easy, linking to the right code is an other thing !

Well, not so hard...you may proceed by trial and error, BPXing on the function and inspecting "bEnable"...not in HIEW, of course...in fact IMHO the question has little or no sense...

[xobor]

hmmm, buttons maybe disabled via calling enablewindow (you can patch rigth part of code) or via resources (you can find and correct res part of exe), but 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

regards

I have to admit to my ignorance: in which way, other than sending a WM_ENABLE message, can you change the enabled state of a control?
Regardless to location of the related code, how can an application control the state of a window?

May you, xobor, expound, please, some alternative methods, if any?

Why don't you just look up enablewindow (mentioned in this thread) in your api-reference, and you won't even have to admit to your ignorance... ;P

Tell us again if you need us to do that work for you...

/Manko

Manko, I've followed your enlightening advice, but I've got nowhere.

BTW the EnableWindow quotation was mine, so probably I can't figure out either what I'm reading.

It seems to me that my API reference indicates in EnableWindow the only way to *change* the state; maybe is there something different in yours? "CreateWindow" (mentioned in my API-reference in that context) can only *create* a disabled control, not change it; in fact, my question was: "in which way, other than using WM_ENABLE, could you *change* the state of a control?"

So, I probably have to admit my stupidity rather than my ignorance. Since you're so kind as to work for me, could you explain, please, what I should read in my (or in your) API-reference?

Thanks in advance for your consultancy

OK. It seems you wan't me to start a silly flamethread with you, but I think it will be better if I just state here and now that I am the stupid one.

I read your reply to xobor and misinterpreted the situation when I could just have looked further up and spared myself the embarassement.

Actually I am now VERY confused as to what you actually asked him. Can you please explain?

If you wanted MORE examples of how one could enable/disable I don't understand why you'd call that ignorance? No one has hinted at a third possibility, so where you beeing sarcastic just cause someone gave the same advice as you?
I guess I'm just stupid and need to go to bed....

Sorry if I offended you.

/Manko

No, Manko, no silly flamethread; I'll resume what's happened.
"code" posted a request, that sounded to me as a non-sense one. What does exactly mean "enable grayed buttons *by hiew*"?

When a control is created, and it's enabled, (otherwise you can always use a resource editor, and not hiew, anyway - you could, but this is desperately out of the code's reach, I guess), its state is usually settled by an EnableWindow call. I never found an application that behaved in a different way (not so about menuitems, anyway). So, if you put a breakpoint on that function, sooner or later you will land inside the proper code, no matter where it is placed (inside the main EXE, inside a DLL, inside any runtime created code, etc.). By varying in real time the "bEnable" parameter, you will often be able to discover which call handles your control. That's all, and this was synthesized in my replies, to code and to LOUZEW.

Maybe my knowledge is somehow inadequate, maybe not, but...why this attitude? Can you honestly say that the sarcastic part of the thread was initiated by me?

If you maintain that my knowledge is lacking, supplying with further elements is information, but criticizing with no information sounds insulting. Is this statement wrong, Manko?

Regards

This is my last comment. PM me if you have questions...

I explained that I made a misstake cause I was too lazy to read what had been said before, then, tired, and upset by your MEGA-sarcastic remarcs to my slightly teasing reply, I went and made more misstakes... For that I am sorry!

I can see now that you are a very nice person who only wants to help others and were just being humble when you said you were ignorant. You truly wanted to know if there were more ways to enable a controle and you humbly realised xobor as your superior asking him a simple question.

But, stil I can't help but wonder if this is the result of some earlier confusion regarding the possibility that the statement, that the code that gets called when you use a controle might not be "linked" or even present in the application, is not the same as that it will be hard to find the code that enables/disables the control.

Anyway I appologise to everyone for these last posts, for which I take full responsibility.

And again I appologise to you too, Vox Humana.

/Manko

[xobor]

take it easy my friends,

i didn't answer to VoxHumana because it question to me was really sarcastics and silly. English is not my mother language but as I read previous posts again and again I didn't find any sense in VH question

I wrote down:

buttons maybe disabled via calling enablewindow (you can patch rigth part of code) or via resources (you can find and correct res part of exe),

and VH later wrote:

Win32 API exposes the "EnableWindow" function in order to enable or disable windows

When a control is created, and it's enabled, (otherwise you can always use a resource editor, and not hiew, anyway - you could, but this is desperately out of the code's reach, I guess

(as I understand control can be disabled in resources)

and it seems to be the same things


and back to code's question :

how to enable greyed buttons. by hiew

he didn't ask how to change state, but how to enable buttons, so these buttons can be created disabled, so for what I pointed to possibility to change their state via resource editor

thanks Manko
VoxHumana excuse my terrible english

howgh

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

[xobor]

ok, ok you won (wow)

but....

I never wrote that code connected to control can switch state of control, look at it:

hmmm, buttons maybe disabled via calling enablewindow (you can patch rigth part of code) or via resources (you can find and correct res part of exe), but 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 what was significance of my post? point to alternative that control can be disabled by programmer in resource editor (if I remember right there was a version of rslogix which had disabled controls in resource editor) and that simply enabling control must not automatically lead to right functioning of control.

eg

a time ago I saw program in which developer done this (I guess)

1) disable menuitems and buttons for saving and printing
2) in message loop for IDSAVE and IDPRINT do only return

but code for saving and printing was still here ...

well it was not so hard to find code for saving and printing in IDA and make some jumps at right places, but situation was as I wrote control disabled by res editor (so spying on EnableWindow lead towards nothing) and code was disconnected from control so there was a need to do some RI works on it


this and ONLY this was sense of my post

regards