[Help] Button Menu

Hey guys.

Ive run into some trouble with my button menu.
It works and all, But when I click the button to activate the hack, It turn on, Then turns straight off again.

Here is the AddButton && RenderButton function:

Code:

void AddButton(int bnum, char *bcaption, int bx, int by, int bw, int bh )
{
     Button[bnum].num       = bnum;
     Button[bnum].caption   = bcaption;
     Button[bnum].x         = bx;
     Button[bnum].y         = by;
     Button[bnum].w         = bw;
     Button[bnum].h         = bh;
     Button[bnum].clicked   = false;
}

void RenderButton(int butnum)
{
     int mw = Button[butnum].x + Button[butnum].w;
     int mh = Button[butnum].y + Button[butnum].h;

	 //Defualt apperance
	 DrawBox(Button[butnum].x, Button[butnum].y,  Button[butnum].w,  Button[butnum].h, Black, Red,g_pDevice);
	 PrintText(pFont, Button[butnum].x + 15, Button[butnum].y + 3, White, Button[butnum].caption);

	 POINT cur;
     GetCursorPos( &cur );

	 //if the mouse coords are the same as the buttons coords
      if ( cur.x > Button[butnum].x &&  cur.x < mw && cur.y > Button[butnum].y && cur.y < mh )
	  {
		   DrawBox(Button[butnum].x, Button[butnum].y,  Button[butnum].w,  Button[butnum].h, Black, Blue, g_pDevice);
		   PrintText(pFont, Button[butnum].x + 15, Button[butnum].y + 3, White, Button[butnum].caption);

		  //if mouse button is clicked
		   if ( GetAsyncKeyState( VK_LBUTTON )&1) 
		   {
				Button[butnum].clicked = !Button[butnum].clicked;
			}
	  }

	  if ( Button[butnum].clicked )
	  {
		  DrawBox(Button[butnum].x, Button[butnum].y,  Button[butnum].w,  Button[butnum].h, Black, Green, g_pDevice);
		  PrintText(pFont, Button[butnum].x + 15, Button[butnum].y + 3, White, Button[butnum].caption);
	  }
}

And the usage of the button:

Code:

if ( Button[1].clicked ) 
		//HackOn
else
               //HackOff

Im really stuck here. And dont know whats wrong.
Help me please!!

Thanks,
acid

You need to test what is causing the hack to turn off. Whether it's the button turning back off, or it's the hack itself. Put in a messagebox or something for when it's turned on and off so you can tell whether the button is turning off, or the hack is. That way you can pinpoint what you need to change.
~lilneo

If GetAsyncKeyState in this case (with the mouse button) is the same with keys. You have to put a wait time after it's clicked/pressed.

Originally Posted by Void

If GetAsyncKeyState in this case (with the mouse button) is the same with keys. You have to put a wait time after it's clicked/pressed.

You only need a wait time if you use < 1. &1 checks if the key has been pressed since the last time you called GetAsyncKeyState, so it will only activate once (or at least until the repeat delay is up).

I tried to help acid but I couldnt get his DLL to run in a debugged test environment so I could see whats wrong. I saw nothing that would cause this strange behavior.

Originally Posted by mmbob

You only need a wait time if you use < 1. &1 checks if the key has been pressed since the last time you called GetAsyncKeyState, so it will only activate once (or at least until the repeat delay is up).

I tried to help acid but I couldnt get his DLL to run in a debugged test environment so I could see whats wrong. I saw nothing that would cause this strange behavior.

&1 will show up as true only if the button was pressed before, and false otherwise. Therefore if u only pressed the key once it would come up as false. but if u hold down the key the LSB will continue to be turned on hence it will be set as true. So David should be right as to the cause of the problem, though everything doesnt work out as u plan it, and in part due to the nature of the bitwise operator I would not use it as a boolean operator. I couldn't imagine the problems from using a bitwise & on a double which takes up two registers or even which C++ compilers would allow it.

Originally Posted by why06

