LuaRef Call crash in WNDPROC CALLBACK - c++

Hi guys.
I have some overlay with lua support.
I need to create some WndProc callbacks, so I hooked WndProc of target window using SetWindowLong and saving old one
LRESULT CALLBACK nProc(HWND hWnd, UINT _Msg, WPARAM wP, LPARAM lP) // its new wndProc
{
switch (_Msg)
{
case WM_CUT: case WM_COPY: case WM_PASTE: case WM_CLEAR:
return 1;
case WM_DESTROY: case WM_NCDESTROY:
UnhookWndP(); // switching back to original wndProc
return 1;
case WM_KEYDOWN: case WM_KEYUP: case WM_LBUTTONDBLCLK: case WM_LBUTTONDOWN: case WM_LBUTTONUP: case WM_RBUTTONDBLCLK: case WM_RBUTTONDOWN: case WM_RBUTTONUP: case WM_MOUSEWHEEL:
try
{
if (_Msg == WM_KEYUP && wP == 120) // restart LuaState
{
if (LuaInit)
DelLua();
else
CreLua();
}
for (luabridge::LuaRef f : wndCall) // call all our WndProc Lua callbacks
{
if (Msg != NULL && wP != NULL && f.isFunction() && f.isFunction() && lua_gettop(L) == 0)
{
f((int)_Msg, wP); // always in callstack when error occurs
}
}
}
catch (luabridge::LuaException ex) { Msg(ex.what()); }
default:
return CallWindowProc(OriWndP, hWnd, _Msg, wP, lP);
}
}
Created global function for adding callback, which is saving func to wndCall Vector(LuaRef)
Lua part is working fine. It shows messages of WM_KEY... events successfully.
The only problem is: When i hold some button or spamming commands I got Crash with Random error :(
I think its because CALLBACK got hit multiple times at one tick and something got broken in LuaState or idk.
Please help me find a solution or some extra checks for WndProc func.

Related

Button to join thread causes win32/winAPI application to freeze

The title pretty much summarizes what my problem is. I have this function shown below and when I press the button to join the thread the application stops responding. I'm fairly new to multithreading in c++ and I don't really know what I am doing or why this is occurring.
HWND hwnd;
//this stops the declaration of the thread from saying that hwnd doesn't exist
bool stopRaidAction;
void JoinLoop(HWND hwnd)
{
for (std::string tokenString; std::getline(std::cin,tFileContents,'\n');) {
if(stopRaidAction==false)
{
if(tokenString.length()==0){break;}
if(tokenString.length()!=0){
//send post request to join the server using token through proxy
}
}
if(stopRaidAction){break;}
}
}
std::thread joinThread(JoinLoop, hwnd);
The issue is with the "JOIN_RAID" thing
LRESULT CALLBACK WindowProcessMessages(HWND hwnd, UINT msg, WPARAM param, LPARAM lparam) {
switch (msg) {
case WM_CREATE:
Controls(hwnd);
break;
case WM_DESTROY:
PostQuitMessage(0);
return 0;
case WM_COMMAND:
{
if ((HIWORD(param) == BN_CLICKED) && (lparam != 0))
{
switch (LOWORD(param))
{
case JOIN_RAID:
stopRaidAction=false;
MessageBeep(MB_OK);
joinThread.join();
break;
case STOP_RAID:
stopRaidAction=true;
MessageBeep(MB_OK);
break;
}
}
break;
}
default:
return DefWindowProc(hwnd, msg, param, lparam);
}
return 0;
}
joinThread.join() blocks the calling thread until JoinLoop() exits. If you do that call in your main UI thread, you will be blocking your message loop from being able to process new messages. That is why your UI freezes.
JoinLoop() is waiting on 2 conditions - user input being entered, and stopRaidAction being true while processing that input. Even if the user enters input, your main thread is setting stopRaidAction to false before calling join(), so unless JoinLoop() itself, or a 3rd thread, sets stopRaidAction to true then JoinLoop() won't exit, and so join() won't unblock.
Even if stopRaidAction were able to be set to true while join() is waiting, JoinLoop() still won't exit until the next time that user input is entered, so it can see the new stopRaidAction value. There is no way to unlocking a pending std::getline() call. So you should rewrite the way you are handling console input so you can stop waiting for input in a timely manner. See Win32 - read from stdin with timeout, for instance.
std::thread::join() is not something you should be calling until you are ready to terminate the worker thread. Which this code is not doing.
Given the code shown, it may make more sense to not create the thread at all until JOIN_RAID is clicked, and then terminate the thread when `STOP_RAID' is clicked, eg:
bool stopRaidAction = false;
std::thread joinThread;
void JoinLoop(HWND hwnd)
{
std::string tokenString;
while (!stopRaidAction) {
// read input with timeout...
if(tokenString.empty()){ break; }
//send post request to join the server using token through proxy
}
}
LRESULT CALLBACK WindowProcessMessages(HWND hwnd, UINT msg, WPARAM param, LPARAM lparam) {
switch (msg) {
case WM_CREATE:
Controls(hwnd);
break;
case WM_DESTROY:
PostQuitMessage(0);
return 0;
case WM_COMMAND:
{
if ((HIWORD(param) == BN_CLICKED) && (lparam != 0))
{
switch (LOWORD(param))
{
case JOIN_RAID:
stopRaidAction=false;
MessageBeep(MB_OK);
joinThread = std::thread(JoinLoop, hwnd);
break;
case STOP_RAID:
stopRaidAction=true;
MessageBeep(MB_OK);
if (joinThread.joinable()) joinThread.join();
break;
}
}
break;
}
default:
return DefWindowProc(hwnd, msg, param, lparam);
}
return 0;
}
But this is just speculation since you did not explain what you are actually trying to achieve in the first place.
Update:
IT WAS THE FOR LOOP. I am literally dying. I don't even know how many hours I spent debugging only to find out that the for loop was messed up and causing the hangs.

Catch Ctrl+Alt keys in wndproc

I have successfully caught Alt+F4 inside my overridden wndproc function using:
LRESULT CALLBACK NewWndProc(HWND hwnd,
UINT uMsg,
WPARAM wParam,
LPARAM lParam
)
{
if (uMsg == WM_SYSKEYDOWN)
{
switch (wParam)
{
case VK_F4:
{
qDebug() << "Alt+F4 pressed";
break;
}
};
}
else
return CallWindowProc(OldWinProc,hwnd,uMsg,wParam,lParam);
}
I now need to catch Ctrl+Alt+Tab and Ctrl+Alt+←
But I can't seem to find them.
I know in C# one of the parameters in the function is:
Keys keyData
And I can use the following:
case Keys.Control | Keys.Alt | Keys.Q:
How do I get those key combinations in C++?
Use GetKeyState WinAPI function to get state of modifier keys like Ctrl. For example:
case VK_LEFT:
{
if (GetKeyState(VK_CONTROL) & 0x8000)
{
qDebug() << "Alt+Ctrl+Left Arrow pressed";
break;
}
}
But please take in account that some videocard drivers under Windows can rotate screen on Ctrl+Alt+← combination and intercept this combination before your code gets it. And it will be a bit hard to implement getting this keyboard event before driver. However you can disable this feature

weird if statement causing to shut timer

So I've been trying to figure the following:
LRESULT CALLBACK WindowProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
HDC hDC; // Display context handle
PAINTSTRUCT PaintSt; // Structure defining area to be drawn
RECT aRect; // A working rectangle
HPEN hPen; // A working pen
HBRUSH hBrush; // A working brush
switch(message)
{
case WM_TIMER:
switch(wParam)
{
case IDT_TIMER1:
redraw = true;
InvalidateRect(hWnd, NULL, TRUE);
case IDT_TIMER2:
if(keys[UP])
{
rect2.bottom -= 5;
rect2.top -= 5;
}
if(keys[DOWN])
{
rect2.bottom += 5;
rect2.top += 5;
}
if(keys[RIGHT])
{
rect2.left += 5;
rect2.right += 5;
}
if(keys[LEFT])
{
rect2.left -= 5;
rect2.right -= 5;
}
}
return 0;
case WM_PAINT:
//if(redraw)
{
redraw = false;
render_frame();
}
return 0;
case WM_KEYDOWN:
switch(wParam)
{
case VK_UP:
keys[UP] = true;
break;
case VK_DOWN:
keys[DOWN] = true;
break;
case VK_LEFT:
keys[LEFT] = true;
break;
case VK_RIGHT:
keys[RIGHT] = true;
break;
default:
break;
}
return 0;
case WM_KEYUP:
switch(wParam)
{
case VK_UP:
keys[UP] = false;
break;
case VK_DOWN:
keys[DOWN] = false;
break;
case VK_LEFT:
keys[LEFT] = false;
break;
case VK_RIGHT:
keys[RIGHT] = false;
break;
default:
break;
}
return 0;
case WM_DESTROY:
PostQuitMessage(0);
return 0;
default:
return DefWindowProc(hWnd, message, wParam, lParam); // default message processing
}
}
So here's the problem: in the case WM_PAINT:, when I uncomment the if statement, the time stops ticking for some reason. I have no idea why and don't know how to correlate this with anything. So, if I uncomment it, it will not render nor it will it recieve information from the other timer (there are two timers). Please help me, and please don't laugh if it is silly.
The WM_TIMER message is a "low priority" message, it is only generated when nothing else needs to be done. The trouble with your WM_PAINT handler is that it doesn't paint the first time it is generated, immediately after creating the window. EndPaint() isn't called, Which leaves the "window is dirty" status bit turned on. Which immediately causes another WM_PAINT message to be generated. Which still won't paint because redraw isn't true. Etcetera, your app is burning 100% core on the WM_PAINT messages and never gets idle enough to allow a WM_TIMER message to be generated.
Simply remove the redraw test to fix your problem. Always draw when Windows asks for it. Or pass the message to DefWindowProc().
Handling WM_PAINT without drawing anything (assuming redraw stays false), and without even calling DefWindowProc is very unorthodox. Your app might even be alive without you noticing.
From the doc:
An application must call BeginPaint and EndPaint in response to
WM_PAINT messages, or pass the message to the DefWindowProc function
to validate the window. DefWindowProc validates the update region; it
can send the WM_ERASEBKGND message if the window background needs to
be erased.

PeekMessage not getting the message?

I've created a custom message type for use in resizing my Window, called WM_NEED_RESIZE. I've defined it in my .h file, and initialized in my .cpp file. I have also registered my WindowProc function to accept messages. Here is the code for these items:
const uint32 WindowsGLWindow::WM_NEED_RESIZE = WM_USER + 100;
LONG WINAPI WindowsGLWindow::WindowProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
static PAINTSTRUCT ps;// do I need this?
static sint32 newWidth = 0;
static sint32 newHeight = 0;
bool res = false;
switch (uMsg) {
case WM_PAINT:
//display();
BeginPaint(hWnd, &ps);
EndPaint(hWnd, &ps);
return 0;
case WM_SIZE:
//glViewport(0, 0, LOWORD(lParam), HIWORD(lParam));
res = PostMessage(hWnd, WindowsGLWindow::WM_NEED_RESIZE, wParam, lParam);
std::cout << "WM_SIZE: " << res << std::endl;
return 0;
case WindowsGLWindow::WM_NEED_RESIZE:
std::cout << "WindowsGLWindow::WM_NEED_RESIZE" << std::endl;
break;
case WM_CHAR:
switch (wParam) {
case 27: /* ESC key */
PostQuitMessage(0);
break;
}
return 0;
case WM_CLOSE:
PostQuitMessage(0);
return 0;
}
return DefWindowProc(hWnd, uMsg, wParam, lParam);
}
In another function I am running through PeekMessage(..) to collect all messages. Here is the snippet of the message pump:
MSG msg;
while (PeekMessage(&msg, 0, 0, 0, PM_REMOVE) == TRUE) // maybe use GetInputState(?) as well?
{
if (msg.message == WM_QUIT)
retVal = -1;
if (msg.message == WindowsGLWindow::WM_NEED_RESIZE) {
uint32 newWidth = LOWORD(msg.lParam);
uint32 newHeight = HIWORD(msg.lParam);
std::cout << "PeekMessage: WindowsGLWindow::WM_NEED_RESIZE" << std::endl;
// call resize only if our window-size changed
if ((newWidth != width_) || (newHeight != height_)) {
resize(newWidth, newHeight);
}
PostMessage(msg.hwnd, WM_PAINT, 0, 0);
}
switch (msg.message) {
case WM_MOUSEMOVE:
// Retrieve mouse screen position
//int x = (short) LOWORD(lParam);
//int y = (short) HIWORD(lParam);
// Check to see if the left button is held down:
//bool leftButtonDown = wParam & MK_LBUTTON;
// Check if right button down:
//bool rightButtonDown = wParam & MK_RBUTTON;
break;
case WM_LBUTTONDOWN:
case WM_RBUTTONDOWN:
case WM_LBUTTONUP:
case WM_RBUTTONUP:
case WM_KEYUP:
case WM_KEYDOWN:
/*
switch (msg.wParam) {
case 'W':
// w key pressed
break;
case VK_RIGHT:
// Right arrow pressed
break;
default:
break;
}
*/
break;
}
TranslateMessage(&msg);
DispatchMessage(&msg);
}
My problem is that the WM_NEED_RESIZE message is only found once in the message queue when the window first opens, after which it is never found in the message queue by my PeekMessage(..). I'm really not sure why this is happening. It is, however, being received by the WindowProc(..) method (which doesn't really help me). I would appreciate any help you guys could provide.
Thanks
Jarrett
Dont use std::cout expecting to see that output in your debugger, insted use OutputDebugString(); .
You need to pass your class pointer to the last parameter of your call to CreateWindowEx, then retrieve that pointer from the LPCREATESTRUCT passed to you in the LPARAM of WM_CREATE, your class pointer will be in the lpCreateParmas feild of the struct. Set your clas pointer to the GWLP_USERDATA of your window, and on any other message calls , call GetWindowsLong , retrieve your class pointer, then pass the message, wparam, and lparam all off to your internal class message handler.
http://msdn.microsoft.com/en-us/library/ff381400%28v=VS.85%29.aspx
The message pump loop that you are showing will exit as soon as the queue is empty. I can't tell from what you've posted if it ever gets entered again.
If this is your main message pump, you should use GetMessage() instead, as it will wait until something is available before returning. Take a look at this MSDN article for more info.

Keyboard Hook problems

I am doing a voice chat application which uses a push-to-talk key. I have done a hook so it will register push-to-talk outside application too.
HHOOK hHook = SetWindowsHookEx(WH_KEYBOARD_LL,(HOOKPROC)pushtotalk,0,0);
LRESULT CALLBACK pushtotalk(int key, WPARAM wParam,LPARAM lParam) {
if (key < 0) {
return (CallNextHookEx(hook,key,wParam,lParam));
}
else if (connected) {
KBDLLHOOKSTRUCT* kbdll = (KBDLLHOOKSTRUCT*)lParam;
if (kbdll ->vkCode == 75 && wParam == WM_KEYDOWN) {
MessageBox(mainhWnd,"KEYSTART","KEYSTART",0);
}
else if (kbdll ->vkCode == 75 && wParam == WM_KEYUP) {
MessageBox(mainhWnd,"KEYSTOP","KEYSTOP",0);
}
}
return (CallNextHookEx(hook,key,wParam,lParam));
}
Problems;
1) Sometimes, (for example the first execution of the proc in the application), the proc causes a 5 sec system freeze before continuing. Why?
2) The hook only works on process that were started before my application started, if I start a text program after starting my application, the hooks wont register. Is there a fix for this?
3) If I hold down the key for ~3 seconds, alot of MessageBoxes shows obviously, but after that, the proc will never register another key being pushed down, so I guess I somehow gets disconnected from the hook chain?
Cheers
EDIT: Here's the main message loop for the application
LRESULT CALLBACK WindowProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) {
switch(message) {
case WM_COMMAND:
switch (LOWORD(wParam)) {
case ID_MENU_EXIT:
SendMessage(hWnd,WM_CLOSE,0,0);
break;
case ID_MENU_PREFERENCES:
voiceManager->send((void*) "1");
break;
case ID_BUTTON_CONNECT:
onConnect(hWnd);
break;
case ID_BUTTON_DISCONNECT:
onDisconnect(hWnd);
break;
case ID_BUTTON_SEND:
onSendText(hWnd);
break;
default:
break;
}
break;
case SOCKET_TCP:
switch (lParam) {
case FD_READ:
{
// Disable repeated FD_READ call while we process message
WSAAsyncSelect(wParam,hWnd,SOCKET_TCP, FD_WRITE | FD_ACCEPT | FD_CLOSE);
// first four bytes is packet size
// second four bytes are used to identify type of msg
char* psize = (char*)malloc(5);
char* ptype = (char*)malloc(5);
psize[4] = '\0';
ptype[4] = '\0';
recv(wParam,psize,4,0);
recv(wParam,ptype,4,0);
// allocate memory for the buffer
int size_to_recv = atoi(psize);
char* textbuff = (char*)malloc(size_to_recv);
// receive
int i = size_to_recv;
while (i > 0) {
int read = recv(wParam,textbuff,i,0);
i = i - read;
}
// handle msg depending on type
switch(identifyMsg(ptype)) {
case 1:
// handle 'text' msg
onReadText(hWnd,textbuff);
break;
case 2:
// handle 'name' msg
onReadName(hWnd,textbuff);
break;
case 3:
// handle 'list' msg
onReadList(hWnd,textbuff);
break;
case 4:
// handle 'remv' msg
onReadRemv(hWnd,textbuff,size_to_recv);
break;
case 5:
// handle 'ipad' msg -- add ip
voiceManager->addParticipant(inet_addr(textbuff));
break;
case 6:
// handle 'iprm' msg -- remove ip
voiceManager->removeParticipant(inet_addr(textbuff));
break;
default:
break;
}
// re-enable FD_READ
WSAAsyncSelect(wParam,hWnd,SOCKET_TCP, FD_WRITE | FD_ACCEPT | FD_READ | FD_CLOSE);
// free resources
free(psize);
free(ptype);
free(textbuff);
break;
}
case FD_WRITE:
break;
case FD_CONNECT:
break;
case FD_CLOSE:
onDisconnect(hWnd);
break;
default:
break;
}
break;
case WM_PAINT:
paintText(hWnd);
break;
case WM_DESTROY:
shutdownConnection(hWnd);
// reset window procs
SetWindowLong(GetDlgItem(hWnd,ID_EDIT_SEND), GWL_WNDPROC,(LONG) OriginalEditProc);
SetWindowLong(GetDlgItem(hWnd,ID_EDIT_IP), GWL_WNDPROC,(LONG) OriginalEditProc);
PostQuitMessage(0);
return 0;
break;
case WM_CLOSE:
DestroyWindow(hWnd);
break;
default:
break;
}
return DefWindowProc(hWnd, message, wParam, lParam);
}
LRESULT CALLBACK sendEditProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) {
if (message == WM_CHAR) {
if (wParam == VK_RETURN) {
onSendText(GetParent(hWnd));
return 0;
}
}
if (message == WM_KEYUP || message == WM_KEYDOWN) {
if (wParam == VK_RETURN) {
return 0;
}
}
return CallWindowProc(OriginalEditProc, hWnd, message, wParam,lParam);
}
Where sendEditProc is a sub/superclass designed to intercept 'enter' keys when inside an edit control 'send'
Does this help?
Here's the message loop; it's the standard so nothing fancy that could go wrong afaik :)
while (GetMessage(&msg, NULL,0,0)) {
TranslateMessage(&msg);
DispatchMessage(&msg);
}
You're calling CallNextHookEx one too many times. If key < 0 return CallNextHookEx, otherwise return 0.
The problem you're seeing has to do with keyboard repeats and the MessageBox or MessageBeep methods being very, very expensive calls. Try this test:
HHOOK hHook;
BOOL bTalkEnabled = FALSE;
LRESULT CALLBACK pushtotalk(int key, WPARAM wParam, LPARAM lParam)
{
if (key < 0)
return CallNextHookEx(hHook, key, wParam, lParam);
KBDLLHOOKSTRUCT* kbdll = (KBDLLHOOKSTRUCT*)lParam;
if (kbdll->vkCode == VK_F11)
{
BOOL bStarted = FALSE;
BOOL bStopped = FALSE;
if (wParam == WM_KEYDOWN)
{
if (!bTalkEnabled)
{
bStarted = TRUE;
bTalkEnabled = TRUE;
}
}
else if (wParam == WM_KEYUP)
{
if (bTalkEnabled)
{
bStopped = TRUE;
bTalkEnabled = FALSE;
}
}
if (bStarted)
OutputDebugString(L"Pushed\r\n");
if (bStopped)
OutputDebugString(L"Released\r\n");
}
return 0;
}
You can monitor the debug strings by running the app under the debugger (check the Output window), or you can get DebugView and watch that.
Notice that I do not check for connected as you did. You don't want to perform that check in the hook, do that outside the hook and only use the hook to determain if the key is pressed or not pressed.