anyone can tell me how to use a bitmap as a button, actually i can create a static control and could set a picture to it but the thing is that i don't know how to use it as a button, i am using c++ win32.
This is how i create the bitmap
Code:
HWND Profile_Stuff(HWND hWnd, HINSTANCE hInst)
{
HWND Profile_Pic;
Profile_Pic = CreateWindow("STATIC", NULL, SS_BITMAP|WS_CHILD|WS_VISIBLE|WS_TABSTOP|WS_BORDER, 5,5,33,33, hWnd, NULL, hInst, NULL);
HBITMAP hBmp = (HBITMAP)LoadImage(NULL, "camera1.jpg", IMAGE_BITMAP,0,0,LR_LOADFROMFILE);
if(hBmp == NULL){
MessageBox(NULL, "Error while loading image", "Error", MB_OK|MB_ICONERROR);
}
SendMessage(Profile_Pic, STM_SETIMAGE, (WPARAM)IMAGE_BITMAP, (LPARAM)hBmp);
return 0;
}
then i call the function in main window wm_create message handler which creates it successfully, now i don't know to use it as a button, like we have a picture of an advertisement at the bottom of bit torrent application.
i am using visual studio c++ with win32 api.
If you want a button control, you should create a button control. The visual representation can be controlled by the application. To do so, specify the BS_OWNERDRAW Button Style. A button control with this style sends a WM_DRAWITEM message to the control parent whenever a visual aspect has changed. The control parent can then render the control as it sees fit.
An introduction to owner-drawn controls is available at Custom Controls. If you wish to retain some parts of the button control (e.g. its border), see Using Visual Styles with Custom and Owner-Drawn Controls for details (or DrawFrameControl if you aren't using Visual Styles).
Fully working sample code for an owner-drawn button control can be found in this answer.
In Windows, the windows belong to a class, a the class defines the windows procedure for all windows of that class, meaning how they react to events.
If you create a STATIC window, it will not react to any click and will not be useable as a button.
You could create a custom class, register it along with a custom windows procedure able to mimic a BUTTON. But unless you have very special requirements just create an owner drawn button as shown in #IInspectable's answer
Related
Im trying to open a Dialog box in Windows machine(using windows credential provider), when the user presses a button. i tried the below code but, dialog box is not getting opened. i have a resource "IDD_DIALOG1" and callback method "ChangePasswordProc".
HWND hwndOwner = nullptr;
::DialogBox(HINST_THISDLL, MAKEINTRESOURCE(IDD_DIALOG1), hwndOwner,ChangePasswordProc);
I didn't write in Windows GUI for a looong time, but perhaps try something like this:
HWND dialog = ::DialogBox(HINST_THISDLL, MAKEINTRESOURCE(IDD_DIALOG1), hwndOwner,ChangePasswordProc);
ShowWindow(dialog, SW_SHOW);
I remember, that creating window does not imply showing it - it must be done explicitly.
To create any window from inside of Credential Provider you must first get parent window handle by calling OnCreatingWindow method of ICredentialProviderCredentialEvents interface.
HRESULT OnCreatingWindow([out] HWND* phwndOwner);
Pointer to this interface is supplying to your provider by calling Advise method of its ICredentialProviderCredential interface :
HRESULT Advise([in] ICredentialProviderCredentialEvents* pcpce);
Have a look at this post.
I have the process name and the handle (HWND) of its window. I want now to get the relative icon (if available). Searching through MSDN, I found ExtractIcon() to get the handle to the icon from a given exe name, and GetIconInfo() to get "information" of the icon from the HICON. I don't know if it's the right way to do this, and how to retrieve correct information to show (in a second moment) the icon without the handle to the icon.I have to send this information to another process (through socket) that has to show the icon.In the ICONINFO structure there are HBITMAP fields that contains the bitmap (black&white and with colour). Is it useful?
you can use the API GetClassLong to retrieve the icon associated with your program then use SendMessage API passing the hwnd of of the window you want to change it's icon.
in this Example I extracted the icon from my application then set it to Calculator. my windows calculator is open before sending to it the icon:
case WM_LBUTTONDOWN: // just for explanation so left clicking in your client area and see the result
{
HICON icon = (HICON)GetClassLong(hWnd, GCL_HICON);
HWND hCons = FindWindow(NULL, "Calculator"); // I already opened windows calculator. you can use any other window but be sure to get its valid Handle
if(!hCons)
MessageBox(0, "\"Calculator\" windows is not found!", 0, MB_OK|MB_ICONHAND);
SendMessage(hCons, WM_SETICON, (WPARAM)ICON_BIG, (LPARAM)icon); // setting the icon
}
break;
Is there a way to programmatically hide an application on windows? I want to achieve the same thing as the windows+D shortcut, but for a single application. I want to do this from within that application (application consists of several windows, one of those can't be moved, resized, closed or minimized by the user). Application is written in c++ and uses Qt for the UI.
to do so it's so easy:
1- retrieve the handle to that window:
HWND hChild = GetDlgItem(hWnd, ID_MYCHILD);
2- send to it SW_SHOW either using ShowWindow or via SendMessage:
ShowWindow(hChild, SW_HIDE); // hide
ShowWindow(hChild, SW_SHOW); // show
SendMessage(hChild, SW_HIDE, 0, 0); // hide
SendMessage(hChild, SW_SHOW, 0, 0); // show
if the window doesn't belong to your application then:
1 - retrieve the main window with:
HWND hWnd = GetForegroundWindow(void);
2- use the above to hide/show it
ShowWindow(HwndWindow, SW_MINIMIZE);
Here's the MSDN ShowWindow documentation.
In addition you may find EnumChildWindows useful for finding all these windows if their handles aren't readily available to you.
How can I arrange dialogs programmatically in MFC in cascade format, other than simply using SetWindowPos based upon the position of the previously displayed window?
The Dialog position is to be loaded from the registry in my app, so we use:
SetWindowPos(NULL,x,y,cx,cy,SWP_NOZORDER);
...for the dialog. After that if we use the CascadeWindows function it doesn't seem to work for this Dialog, though it works for other dialogs in the same parent window. It seems the CascadeWindows function has no effect on windows that have called SetWindowPos; can anybody please confirm?
If so, do we have to use only SetWindowPos to arrange the dialog's cascade, or is there another way?
Check if your dialog is having window style: WS_EX_TOOLWINDOW or WS_EX_TOPMOST. CascadeWindows will not arrange windows with that styles.
I tried an MFC sample dialog based application with the following code:
void CTestCascadeDlg::OnBnClickedOk()
{
this->SetWindowPos( NULL, 100,100,500,500, SWP_NOZORDER );
CascadeWindows( NULL, MDITILE_ZORDER, NULL, NULL, NULL );
}
And I could observe that my dialog was cascaded successfully.
So, I am a total beginner in any kind of Windows related programming. I have been playing around with the Windows API and came across a couple of examples on how to initialize create windows and such.
One example creates a regular window (I abbreviated some of the code):
int WINAPI WinMain( [...] )
{
[...]
// Windows Class setup
wndClass.cbSize = sizeof( wndClass );
wndClass.style = CS_HREDRAW | CS_VREDRAW;
[...]
// Register class
RegisterClassEx( &wndClass );
// Create window
hWnd = CreateWindow( szAppName, "Win32 App",
WS_OVERLAPPEDWINDOW,
0, 0, 512, 384,
NULL, NULL, hInstance, NULL );
[...]
}
The second example creates a dialog box (no abbreviations except the WinMain arguments):
int WINAPI WinMain( [...] )
{
// Create dialog box
DialogBox(hInstance,
MAKEINTRESOURCE(IDD_MAIN_DLG),
NULL,
(DLGPROC)DialogProc);
}
The second example does not contain any call to the register function. It just creates the DialogBox with its DialogProc process attached.
This works fine, but I am wondering if there is a benefit of registering the window class and then creating the dialog box (if this is at all possible).
You do not have to register a dialog box.
Dialog boxes are predefined so (as you noted) there is no reference to a window class when you create a dialog. If you want more control of a dialog (like you get when you create your own window class) you would subclass the dialog which is a method by which you replace the dialogs window procedure with your own. When your procedure is called you modify the behavior of the dialog window; you then might or might not call the original window procedure depending upon what you're trying to do.
It's been a while since I've done this, but IIRC, the first case is for creating a dialog dynamically, from an in-memory template. The second example is for the far more common case of creating a dialog using a resource. The dynamic dialog stuff in Win32 was fairly complex, but it allowed you to create a true data-driven interface, and avoid issues with bundling resources with DLLs.
As for why use Win32 - if you need a windows app and you don't want to depend on MFC or the .NET runtime, then that's what you use.