&1 will show up as true only if the button was pressed before, and false otherwise. Therefore if u only pressed the key once it would come up as false. but if u hold down the key the LSB will continue to be turned on hence it will be set as true. So David should be right as to the cause of the problem, though everything doesnt work out as u plan it, and in part due to the nature of the bitwise operator I would not use it as a boolean operator. I couldn't imagine the problems from using a bitwise & on a double which takes up two registers or even which C++ compilers would allow it.

No, you are wrong. The LSB is set if the key has been pressed since the last time it was called. It does NOT return whether the key is down or not. For keys on the keyboard, the LSB is set to one every time the key repeat delay is up. The mouse, however has no repeat delay and is "pressed" only once.

Originally Posted by mmbob

No, you are wrong.

You are wrong about me being wrong.

The LSB is set if the key has been pressed since the last time it was called.

this is correct. However the GetAsynkeystate can only tell if that key has been pressed by checking the current state of the key. at the instant it is called. so for instance if u were to press a key and have a 1000 ms delay in which u pressed the key, but were not pressing at the instant GetAsynckeystate was called again. This press would not be detected.

It does NOT return whether the key is down or not.

inconsequentially it does since the key must be down in order for the LSB to be set. It just also tells us that the key was pressed on the previous call, which lets us know that the key has been held down. Which may be incorrect. The key could also be being pressed at a frequency higher then then our detection rate, but for most cases this is inconsequential since humans can only move their fingers so fast.

For keys on the keyboard, the LSB is set to one every time the key repeat delay is up. The mouse, however has no repeat delay and is "pressed" only once.

No such thing as a key repeat delay. Just because most word processors limit their frequency of detection to human levels, does not mean a delay is included in the function through some kind of static time variable. Test it and u will see.

Smiley faces should come up for however long u click ur mouse.

Code:

#include <iostream>
#include <windows.h>
using namespace std;

    
int main()
{

    
    
  
    
    while(1){
             for(int ch = 0; ch < 256; ch++)
             {
              if(GetAsyncKeyState(ch))cout<<(char)ch<<endl;
             }
             Sleep(200);
    }
    return 0;
}

NOTE: I don't post anything without checking my facts. Even though I have written on this subject before I reviewed the Windows API, created a sample program, and tested several possible scenarios, because when it comes to programming theory is not enough. Compilation environment, and target platform can cause discrepancies, but I am still fairly confident what Ive said is accurate.

As to ur point:
If you still wish to test a Getsynckeystate function using bitwise operators that the key has not been held for more then one iteration you can do so, by using the ^ or XOR bitwise operator which will be false in ever situation besides in which one bit is off and the other on. and since our ^1 will always be set, the getasynckeystate should only return true when it is the first pass. However this still has the problem that u will have to isolate the first bit of the return value and then the key detection frequency will only be halved as the program will only detect ur key after skipping one iteration.

