I've got this code to load a bitmap:
HBITMAP reg_hbmCS = NULL;
LRESULT CALLBACK WndProc(HWND hRegWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
switch(message)
{
case WM_CREATE:
reg_hbmCS = LoadBitmap(NULL, MAKEINTRESOURCE(IDB_CSBITMAP));
if(!reg_hbmCS)
MessageBox(hRegWnd,
"No se ha podido cargar el icono del programa.\r\n"
"Pruebe a reinstalar el programa para solucionar este problema.",
"Atención", MB_ICONEXCLAMATION | MB_OK);
break;
case WM_CLOSE:
DeleteObject(reg_hbmCS);
DestroyWindow(hRegWnd);
break;
case WM_DESTROY:
PostQuitMessage(0);
break;
default:
return DefWindowProc(hRegWnd, message, wParam, lParam);
}
return 0;
}
The problem is that the reg_hbmCS won't load, so I don't have the bitmap available (it prompts with the message box in (if !reg_hbmCS).
Here my resources.h:
#ifndef RESOURCES_H
#define RESOURCES_H
#ifndef IDC_STATIC
#define IDC_STATIC -1
#endif
#define IDI_CSICO 101
#define IDB_CSBITMAP 201
#endif // RESOURCES_H
And my resources.rc:
#include <windows.h>
#include "resources.h"
IDI_CSICO ICON "CS-Nursing.ico"
IDB_CSBITMAP BITMAP DISCARDABLE "CS-Nursing.bmp"
In case it was necessary, I use Code::Blocks 12.11 on WindowsXP SP3.
Any help will be much appreciated.
LoadBitmap is probably failing because you haven't told it where to find the bitmap resource. The first parameter to LoadBitmap is a handle to the instance of the module containing the bitmap resource (unless you are loading a system bitmap in which case it is NULL). Since the bitmap resource is being compiled into your application, you need to pass a handle to the instance of your application module as the first parameter when you call LoadBitmap. You can get this handle from the first parameter in your WinMain function. Many people store this parameter in a global variable so that it can be accessed easily from other functions. If the call to LoadBitmap still fails then you should call GetLastError to get a code describing why the call failed. See Windows System Error Codes.
Changed the resources.rc file:
//IDB_CSBITMAP BITMAP DISCARDABLE "CS-Nursing.bmp"
IDB_CSBITMAP BITMAP "CS-Nursing.bmp"
Now it works perfectly, will mark this as solved, thank you all for your help.
Related
I'm learning Win32 programming
I used LoadImage(...) to set the small icon for the window but it doesn't seem to be working and I cannot pinpoint the problem
void AddIcons(HWND hw)
{
HICON hi = LoadImage(NULL, "ICON.bmp", IMAGE_BITMAP, 16, 16, LR_LOADFROMFILE);
printf("Icon initialized\n");
if(hi)
{
printf("%x\n", hi);
SendMessage(hw, WM_SETICON, ICON_SMALL, (LPARAM)hi);
}
}
And the windows procedure:
LRESULT CALLBACK WndProc(HWND handle, UINT message, WPARAM wParam, LPARAM lParam)
{
switch(message)
{
case WM_SETICON: printf("REQUEST RECEIVED\n");
}
.
. // AddIcons() is called here
. // DefWindowProc() handles the message at the end
}
I get all three print statements including REQUEST RECEIVED.
However, the icon is still the default. Where is the problem occuring?
I am aware that I can use keep a resource file and use LoadIcon(..) but I am more comfortable doing everything programatically. Which begs a second question:
Can everything that can be done using resource(.rc) files be done programmatically?
If so, is one method inherently better than the other?
I need help with this code. I need to set the focus to a edit button and read the value entered in the edit box and move it to a variable for further processing. This code creates a text prompt with TextOut() which says " Enter the value of mass:" and an editbox with an IDC_EDIT_MASS and hEditMASS next to it.
I am not able to read the value from edit box into variable mass.
And the code is as follows *
#define IDC_EDIT_MASS 103 // Edit box identifier
RESULT CALLBACK WindowProcedure (HWND hwnd, UINT message, WPARAM wParam, LPARAM
lParam)
{
HWND hEditMASS;
HDC hDC;
PAINTSTRUCT Ps;
HFONT font;
float mass;
char msgMASS[]="Enter the value of mass:";
switch (message) /* handle the messages */
{
case WM_CREATE :
hEditMASS=CreateWindowEx(WS_EX_CLIENTEDGE, “EDIT",
"", WS_CHILD|WS_VISIBLE|ES_MULTILINE|ES_AUTOVSCROLL|ES_AUTOHSCROLL,
550,
200,
200,
20,
hwnd,
(HMENU)IDC_EDIT_MASS,
GetModuleHandle(NULL),
NULL);
Break;
case WM_COMMAND:
switch (LOWORD(wParam)) {
case IDC_EDIT_MASS:
SendMessage(hEditMASS,WM_GETTEXT, sizeof(buffer)/sizeof(buffer[0]),
reinterpret_cast<LPARAM>(buffer));
int ctxtlen=GetWindowTextlength(GetDlgItem(hwnd, IDC_EDIT_MASS));
GetWindowText(GetDlgItem(hwnd, IDC_EDIT_MASS), buffer,(cTxtLen + 1);
mass=atoi(buffer);
MessageBox(NULL,buffer,"Information",MB_ICONINFORMATION);
break;
}
Break;
case WM_SETFOCUS :
SetFocus (hwnd) ;
break;
case WM_PAINT:
hDC = BeginPaint(hwnd, &Ps);
//inputs prompts ...
TextOut(hDC,300,200,msgMASS,sizeof(msgMASS));
EndPaint(hwnd, &Ps);
break;
case WM_DESTROY:
PostQuitMessage (0); /* send a WM_QUIT to the message queue */
break;
default: /* for messages that we don't deal with */
return DefWindowProc (hwnd, message, wParam, lParam);
}
return 0;
}
hEditMASS is an local, automatic-storage-duration variable. You set it when the message is WM_CREATE. However, you then access it when the message is WM_COMMAND. Automatic-storage-duration variables do not retain their value between calls. In order for it to retain its value, you must either make it global or make it static, e.g.:
static HWND hEditMASS;
Keep in mind that you'll probably only be able to use your window procedure for one window now, since creating any other window with the same window procedure will end up using the same hEditMASS variable, and when you next try to access hEditMASS, it will point to the edit control in the most-recently-created window with that window procedure.
I have this code which sets up a keyboard hook for low-level events, then displays a message box.
HHOOK keyboardHook = SetWindowsHookEx (WH_KEYBOARD_LL, HookKey, hInstance, 0);
MessageBox(NULL, L"Click to exit", L"hook test", NULL);
UnhookWindowsHookEx(keyboardHook);
How do I run the application's main loop without creating a foreground window, and how do I set hInstance to capture global events?
The answer is all contained on the MSDN docs page for SetWindowsHookEx. To experiment with a sample application, create a new solution, add two projects, a console app and a DLL. Each project just needs one file. The DLL will contain the hook, and the console app installs the hook.
The code for the hook must live inside a DLL, as the MSDN docs very clearly say:"If the dwThreadId parameter is zero or specifies the identifier of a thread created by a different process, the lpfn parameter must point to a hook procedure in a DLL." Indeed, the hook clearly has to be in a DLL, or how could the shell run the code during another application's message loop? The DLL installs the hook using its HINSTANCE to identify where the function pointer lives.
The main application runs starts the hooks, and pumps messages, again just following the instructions in the MSDN docs: "...the hooking application must continue to pump messages or it might block the normal functioning of the 64-bit processes."
Note that this is very niche application — hardly ever will you need to inject a DLL like this. Please, please, think twice about doing this. For many applications, it's not necessary to capture low-level events, although immersive applications that suppress the Start menu are a reasonable use-case. More importantly though, you very rarely need to capture input sent to other applications. Check before using this code that you really need to do this. For example, recording a macro can be done just by hooking the input to your own application's window.
main.cpp
#include <windows.h>
#include <tchar.h>
__declspec(dllimport) void (__stdcall runHook)(BOOL startOrStop);
__declspec(dllimport) LRESULT (CALLBACK hookProc)(int code, WPARAM wParam, LPARAM lParam);
int _tmain(int argc, _TCHAR* argv[])
{
runHook(true);
MSG Msg;
while(GetMessage(&Msg, NULL, 0, 0) > 0 && Msg.message != WM_QUIT) {
TranslateMessage(&Msg);
DispatchMessage(&Msg);
}
runHook(false);
return 0;
}
Dll.cpp
#include <assert.h>
#include <windows.h>
static HINSTANCE dllInst = 0;
static HHOOK hookSelf = 0;
BOOL APIENTRY DllMain( HMODULE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
dllInst = (HINSTANCE)dllInst;
return TRUE;
}
__declspec(dllexport) LRESULT (CALLBACK hookProc)(int code, WPARAM wParam, LPARAM lParam)
{
if (code >= 0) {
UINT msgType = wParam;
KBDLLHOOKSTRUCT* msgInfo = (KBDLLHOOKSTRUCT*)lParam;
// The msgInfo contains the VK_CODE and flags.
}
return hookSelf ? CallNextHookEx(hookSelf, code, wParam, lParam) : 0;
}
__declspec(dllexport) void (__stdcall runHook)(BOOL startOrStop)
{
assert((bool)hookSelf != (bool)startOrStop);
if (startOrStop)
hookSelf = SetWindowsHookEx(WH_KEYBOARD_LL, hookProc, dllInst, 0);
else {
UnhookWindowsHookEx(hookSelf);
hookSelf = 0;
}
}
One way to do this is creating a TSR(Terminate and Stay Resident) program on Windows.
On Windows, a typical TSR program consists of the following components :
Creating and hiding the main window.
Registering hot keys.
The loop testing events.
Functions responding to hot keys.
Functions invoked periodically by timers.
Here is a good article with code-snippets and detailed explanations about writing TSRs on Windows.
I have to use a simple function from a DLL; I am able to load the library but GetProcAddress returns NULL. I think I understood name mangling but maybe I'm doing something wrong. Thanks (Code follows, asap I'll add other information required):
mydll.h
#ifdef MYDLL_EXPORTS
#define MYDLL_API extern "C" __declspec(dllexport)
#else
#define MYDLL_API extern "C" __declspec(dllimport)
#endif
MYDLL_API void testFunction(void);
MYDLL_API LRESULT CALLBACK mouseProc(int nCode, WPARAM wParam, LPARAM lParam);
mydll.cpp
#include "stdafx.h"
#include "mydll.h"
// This is an example of an exported function.
MYDLL_API void testFunction(void)
{
MessageBox(NULL, (LPCWSTR)L"Test", (LPCWSTR)L"Test", MB_OK);
}
MYDLL_API LRESULT CALLBACK mouseProc(int nCode, WPARAM wParam, LPARAM lParam)
{
// processes the message
if(nCode >= 0)
{
if(wParam != NULL && wParam == MK_RBUTTON)
{
MessageBox(NULL, (LPCWSTR)L"Captured mouse right button", (LPCWSTR)L"Test", MB_OK);
}
}
// calls next hook in chain
return CallNextHookEx(NULL, nCode, wParam, lParam);
}
code from main.cpp
...
case WM_CREATE:
{
// creates state for window
stateClassPointer = new stateClass();
// saves states pointer in a space reserved for user data
SetWindowLongPtr(hWnd, GWLP_USERDATA, (LONG_PTR) stateClassPointer);
// now it will load DLL and set up hook procedure for mouse events
// declares local variables
HOOKPROC hkprcMouseProc;
HINSTANCE hinstDLL;
HHOOK hhookMouseProc;
//FARPROC WINAPI test;
// loads DLL
if((hinstDLL = LoadLibrary(TEXT("C:\\Users\\Francesco\\Dropbox\\poli\\bi\\not\\pds\\sp\\wk5\\lsp5\\Debug\\mydll.dll"))) == NULL)
{
MessageBox(hWnd, (LPCWSTR)L"Error loading DLL", (LPCWSTR)L"Error", MB_OK | MB_ICONERROR);
break;
}
// saves DLL handle in the state class
stateClassPointer->setHInstance(hinstDLL);
// sets up hook procedure for mouse events
if((hkprcMouseProc = (HOOKPROC)GetProcAddress(hinstDLL, "mouseProc")) == NULL)
{
MessageBox(hWnd, (LPCWSTR)L"Error setting windows hook: GetProcAddress", (LPCWSTR)L"Error", MB_OK | MB_ICONERROR);
break;
}
if((hhookMouseProc = SetWindowsHookEx(WH_MOUSE, hkprcMouseProc, hinstDLL, 0)) == NULL)
{
MessageBox(hWnd, (LPCWSTR)L"Error setting windows hook: SetWindowsHookEx", (LPCWSTR)L"Error", MB_OK | MB_ICONERROR);
break;
}
// saves hook handle in the state class
stateClassPointer->setHHook(hhookMouseProc);
/*test = GetProcAddress(hinstDLL, "testFunction");
test();*/
}
break;
...
Yes, the MessageBox() call succeeded without errors. Move the GetLastError() call before it.
The error is otherwise predictable, it couldn't find "mouseProc". The name will be mangled in the DLL, most probably "_mouseProc#12". Use dumpbin.exe /exports on your DLL to be sure.
Fwiw: you can make this code less painful by not dynamically loading the DLL but just linking its import library. The fact that the DLL will be injected into other processes doesn't also mean you have to inject it in yours. All you need is the module handle so you can call SetWindowsHookEx(). Get that from the DllMain() entry point or by using GetModuleHandle().
I'm trying a little concept test to change one of the features of the logitech MS3200 keyboard (the zoom feature). I've got the keys that are sent from the zoom control. So, I have a main app, and a dll that contains a hook procedure.
Here's the main app:
#include <stdio.h>
#include <windows.h>
HANDLE hHook;
int main()
{
HINSTANCE hMod = GetModuleHandle(NULL);
hHook = SetWindowsHookEx(WH_KEYBOARD, HookProc,0,0);
if(hHook == NULL)
printf("Unable to set hook! Error: %d", GetLastError());
else
printf("Hook set successfully!");
while(TRUE)
{
Sleep(1000);
}
return 0;
}
And here is the hook procedure dll:
#include <windows.h>
int __declspec (dllexport) HookProc(int nCode, WPARAM wParam, LPARAM lParam)
{
if(nCode < 0)
{
return CallNextHookEx(hHook, nCode, wParam, lParam);
}
if(wParam == VK_ADD || wParam == VK_SUBTRACT)
{
short status = GetKeyState(VK_CONTROL);
if(status == 1)
{
if(wParam == VK_ADD)
wParam = VK_UP;
else
wParam = VK_DOWN;
}
}
return CallNextHookEx(hHook, nCode, wParam, lParam);
}
int WINAPI dllmain(HINSTANCE hMod, DWORD data, LPVOID lpVOid)
{
return 0;
}
I need to be able to access what's returned by SetWindowsHookEx (hHook) from the dll, in order to call CallNextHookEx().
It's probably possible, but it's not worth your time to investigate.
Instead, move the hook setting code to the DLL.
Oh, and I think you need to pass the DLL module handle to the hook setting function, not a NULL
One possible way to handle this would be to have another exported function in your DLL to pass the hHook to, and save that in a variable local within the DLL for use in the HookProc.
HANDLE dllHook;
void __declspec (dllexport) HookHandle(HANDLE hHook)
{
dllHook = hHook;
}
int __declspec (dllexport) HookProc(int nCode, WPARAM wParam, LPARAM lParam)
{
if(nCode < 0 && dllHook!= NULL)
{
return CallNextHookEx(dllHook, nCode, wParam, lParam);
}
//....
}
int WINAPI dllmain(HINSTANCE hMod, DWORD data, LPVOID lpVOid)
{
dllHook = NULL; //initialize
return 0;
}
Code in a DLL can't directly access variables in the calling app, because there's no guarantee that the app that loads the DLL will have those variables defined, and even if it did, the DLL has no way to know where it would be stored.
You could have a global variable in the DLL and an extra entry point to set it, which you call after calling SetWindowsHookEx. The DLL would need to wait until this entry point is called before calling CallNextHookEx.
On NT/XP/2003 etc the first param to CallNextHookEx is ignored. See the documentation for CallNextHookEx:
http://msdn.microsoft.com/en-us/library/ms644974%28VS.85%29.aspx
hth