Win32 GUI and callback to C++ function - c++

So, basically I'm using a code like this one. It's a little simple window where you can only change text inside of an edit box and press a button that will make a callback to a function (DoSomethingCallback(text)).
#include <windows.h>
#define ID_EDIT 1
#define ID_BUTTON 2
LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
static HWND hwndEdit;
static HWND hwndButton;
static int len;
static TCHAR text[30];
switch(msg)
{
case WM_CREATE:
hwndEdit = CreateWindow(TEXT("Edit"), NULL, WS_CHILD | WS_VISIBLE | WS_BORDER,
50, 50, 150, 20, hwnd, (HMENU) ID_EDIT,
NULL, NULL);
hwndButton = CreateWindow(
TEXT("button"), TEXT("Set Title"),
WS_VISIBLE | WS_CHILD,
50, 100, 80, 25,
hwnd, (HMENU) ID_BUTTON, NULL, NULL);
break;
case WM_COMMAND:
if (HIWORD(wParam) == BN_CLICKED) {
SetWindowText(hwnd, "Working...");
GetWindowText(hwndEdit, text, len);
DoSomethingCallback(text);
SetWindowText(hwnd, "Finished");
}
break;
case WM_DESTROY:
PostQuitMessage(0);
break;
}
return DefWindowProc(hwnd, msg, wParam, lParam);
}
int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPSTR lpCmdLine, int nCmdShow )
{
MSG msg ;
WNDCLASS wc = {0};
wc.lpszClassName = TEXT( "Edit Control" );
wc.hInstance = hInstance ;
wc.hbrBackground = GetSysColorBrush(COLOR_3DFACE);
wc.lpfnWndProc = WndProc ;
wc.hCursor = LoadCursor(0,IDC_ARROW);
RegisterClass(&wc);
CreateWindow( wc.lpszClassName, TEXT("Edit control"),
WS_OVERLAPPEDWINDOW | WS_VISIBLE,
220, 220, 280, 200, 0, 0, hInstance, 0);
while( GetMessage(&msg, NULL, 0, 0)) {
TranslateMessage(&msg);
DispatchMessage(&msg);
}
return (int) msg.wParam;
}
The problem is that when running that Callback the window will appear as "Not responsive" and even laggy if you try to close or press the button. I understand the reason why this might be happening, the callback takes time and the receiving loop isn't there to check the input of the user. I've searched a way to 'fix' this and I couldn't find any. I'm pretty sure it's something dumb, but I have to try and ask.
An obvious way would be making a faster callback. But is there another one like checking the user input inside of a DoSomethingCallback() while, or I have to use multiple threads?
Sorry for the confusing question.

I would go for calling QueueUserWorkItem() to handle it. If your DoSomethingCallback() is too long, there is no way to make your window responsive while DoSomethingCallback() is working since there is only one thread to run the code. Good Luck!