It is for these reasons that I recommend not using bitwise operators as replacements for boolean operators as well as strongly suggesting to only use the LSB in the return value of GASKS() to test if a key is currently being held, and NOT if it has been held, which is a bit more difficult, and do to the very nature of the API, hell the very nature of Windows and multitasking, or even the physical limitations of the machine... (though I wouldn't dare wonder why anyone would need to press a key that fast) a inherent margin for error. You simply have carried with you the illusion that many novices start off with. That a computer moves so fast that it must be constant, but this is not true. In the tightest weave there are gaps, and so is there here. And when working with programs know that these are consisted of the elements of the computer and are so small as to fall through the gaps humans can not see.

EDIT: Seems like ive missed something. Upon further testing ur concept seems to work with mouse buttons. Only the mouse buttons strange, but very interesting I give u that. Rather this is due to the hardware device or the function I can quite say.

Originally Posted by why06

this is correct. However the GetAsynkeystate can only tell if that key has been pressed by checking the current state of the key. at the instant it is called. so for instance if u were to press a key and have a 1000 ms delay in which u pressed the key, but were not pressing at the instant GetAsynckeystate was called again. This press would not be detected.

I dont see how this is relevant.

Originally Posted by why06

inconsequentially it does since the key must be down in order for the LSB to be set. It just also tells us that the key was pressed on the previous call, which lets us know that the key has been held down. Which may be incorrect. The key could also be being pressed at a frequency higher then then our detection rate, but for most cases this is inconsequential since humans can only move their fingers so fast.

By it "does not check" I was meaning that the LSB does not return this state.

Originally Posted by why06

No such thing as a key repeat delay. Just because most word processors limit their frequency of detection to human levels, does not mean a delay is included in the function through some kind of static time variable. Test it and u will see.

The key repeat is implemented at the hardware level. You should get your facts straight.

Originally Posted by why06

Smiley faces should come up for however long u click ur mouse.

Code:

#include <iostream>
#include <windows.h>
using namespace std;

int main()
{
    while(1){
             for(int ch = 0; ch < 256; ch++)
             {
              if(GetAsyncKeyState(ch))cout<<(char)ch<<endl;
             }
             Sleep(200);
    }
    return 0;
}

Yes, they should. We were talking about using &1 so I dont see why you didnt include it in your program.

Originally Posted by why06

NOTE: I don't post anything without checking my facts. Even though I have written on this subject before I reviewed the Windows API, created a sample program, and tested several possible scenarios, because when it comes to programming theory is not enough. Compilation environment, and target platform can cause discrepancies, but I am still fairly confident what Ive said is accurate.

I, too, review the msdn page for functions that I use. I have used &1 in my own hack and I know 100% how it works.

Originally Posted by why06

As to ur point:
If you still wish to test a Getsynckeystate function using bitwise operators that the key has not been held for more then one iteration you can do so, by using the ^ or XOR bitwise operator which will be false in ever situation besides in which one bit is off and the other on. and since our ^1 will always be set, the getasynckeystate should only return true when it is the first pass. However this still has the problem that u will have to isolate the first bit of the return value and then the key detection frequency will only be halved as the program will only detect ur key after skipping one iteration.

I dont see what your problem with using bitwise AND. You use to so you can isolate only 1 bit to check (in this case the LSB).

Originally Posted by why06

It is for these reasons that I recommend not using bitwise operators as replacements for boolean operators as well as strongly suggesting to only use the LSB in the return value of GASKS() to test if a key is currently being held, and NOT if it has been held, which is a bit more difficult, and do to the very nature of the API, hell the very nature of Windows and multitasking, or even the physical limitations of the machine... (though I wouldn't dare wonder why anyone would need to press a key that fast) a inherent margin for error. You simply have carried with you the illusion that many novices start off with. That a computer moves so fast that it must be constant, but this is not true. In the tightest weave there are gaps, and so is there here. And when working with programs know that these are consisted of the elements of the computer and are so small as to fall through the gaps humans can not see.

I am not a "novice" so dont speak to me as one.

It is possible that the (.exe) or anticheat is turning the hacks off. Without the message box or the .dll to test on a fake (.exe) then we dont know base on his source code.

Originally Posted by faceofdevil

It is possible that the (.exe) or anticheat is turning the hacks off. Without the message box or the .dll to test on a fake (.exe) then we dont know base on his source code.

L.A.W.L.

Yah 'right, The AC Knows how your Hack's Functions works, And change their State to appear as Off. And Makes a Sad Face.

Bad Coder is Bad.

Originally Posted by Melodia
L.A.W.L.

Yah 'right, The AC Knows how your Hack's Functions works, And change their State to appear as Off. And Makes a Sad Face.

Bad Coder is Bad.

Well I should of probly reworded that. Sometimes when people active hacks the AC will rewrite the orignal values back. I was on the assumption of that. I've had this issue one time with button menu's and why06 pretty much explained whats wrong.

thread = hijacked.

its like a sophisticated flame war!

Ur thing checks out. I concede, but I did not understand that this only worked for the mouse keys. So in this u are correct. but for every other key I am correct as well. In any case point has been noted. I learned something out of this. Thanks for the debate.

Hijacked Much?
Can anyone halp me please D:

Originally Posted by ac1d_buRn

Hijacked Much?
Can anyone halp me please D:

This is nothing compared to the hijack we had a couple months ago, it started at page 2 and we ended up with 16 pages of awesome discussion about industry standards, the future and that kinda stuff

[Help] Button Menu

Post a Reply

Similar Threads

Tags for this Thread