Switch between edit controls using Tab? - c++

The Window is non DialogBox based so WS_TABSTOP doesn't work. Moreover I don't want to Tab through all the controls, I just want to Tab through few Edit controls.
What I did is I superclassed the Edit control and handled the WM_KEYDOWN message, switching between edit controls, by getting next window in the line thorugh ::GetWindow(hwnd,GW_HWNDNEXT); Also I would like to switch focus back to the first Edit control when I have reached the last one.
The Code doesn't work for when I have reached the last Edit control, the ::GetWindow simply returns the next window in the line(?), which happens to be a non superclassed edit control. And there are more hidden child windows(SW_HIDE).
Maybe if I know how to know the class name of the window's HWND ?
Note: Pure Win32 api, c++ oop.
else if ( ( int ) wParam == VK_TAB )
{
HWND nextInLine;
nextInLine = ::GetWindow ( hwnd, GW_HWNDNEXT );
if ( hwnd == NULL ) nextInLine = ::GetWindow ( hwnd, GW_HWNDPREV );
::SendMessage ( nextInLine, EM_SETSEL, ( WPARAM ) 0, ( LPARAM ) -1 );
::SetFocus ( nextInLine );
return 0;
}

You get keyboard navigation for free in any window by using the IsDialogMessage API call. To consume the service a window message loop has to be modified to include a call to IsDialogMessage and only pass the message on to regular message handling if it hasn't been handled by the dialog manager already.
MSG msg = { 0 };
while (GetMessage(&msg, NULL, 0, 0)) {
if (IsDialogMessage(hwnd, &msg)) {
/* Already handled by dialog manager */
} else {
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
Don't forget to set the WS_EX_CONTROLPARENT extended window style on the parent window, so that the dialog manager recurses into child windows.

It's possible to get away with just calling IsDialogMessage, but the result isn't quite 100% dialog-like. To make an ordinary window behave like a dialog:
Specify DLGWINDOWEXTRA as the cbWndExtra field of your WNDCLASS (don't forget to add on extra space you might already be using and offset your data's indexes)
Call DefDlgProc rather than DefWindowProc
Since this makes your window a dialog, you need to use the DWLP_USER window long instead of GWLP_USERDATA, if you're using that, when calling GetWindowLongPtr or SetWindowLongPtr.
(From memory, the main thing you get from doing the above is support for WM_NEXTDLGCTL, which I've found useful to use for supporting changing focus using the Enter key, using Method I described in http://support.microsoft.com/kb/102589.)
Then in your message pump, call IsDialogMessage for each dialog-like window in your message pump.
Finally, when creating controls for your dialog-like window, set the WS_TABSTOP window style for each window you want to participate in the tabbing, and set the WS_EX_CONTROLPARENT window exstyle (aka Control Parent in the resource editor) for child windows that contain dialog controls.

Related

Can't show/hide buttons in the main window of my C++ Win32 app [duplicate]

This question already has answers here:
Access a variable from a different switch case (from WM_CREATE to WM_CTLCOLORSTATIC in the WinApi)
(2 answers)
Closed last month.
I have created a basic button in case: WM_CREATE in the windows procedure with the following.
/*The "new_game_button" is declared as type HWND at the
start of the windows procedure function but not initialized.*/
new_game_button = CreateWindow ( "BUTTON", "New Game",
WS_CHILD | WS_BORDER ,
50, 50, 100, 100,
hwnd, NULL, NULL, NULL);
My intent is to create an instructions and "start new game" button as the first thing in my simple tictactoe app. It will immediately show as expected if I give the parameter WS_VISIBLE.
Further in the same case:WM_CREATE if I use the lines
if (!start_Game){ //global variable default is false
ShowWindow( new_game_button, SW_SHOW);
}
The button will show as expected.
Outside of those two cases I cannot get the button to show at a later stage.
Further, if I use one of those two methods to show the button I can never get it to go away using
ShowWindow ( new_game_button, SW_HIDE);
Once the button is showing, it stays for the duration of the programs execution. Doesn't matter which case. Command/Create/Paint
I have tried using
if (start_Game){
ShowWindow( new_game_button, SW_HIDE);
UpdateWindow ( new_game_button );
//UpdateWindow ( hwnd ); tried this as well
}
inside case WM_CREATE.
I have also tried the same SW_HIDE line inside case: WM_COMMAND where a new game is generated (compiles but doesn't hide the button.)
I have tried declaring the button child window outside the WM_CREATE inside the windows procedure function. Then using WM_CREATE to show the window - works -- still WM_COMMAND will not hide the window.
I have also tried creating the button window inside of case:WM_PAINT which works to show the button but not to get rid of it. I have even tried DestroyWindow which just fails. [returns 0]
In trying to understand the behaviour of the button window - I have found that I cannot get
ShowWindow( new_game_button, SW_SHOW);
to work in the case:WM_COMMAND.
You said (in a code comment in the question).
new_game_button is declared as type HWND at the start of the windows procedure function but not initialized.
Each incoming message means a new call to your window procedure. Variables which are local to a function don't retain their value between calls unless they are marked static.
When your window procedure returned from processing WM_CREATE, you lost the value of new_game_button. When you try to use it during WM_COMMAND processing later, it is uninitialized and your program causes undefined behavior by passing it to ShowWindow.
Every comment helped me solve this which I appreciate. I am too new to give reputation sadly.
case WM_CREATE:
{
new_game_button = CreateWindow ("BUTTON", "New Game",
WS_CHILD | WS_BORDER ,
50, 50, 100, 100,
hwnd, (HMENU) 1, NULL, NULL);
if (!start_Game){
ShowWindow( new_game_button, SW_SHOW);
}
}
break;
After I had an ID for the dialog I am able to use GetDlgItem function to show or hide as I please.
new_game_button = GetDlgItem (hwnd, 1);
ShowWindow( new_game_button, SW_HIDE);

Making TAB key work in my win32 app

I want to make the tab button work on my app , so when I press tab, it will change from one edit box to another, these are the edit box codes:
case WM_CREATE:
TextBox = CreateWindow("EDIT",
"",
WS_BORDER|WS_CHILD|WS_VISIBLE|WS_EX_LAYERED|WS_TABSTOP|WS_GROUP,
60,50,200,20,
hwnd,NULL,NULL,NULL);
DataBox = CreateWindow("EDIT",
"",
WS_BORDER|WS_CHILD|WS_VISIBLE|WS_TABSTOP|WS_GROUP,
60,72,200,20,
hwnd,NULL,NULL,NULL);
MotivBox = CreateWindow("EDIT",
"",
WS_BORDER|WS_CHILD|WS_VISIBLE|WS_TABSTOP|WS_GROUP,
60,92,200,20,
hwnd,NULL,NULL,NULL);
PretBox = CreateWindow("EDIT",
"",
WS_BORDER|WS_CHILD|WS_VISIBLE|WS_TABSTOP|WS_GROUP,
60,112,200,20,
hwnd,NULL,NULL,NULL);
The fix is quite simple. Given the fact you're handling the WM_CREATE message, rather than the WM_INITDIALOG message, it seems safe to assume that you're adding the controls to a 'standard' window, rather than a 'dialog'.
With that in mind, I expect you've got something like the following in your winmain:
/* Run the message loop. It will run until GetMessage() returns 0 */
while (GetMessage (&messages, NULL, 0, 0))
{
/* Translate virtual-key messages into character messages */
TranslateMessage(&messages);
/* Send message to WindowProcedure */
DispatchMessage(&messages);
}
However, the documentation for IsDialogMessage states:
"Although the IsDialogMessage function is intended for modeless dialog boxes, you can use it with any window that contains controls, enabling the windows to provide the same keyboard selection as is used in a dialog box.
When IsDialogMessage processes a message, it checks for keyboard messages and converts them into selection commands for the corresponding dialog box. For example, the TAB key, when pressed, selects the next control or group of controls, and the DOWN ARROW key, when pressed, selects the next control in a group.
Because the IsDialogMessage function performs all necessary translating and dispatching of messages, a message processed by IsDialogMessage must not be passed to the TranslateMessage or DispatchMessage function."
So, you can change your message pump to resemble the following:
/* Run the message loop. It will run until GetMessage() returns 0 */
while (GetMessage (&messages, NULL, 0, 0))
{
/* Translate virtual-key messages into character messages */
if (IsDialogMessage(hwnd, &messages) == 0)
{
TranslateMessage(&messages);
/* Send message to WindowProcedure */
DispatchMessage(&messages);
}
}
As far as I remember, you should use WS_GROUP only on the first entry. All following childwindows will be added to this group. When you create a new group, you use WS_GROUP again on the first window being created.
So keep the WS_GROUP on TextBox and remove it form the other windows.
You can read about this here on MSDN.
You also should use the IsDialogMessage in your message loop. You can see an example here.
I had a similar problem and found adding the IsDialogMessage statement before TramnslateMessage and DispatchMessage (as shown in the accepted answer) fixed my problem.

Flickering using WM_DRAWITEM

It seems like I can't get pass this issue with owner-draw controls. I've super-classed a status control. I am trying to customize but still retain the same functionality. Basically, I want to change the background and text. I'm using Direct2d (or ID2D1DCRenderTarget interface) for the drawing. I have successful changed the background by using WM_NCPAINT; although, you can use WM_ERASEBKGRND if you want. However, both methods acted as a control in my experiment and flickering still occurred. Moreover, flickering doesn't occur when the WPARAM of SB_SETTEXT is NOT SET to SBT_OWNERDRAW. Therefore, I came to a conclusion that WM_DRAWITEM is the culprit. Is there anyway I can fix this flickering issue with owner-draw statusbar?
You can avoid flickering if you turn on double buffering for you control.
Set the WS_EX_COMPOSITED extended style:
http://msdn.microsoft.com/en-us/library/windows/desktop/ff700543(v=vs.85).aspx
e.g. when handling WM_CREATE, call (WTL or MFC):
ModifyStyleEx(0, WS_EX_COMPOSITED);
Well, seems like I figured it out. When super-classing a status-bar follow these sets to avoid flickering.
**Note: This has only been tested with visual styles turned off. SetWindowTheme(hWndStatus, L"", L"");
Also, the parent window must have WS_CLIPCHILDREN set in the style parameter during window creation.
1: Override WM_SIZE. Make a call to InvalidateRect(m_hWnd, NULL, TRUE) and return 0 unless you want the default sizing; in this case, call CallWindowProc.
2: Override WM_ERASEBKGND and return -1.
3: Override WM_NCPAINT and place your drawing code here.
Handling WM_NCPAINT. People seem to have trouble understanding how to handle WM_NCPAINT. Here is how I do it.
if (wParam == 1) {
hdc = GetWindowDC(m_hWnd);
} else {
hdc = GetDCEx(m_hWnd, (HRGN) wParam, DCX_WINDOW | DCX_INTERSECTRGN | DCX_CACHE);
}
Then do drawing with the DC.
4: In the parent procedure (WndProc or whatever) call SetWindowPos(..., SWP_DRAWFRAME) with the handle to the statusbar. This will resize your statusbar.
5: Send a message via SendMessage(hWndStatusbar, SB_SETPARTS, 1, (LPARAM) &parts);
6: Send a message via SendMessage(hWndStatusbar, SB_SETTEXT, LOBYTE(0) | SBT_OWNERDRAW, L"Ready"). Sample code for WM_DRAWITEM:
...
WM_DRAWITEM:
LPDRAWITEMSTRUCT lpDIS = (LPDRAWITEMSTRUCT) lParam;
m_pFramework->m_pD2D1RenderTarget->BindDC(lpDIS->hDC, &lpDIS->rcItem);
m_pFramework->m_pD2D1RenderTarget->BeginDraw();
m_pFramework->m_pD2D1RenderTarget->Clear(D2D1::ColorF(D2D1::ColorF::CadetBlue));
D2D1_RECT_F rf = D2D1::RectF(
PixeltoDipX(lpDIS->rcItem.left),
PixeltoDipY(lpDIS->rcItem.top),
PixeltoDipX(lpDIS->rcItem.right),
PixeltoDipY(lpDIS->rcItem.bottom)
);
m_pFramework->m_pD2D1RenderTarget->DrawText(
(LPCWSTR) lpDIS->itemData,
wcslen((WCHAR*) lpDIS->itemData) + 1,
m_pFramework->m_pTextFormat,
rf,
m_d2dCaptionTextColor
);
m_pFramework->m_pD2D1RenderTarget->EndDraw();
break;
....
This should stop flickering. Also, do not call InvalidateRect(hWndStatus, NULL, TRUE) in the parent's WM_SIZE. This was the main reason it flickered.

How do I use Dialog resources in Win32?

Without resources I can create my UI with a complex array of CreateWindow() and CreateWindowEx(), and WndProc() to process my events.
I noticed if I right-click in the resource view and click "add resource", I can draw a dialog box with all the controls. This would save me a huge amount of time if I could draw the interface like I normally do with C#.
After I've drawn the interface with the resource editor, how do I then create the window from code? Can someone provide a very simple example with a button, and show how to handle a WM_COMMAND event on that button please?
Also, is this generally how people create the GUI? Is there any loss in flexible to do this way? Even in C# I often have to supplement designer-generated UI with my own code-generated UI, but the majority of the time I'm quite happy to use designer.
After creating the dialog in the resource editor, call CreateDialog(modeless dialog;you need to dispatch the messages manually just like when you use CreateWindow) or DialogBox(modal dialog; the function does not return until you close the dialog. it does the dispatching for you) to make the dialog show up. Just like you pass in the window proc to RegisterClass, you pass the dialog proc to those functions for the dialog call back. An example of DialogProc looks likes this:
BOOL DialogProc( HWND hDlg, UINT iMessage, WPARAM wParam, LPARAM lParam ){
switch( iMessage ){
case WM_COMMAND:
switch( LOWORD( wParam ) ){
case BTOK:
MessageBox( hDlg, "Hello, World!", NULL, NULL );
return TRUE;
break;
}
break;
}
return FALSE;
}
This is a basic way of creating a dialog. More sophisticated method would normally involve OOP, usually wrapping each resource( button, window, etc) as a C++ object or using MFC.
If you have placed your button or any control on some dialog, that control is already in created state. For handling the messages of these child controls on this dialog , you have to override OnCommand Method in the class which is implementing your dialog.
For Example:
//CDialog_ControlDlg is my Dialog class derived from CDialog
//IDC_BUTTON_SAMPLE is the ID of the button which was palced on the dialog in the resource Editor..
BOOL CDialog_ControlDlg::OnCommand(WPARAM wParam,LPARAM lparam){
int iNotiFicationMsg=HIWORD(wParam);//This is thenotification Msg from the child control
int iCommandId=LOWORD(wParam);//And Control ID of the Child control which caused that Msg
BOOL result=FALSE;
switch(iCommandId){
case IDC_BUTTON_SAMPLE:
if(iNotiFicationMsg==BN_CLICKED)
{
//Your Code for handling this type of Msg for this control..
}
break;
default:
{
//Specific Code;
}
return result;
}
}

Is it necessary to destroy a tooltip?

In my application I am handling the WM_HELP message and then creating a tooltip for a control using this method:
Taken from: http://msdn.microsoft.com/en-us/library/bb760252(v=vs.85).aspx
HWND CreateToolTip(int toolID, HWND hDlg, PTSTR pszText)
{
if (!toolID || !hDlg || !pszText)
{
return FALSE;
}
// Get the window of the tool.
HWND hwndTool = GetDlgItem(hDlg, toolID);
// Create the tooltip. g_hInst is the global instance handle.
HWND hwndTip = CreateWindowEx(NULL, TOOLTIPS_CLASS, NULL,
WS_POPUP |TTS_ALWAYSTIP | TTS_BALLOON,
CW_USEDEFAULT, CW_USEDEFAULT,
CW_USEDEFAULT, CW_USEDEFAULT,
hDlg, NULL,
g_hInst, NULL);
if (!hwndTool || !hwndTip)
{
return (HWND)NULL;
}
// Associate the tooltip with the tool.
TOOLINFO toolInfo = { 0 };
toolInfo.cbSize = sizeof(toolInfo);
toolInfo.hwnd = hDlg;
toolInfo.uFlags = TTF_IDISHWND | TTF_SUBCLASS;
toolInfo.uId = (UINT_PTR)hwndTool;
toolInfo.lpszText = pszText;
SendMessage(hwndTip, TTM_ADDTOOL, 0, (LPARAM)&toolInfo);
return hwndTip;
}
The tooltip vanishes as soon as I move my mouse pointer.
My questions are:
Is tooltip is destroyed or is it just hidden ?
If it is hidden then how to destroy it and when?
Thanks.
It's been a while since I've done any WinAPI programming but if my memory serves me...
The call to CreateWindowEx passes the hDlg as the hWndParent parameter meaning the dialog window is now the parent of the tooltip.
From the MSDN documentation on the DestroyWindow function it says:
If the specified window is a parent or owner window, DestroyWindow automatically destroys the associated child or owned windows when it destroys the parent or owner window. The function first destroys child or owned windows, and then it destroys the parent or owner window.
So you can assume your tooltip window will be destroyed eventually. Be careful if you are calling CreateToolTip in response to every WM_HELP message as you will end up with a number of tooltip windows hanging around in memory until your dialog is closed and DestroyWindow is finally called.
As vz0 pointed out you could create the tooltip once, hang on to the window handle, then show the tooltip in response to the help message rather than creating it again.
In your comment to vz0's answer you said:
there are multiple ways in which a tooltip goes awya. example: mouse move, timeout etc.
All of those only result in the window being hidden so the handle to the tooltip is still valid and can be redisplayed using ShowWindow.
For every CreateWindowEx call you need a matching DestroyWindow call.
As an alternative, instead of creating and destroying the window every time you can use the ShowWindow call with SW_SHOW and SW_HIDE to show and hide the popup.
In my experience, I had to DestroyWindow() on the tooltip so an HFONT (font GDI resource) was properly released. There was a parent-child bond of the two windows at one time - but my system changes this at run-time and could be to blame. Probably no harm in doing it if your system generalizes it.