If possible, you can process the message queue at intervals within DoSomethingCallback which will keep the UI responsive. Just run the original message loop i.e. while( GetMessage(... whenever you can but make sure you disable the button so the user does not click a second time... this will lead to recursion.

You can peek at the message queue to convince windows that you are still alive and kicking, by calling PeekMessage() from time to time. This assumes that you can do this in your DoSomethingCallback(), i.e. that the main thread doesn't hang completely. Regard the loop below as pseudo code and use your imagination to transform it to your needs.
void DoSomethingCallback()
{
// Loop that takes a long time
while (true) {
DoSomeStuff();
MSG msg;
PeekMessage(&msg, nil, 0, 0, PM_NOREMOVE);
if (ShouldBreak()) {
break;
}
}
}

Related

WM_COMMAND unabled to fulfil request unless clicked outside of application window,

Currently creating an application that just outputs Physics equations + some historical and mathematical context. I've ran into this problem where I'm using WS_EX_CLIENTEDGE to sort out a list of these terms and when I click said term on the screen, expecting a definition to appear, it doesn't output anything until I've clicked outside of the application window(Visual Studio, Debug Terminal, etc)
Cursed gif
And I want to make it clear that I DON'T want to use a button due to GUI aesthetics.
Mundane WINAPI application creation
int main(HINSTANCE hInstance, HINSTANCE hPrevInstance, PWSTR pCmdLine, int nCmdShow)
{
const wchar_t CLASS_NAME[] = L"Application";
WNDCLASS window = { 0 };
MSG msg = { 0 };
window.lpfnWndProc = WindowProc;
window.lpszClassName = CLASS_NAME;
window.hInstance = hInstance;
RegisterClass(&window);
HWND hWnd = CreateWindow(CLASS_NAME, L"PhysicsBox", WS_VISIBLE | WS_OVERLAPPEDWINDOW, 100, 100, 600, 500, NULL, NULL, NULL, NULL);
ShowWindow(hWnd, nCmdShow);
//aMessageBox = CreateWindowW(L"edit", L" ", WS_VISIBLE | WS_CHILD | WS_BORDER, 165, 150, 400, 300, hWnd, NULL, NULL, NULL);
while (GetMessage(&msg, NULL, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
return 0;
}
The Juicy Window Procedure
LRESULT CALLBACK WindowProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
switch (uMsg)
{
case WM_CREATE:
aListBox(hWnd);
break;
case WM_COMMAND:
if (SendMessage(hList, LB_GETSEL, FORCE, 0))
{
CreateWindowW(L"static", L"Simple Text", WS_VISIBLE | WS_CHILD | WS_BORDER | SS_CENTER, 200, 100, 100, 100, hWnd, NULL, NULL, NULL);
}
break;
case WM_DESTROY:
PostQuitMessage(0); break;
default:
return DefWindowProc(hWnd, uMsg, wParam, lParam);
}
}
The void function that creates the list
void aListBox(HWND hWnd)
{
hList = CreateWindowEx(WS_EX_CLIENTEDGE, L"ListBox", L" ", WS_CHILD | WS_VISIBLE | WS_VSCROLL | ES_AUTOVSCROLL, 3, 4, 150, 300, hWnd, (HMENU)ID_LISTBOX, 0, 0);
SendMessageW(hList, LB_ADDSTRING, FORCE, (LPARAM)L"Force");
SendMessageW(hList, LB_ADDSTRING, WORK, (LPARAM)L"Work");
SendMessageW(hList, LB_ADDSTRING, POWER, (LPARAM)L"Power");
SendMessageW(hList, LB_ADDSTRING, EFFICENCY, (LPARAM)L"Efficency");
SendMessageW(hList, LB_ADDSTRING, POTENTIALENERGY, (LPARAM)L"Potential Energy");
SendMessageW(hList, LB_ADDSTRING, HOOKESLAW, (LPARAM)L"Hooke's Law");
}
Note: the MSG('s) placed in the "aListBox(HWND hWnd)" SendMessageW parameters are numerically ordered(from 0). So FORCE = 0, WORK = 1, and so on. Also hList is a global variable if that helps :P
The listbox is created without the LBS_NOTIFY style and will therefore not send LBN_SELCHANGE notifications to the parent window. Changing the first line in aListBox to the following fixes this.
hList = CreateWindowEx(WS_EX_CLIENTEDGE, L"ListBox", L" ", WS_CHILD | LBS_NOTIFY | WS_VISIBLE | WS_VSCROLL | ES_AUTOVSCROLL, 3, 4, 150, 300, hWnd, (HMENU)ID_LISTBOX, 0, 0);
Also, the WindowProc does not return a result on all code paths, and does not call DefWindowProc for all messages that it does not handle. The following corrects those issues.
LRESULT CALLBACK WindowProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
switch (uMsg)
{
case WM_CREATE:
aListBox(hWnd);
return 0;
case WM_COMMAND:
if (SendMessage(hList, LB_GETSEL, FORCE, 0))
{
HWND hText = CreateWindowW(L"static", L"Simple Text", WS_VISIBLE | WS_CHILD | WS_BORDER | SS_CENTER, 200, 100, 100, 100, hWnd, NULL, NULL, NULL);
ShowWindow(hText, SW_SHOW);
return 0;
}
break;
case WM_DESTROY:
PostQuitMessage(0);
return 0;
}
return DefWindowProc(hWnd, uMsg, wParam, lParam);
}
Other problems remain with the code, for example the WindowProc does not check the WM_COMMAND notification code and will happily create new windows over and over, but the assumption was that this was minimal code only meant to showcase the particular issue in the question.
[ EDIT ]   The behavior described by the OP when running without the LBS_NOTIFY style bit is mostly accidental, due to WM_COMMAND not checking the WPARAM notification code. What happens is that clicking outside the app window causes the listbox to send a LBN_KILLFOCUS notification (which is being sent regardless of LBS_NOTIFY). That notification is the one which triggers the WM_COMMAND code in WindowProc that creates the static control when the FORCE item is selected.

How to correctly create push buttons on winApi as well as Handle its messages

So my program works, all apart from one thing, I would like for my button, 'pushBtn' , aka BTN_PUSH_TALK , to send a BN_PUSHED or BN_UNPUSHED message so I can handle it accordingly.
Following steps online, as well as trial and improvement, right now the only response I ever get is once I am done holding / clicking the button.
pushBtn = CreateWindowEx(0, L"BUTTON", L"TALK", WS_CHILD |
WS_VISIBLE |
BS_DEFPUSHBUTTON , 0 , 290 , 50, 50,
hWnd,(HMENU)BTN_PUSH_TALK, GetModuleHandle(NULL), NULL);
Handler (or at least what matters) :
LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM
lParam)
{
bool asd;
switch (message)
{
case WM_COMMAND:
{
int wmId = LOWORD(wParam);
// Parse the menu selections:
switch (wmId)
{
case BTN_PUSH_TALK:
switch (HIWORD(wParam))
{
case BN_UNPUSHED:
if (connected && inputChoiceStr == "Push To Talk") {
tplug->setDuck(false);
}
break;
case BN_PUSHED:
if (connected && inputChoiceStr == "Push To Talk") {
tplug->setDuck(true);
}
break;
}
break;
I expected once i clicked and held down the button , that the BN_PUSHED case would be entered, however it is not.
On letting go, I expect the BN_UNPUSHED case to be entered, but this was not the case either.
case BTN_PUSH_TALK is reached, meaning the button is identifiable, however the switch case within this block of code is never reached.
Buttons send WM_COMMAND on click. To achieve a push/release notification you must subclass the button class (SetWindowLongPtr() with GWLP_WNDPROC) and then handle WM_LBUTTONDOWN and WM_LBUTTONUP in your new Window Proc.
If I'm reading the question right, your goal is to get notifications when a standard push button is initially pushed by the user, whereas standard notification behavior of buttons only posts WM_COMMANDs on "clicks" where a click is the whole mouse down plus mouse up sequence.
Historically in order to get the BN_PUSHED and BN_UNPUSHED notifications in your WM_COMMAND handler you had to use the BS_NOTIFY window style when creating the button. However, if you read the documentation for BN_PUSHED or BN_UNPUSHED you will see
This notification code is provided only for compatibility with 16-bit versions of Windows earlier than version 3.0. Applications should use the BS_OWNERDRAW button style and the DRAWITEMSTRUCT structure for this task.
These were very old notifications that from what I can tell are not just deprecated but no longer even supported. You can do, however, as the documentation suggests: use an owner drawn button i.e. a button created with the BS_OWNERDRAW style.
This turns out to be more difficult than just creating the button with BS_NOTIFY turned on, because the button will no longer perform default painting by itself. Given this added chore, I'd recommend not doing it this way unless you want to custom paint your buttons anyway -- unless you happen to want some nonstandard visual look-and-feel for these buttons as well as nonstandard notification behavior. Otherwise, I would probably just do Win32 subclassing as someone else suggested to trap WM_LBUTTONDOWN etc. and then call the standard button WNDPROC after doing some action on the events i cared about.
Anyway the minimal owner drawn button that reports button down and button up events is like the following. (I post the button events as custom messages but you could do whatever you wish there)
#include <windows.h>
#define BTN_ID 101
#define WM_PUSHBUTTONDOWN WM_APP + 1
#define WM_PUSHBUTTONUP WM_APP + 2
HINSTANCE g_instance = 0;
LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam);
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
g_instance = hInstance;
MSG msg = { 0 };
WNDCLASS wc = { 0 };
wc.lpfnWndProc = WndProc;
wc.hInstance = hInstance;
wc.hbrBackground = reinterpret_cast<HBRUSH>(COLOR_BACKGROUND);
wc.lpszClassName = L"owner_draw_btn";
if (!RegisterClass(&wc))
return -1;
if (!CreateWindow(wc.lpszClassName, L"foobar", WS_OVERLAPPEDWINDOW | WS_VISIBLE, 0, 0, 640, 480, 0, 0, hInstance, NULL))
return -1;
while (GetMessage(&msg, NULL, 0, 0)) {
TranslateMessage(&msg);
DispatchMessage(&msg);
}
return 0;
}
LRESULT HandleDrawItem(HWND hWnd, WPARAM wParam, LPARAM lParam)
{
auto* dis = reinterpret_cast<DRAWITEMSTRUCT*>(lParam);
if (dis->CtlType != ODT_BUTTON)
return 0;
auto style = (dis->itemState & ODS_SELECTED) ?
DFCS_BUTTONPUSH | DFCS_PUSHED :
DFCS_BUTTONPUSH;
auto rect = &dis->rcItem;
DrawFrameControl(dis->hDC, rect, DFC_BUTTON, style);
TCHAR text[512];
auto n = GetWindowText(dis->hwndItem, text, 512);
DrawText(dis->hDC, text, n, rect, DT_SINGLELINE | DT_VCENTER | DT_CENTER);
if (dis->itemAction == ODA_SELECT) {
PostMessage(
hWnd,
(dis->itemState & ODS_SELECTED) ? WM_PUSHBUTTONDOWN : WM_PUSHBUTTONUP,
dis->CtlID,
0
);
}
return 0;
}
LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
switch (message)
{
case WM_CREATE:
CreateWindow(
L"button", L"foobar",
BS_OWNERDRAW | WS_CHILD | WS_VISIBLE,
10, 10, 150, 35, hWnd,
(HMENU) BTN_ID,
g_instance,
0
);
return 0;
case WM_DRAWITEM:
return HandleDrawItem(hWnd, wParam, lParam);
case WM_PUSHBUTTONDOWN:
OutputDebugString(L"Button down event\n");
break;
case WM_PUSHBUTTONUP:
OutputDebugString(L"Button up event\n");
break;
case WM_CLOSE:
PostQuitMessage(0);
return 0;
}
return DefWindowProc(hWnd, message, wParam, lParam);
}

Can I run a while() at the same time as a switch(messages) statement? (c++)

I have a simple program. It looks like this:
bool i = fasle;
int WINAPI WinMain(HINSTANCE hThisInstance,
HINSTANCE hPrevInstance,
LPSTR lpszArgument,
int nCmdShow)
{
/*COMMENT TO REPRESENT WNDCLASSEX STUFF*/
return messages.wParam;
}
LRESULT CALLBACK WindowProcedure(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
switch(message)
{
case WM_CREATE:
CreateWindow(
TEXT("button"),TEXT("Activate"),
WS_VISIBLE | WS_CHILD,
10,
100,
100,
50,
hwnd,
(HMENU) 1,
NULL, NULL
);
CreateWindow(
TEXT("button"),TEXT("Deactivate"),
WS_VISIBLE | WS_CHILD,
10,
250,
100,
50,
hwnd,
(HMENU) 2,
NULL, NULL
);
break;
case WM_COMMAND:
if(LOWORD(wParam) == 1){
i = true;
}
if(LOWORD(wParam) == 2){
i = false;
}
break;
case WM_DESTROY:
PostQuitMessage (0);
break;
default:
return DefWindowProc (hwnd, message, wParam, lParam);
}
return 0;
}
I want a while statement to run no matter what. The loop looks like this:
while(1)
{
if(i == true)
{
/*DO STUFF*/
}
}
Where can I add my loop into my code to make it run forever?
Where can I add my loop into my code to make it run forever?
In a different thread.
Sorry, but this is a fact of life with GUIs. The Win32 GUI programming model is event driven, and in event driven systems you cannot do long-running operations on the GUI thread, because then the GUI thread never gets the chance to process any messages.
So, you have to move your endless- (or even just long-) running loop in a different thread.
However, this is quite likely an X-Y Problem. (http://xyproblem.info/)

Painting gives unusual results, black portions of window

I'm creating a win32 application in C++ and trying (unsuccessfully) to keep things somewhat object-orientated while still respecting the winapi message loop etc.
The problem I'm having is that my window seems to be drawing inconsistently and/or in a weird way that I have not encountered before. Eg:
This occurs when the window is resized. If I minimize the window and open it again, everything is black, apart from the buttons. Also, when moving my mouse from outside the window into the window, whatever my cursor was before getting inside the window is retained. For example, if there is a textbox behind the window, and I move my cursor from the textbox and into this window, the cursor remains the caret cursor.
I'm using this code to handle messages inside my WindowMain class:
std::map<HWND, WindowMain*> WindowMain::HWNDMap;
LRESULT CALLBACK WindowMain::WndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam) {
if (HWNDMap.find(hWnd) == HWNDMap.end()) { return DefWindowProc(hWnd, msg, wParam, lParam); }
return HWNDMap[hWnd]->InstWndProc(hWnd, msg, wParam, lParam);
}
LRESULT CALLBACK WindowMain::InstWndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam) {
switch (msg) {
case WM_CLOSE:
PostQuitMessage(0);
break;
case WM_DESTROY:
DeleteObject(_hFont);
break;
default:
return DefWindowProc(hWnd, msg, wParam, lParam);
}
return 0;
}
The WindowMain::WndProc function is a static member of WindowMain. I use a std::map to map HWND to WindowMain* so that I can pass messages from the static method to the relevant WindowMain::InstWndProc. I feel like the problem might be here but I can't spot it.
In case it's relevant, this is the code I'm using to create the window:
WindowMain::WindowMain(HINSTANCE hInst) {
_isReady = false;
WNDCLASS wc;
memset(&wc, 0, sizeof(wc));
wc.lpfnWndProc = WndProc;
wc.lpszClassName = ClassName.c_str();
wc.hInstance = hInst;
wc.hbrBackground = (HBRUSH)(0);
if (!RegisterClass(&wc)) { return; }
_hWnd = CreateWindow(ClassName.c_str(), "AlchemyAC", WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, 400, 300, NULL, NULL, hInst, NULL);
if (!_hWnd) { return; }
_hBtnStart = CreateWindow("BUTTON", "Start", WS_TABSTOP | WS_VISIBLE | WS_CHILD, 10, 10, 100, 24, _hWnd, NULL, hInst, NULL);
_hBtnStop = CreateWindow("BUTTON", "Stop", WS_TABSTOP | WS_VISIBLE | WS_CHILD, 10, 39, 100, 24, _hWnd, NULL, hInst, NULL);
if (!_hBtnStart || !_hBtnStop) { return; }
GetObject(GetStockObject(DEFAULT_GUI_FONT), sizeof(LOGFONT), &_lf);
_hFont = CreateFont(_lf.lfHeight, _lf.lfWidth,
_lf.lfEscapement, _lf.lfOrientation, _lf.lfWeight,
_lf.lfItalic, _lf.lfUnderline, _lf.lfStrikeOut, _lf.lfCharSet,
_lf.lfOutPrecision, _lf.lfClipPrecision, _lf.lfQuality,
_lf.lfPitchAndFamily, _lf.lfFaceName);
SendMessage(_hBtnStart, WM_SETFONT, (WPARAM)_hFont, true);
SendMessage(_hBtnStop, WM_SETFONT, (WPARAM)_hFont, true);
EnableWindow(_hBtnStop, false);
HWNDMap[_hWnd] = this;
_isReady = true;
}
My question is, why is this strange painting issue occurring? I'm mainly interested in the odd thing that is happening with the cursor.
EDIT: I am using a while loop to translate and dispatch messages.

Command Prompt window appears with gui window c++

Whenever I try to make a c++ gui program/window the command prompt window appears with the window like this:
but all I did was this::
#include <iostream>
#include "define.h"
LRESULT CALLBACK WinProc(HWND hWnd,UINT message,WPARAM wParam,LPARAM lParam);
int WINAPI WinMain(HINSTANCE hInst, HINSTANCE hPrevInst, LPSTR lpCmdLine, int nShowCmd){
window win;
MSG msg;
win.cbClsExtra = NULL; //Additional parameters
win.cbWndExtra = NULL; //Additional parameters
win.hbrBackground = (HBRUSH)COLOR_WINDOW ; //Sets background color for the window
win.hCursor = LoadCursor(NULL, IDC_ARROW); //The cursor that will appear in the window
win.hIcon = NULL; //Icon for the window
win.hInstance = hInst; //Handle to the application instance
win.lpszClassName = "Window Class"; //The unique name of the window class
win.lpszMenuName = NULL; //Used for menus
win.style = NULL; //The look and feel of the window
win.lpfnWndProc=(WNDPROC)WinProc; //The callback procedure (more on that later)
RegisterClass(&win);
HWND hwnd = CreateWindow("Window Class", "Title", WS_OVERLAPPEDWINDOW, 200, 200, 640, 480, NULL, NULL, hInst, NULL);
ShowWindow(hwnd, SW_SHOWNORMAL);
while(GetMessage(&msg, NULL, 0, 0)){
TranslateMessage(&msg);
DispatchMessage(&msg);
}
return 0;
}
LRESULT CALLBACK WinProc(HWND hWnd,UINT message,WPARAM wParam,LPARAM lParam){
switch (message){
case WM_CREATE:{
HWND button = CreateWindow("BUTTON", "ok", WS_VISIBLE | WS_CHILD | WS_BORDER, 20, 20, 50, 30, hWnd, NULL, NULL, &lParam);
break;
}
case WM_DESTROY:{
PostQuitMessage(0);
return 0;
break;
}
default:{
return DefWindowProc(hWnd, message, wParam, lParam);
}
}
}
I followed the code just on internet and don't think I did something wrong I want to remove this annoying cmd window by any way...
tysm for all repliers much appreciated...........
EDIT
and btw the define.h is a header file I made and define WNDCLASS as window