Create Button and Reference in message map - c++

Im creating a button on my oncreate using message map.
I am unable to get a callback message from ON_BN_CLICKED when passing a reference to ICL_OK.
I don't believe its a parenting issue. The window is an CFrameWnd and parent is a CMainFrame.
Even getting all the messages and I can swtich between what I want to do as I have list boxes and input boxes to add also and edit / get response.
Thanks
Cant go into the gui main thread loop. Message map is the way I need to achieve this.
okBtn.Create(_T("Ok Button"), WS_TABSTOP | WS_VISIBLE | WS_CHILD | BS_DEFPUSHBUTTON,
CRect(10, 10, BUTTON_WIDTH, HEIGHT), this, ICL_OK);
To click the button and get a response. Instead in using OnCmdMsg and getting a reference to its nID which I don't like. I want BN_CLICKED to work.
Refering to this answer
Message map macros
I can again confirm oncmdmsg works but wm_command event does not fire.
Message map macros
UPDATE: Still not working, alternative is to use ON_COMMAND_RANGE and still fires the WM_COMMAND so just have to restrict the amount of messages it handles. Hope it helps someone. If you want to generate a button the solution below might help you.

You are writing that the button is not showing in the window. There is a reason for that, and I would guess this: You define the button in a subroutine/method/function instead of defining it in its parent class.
Instead, in its parent class, whether that is the CMainFrame or some other Window, define a button like:
class CMainFrame : public CFrameWnd
{
/// bunch of stuff, including OnCreate() or OnCreateClient()
CButton m_button;
};
In the class that houses the button, assuming CMainFrame for now, create the button... ideally in OnCreate() or OnCreateClient()
call the baseclass version then your button create....
int CMainFrame::OnCreate(LPCREATESTRUCT lpcs)
{
int ret = __super::OnCreate(lpcs);
if (ret != -1) {
m_button.Create(_T("Ok Button"), WS_TABSTOP | WS_VISIBLE | WS_CHILD | BS_DEFPUSHBUTTON, CRect(10, 10, BUTTON_WIDTH, HEIGHT), this, ICL_OK);
}
return ret;
}
If your constructor is in a method, then its destructor will be called at the end of the method. MFC CWnd derived windows classes usually call DestroyWindow() in their destructor and what this means is that the window is destroyed by the end of the call and that is the reason it is not visible.

Related

How to set control focus inside an MFC custom control

Experts!
I am using a class that inherits CWnd to make the content visible using a horizontal scroll bar
The control I want to create looks like this:
However, I have some problems and leave a question
When the button receives focus, it changes to blue. If another button is pressed, the button that received the existing focus should be unfocused.
The button does not release focus as shown in the second picture.
However, the above problem occurs when implemented in Dialog, not in SDI.
I need help solving this problem.
Custom Control Create Code;
m_ScrollWnd.Create(WS_CHILD | WS_VISIBLE, CRect(0, 0, 0, 0), this, 1234);
BOOL CScrollWnd::Create(DWORD dwStyle, CRect &rect, CWnd *pParent, UINT nID)
{
dwStyle |= ((WS_HSCROLL) );
return CWnd::Create(CScrollWnd::IID, nullptr, dwStyle, rect, pParent, nID);
}
m_Button3.Create(_T("Hello3"), WS_CHILD | WS_VISIBLE | BS_PUSHBUTTON, CRect(0, 0, 0, 0), this, 1238);
The so called "default button handling" is done by a function named IsDialogMessage.
The easiest way to control this is to make your parent control a window derived from CDialog, or if it's a view derive from CFormView. The MFC will handle all this for you in the appropriate PreTranslateMessage handler.
If you want to do this by your own you might insert your own PreTranslateMessage handler and use IsDialogMessage. The CWnd class also has a predefined implementation named CWnd::PreTranslateInput.
So this might be sufficient:
BOOL CYourParentClass::PreTranslateMessage(MSG* pMsg)
{
// allow standard processing
if (__super::PreTranslateMessage(pMsg))
return TRUE;
return PreTranslateInput(pMsg);
}
Using CFormView / CDialog is the better way from my point of view, because also other "problematic things about dialogs" are solved in it. Including loosing and getting focus and activation...
Official document from MSDN: Dialog Box Keyboard Interface
BTW, xMRi explains it very well.

Create toolbar with event in MFC

Hi I'm having a problem with my single-document MFC application.
I want to add my own toolbar to MainFrm class (CFrameWnd).
I am a total newb with MFC. So I'm not sure that's even the place to add it.
So far:
A toolbar resource with id IDR_TOOLBAR1 is created
A toolbarbutton with id ID_SELECT_SHAPE
In MainFrm.h is CToolBar m_wndMyToolBar; declared
In MainFrm.cpp:
if (!m_wndMyToolBar.CreateEx(this, TBSTYLE_FLAT, WS_CHILD | WS_VISIBLE | CBRS_TOP | CBRS_GRIPPER | CBRS_TOOLTIPS | CBRS_FLYBY | CBRS_SIZE_DYNAMIC) ||
!m_wndMyToolBar.LoadToolBar(IDR_TOOLBAR1))
{
TRACE0("Failed to create toolbar\n");
return -1; // fail to create
}
The toolbar is showing now. YAY!
But I don't know how to add the event handler.
Somebody who can tell if I'm on the right track? And if so, who can tell how to add that event?
Yes, you are on the right track. Your MainFrame.cpp should have a section that starts with
BEGIN_MESSAGE_MAP
and ends with
END_MESSAGE_MAP
Inside that section, you will need an entry
ON_COMMAND (ID_SELECT_SHAPE, &CFrameWnd::OnSelectShape)
In your .h file add a declaration
afx_msg void OnSelectShape();
and in the .cpp file implement the OnSelectShape function to handle your event.
Depending on what your handler needs to do and what data it needs to have, it may be easier to add the handler and implement it in the CView... class instead of the CFrameWnd class. Handlers can also be implemented in the CDocument... class. When the toolbar button is clicked, the MFC Doc-View framework will first look for a handler in the View. If there is no handler available, it then looks for one in the Document, and finally if there is not a handler there it will look for one in the main Frame window.

How to show a window before processing in MFC

How can I get a window visible before processing?
I'm trying to do something like this:
void CMyClass::OnButton1Clicked()
{
CString class_str = AfxRegisterWndClass(CS_VREDRAW | CS_HREDRAW, ::LoadCursor(NULL,IDC_ARROW),(HBRUSH)::GetStockObject(WHITE_BRUSH),::LoadIcon(NULL, IDI_APPLICATION));
CWnd* wnd = new CWnd();
wnd->Create(class_str,"Test",WS_CHILD | WS_VISIBLE | WS_BORDER, CRect(0,0,100,100), AfxGetMainWnd(), 1432);
//AfxMessageBox("test"); // <- if this is executed wnd gets visible before sleep()
Sleep(5000); //this would be processing
wnd->DestroyWindow();
delete wnd;
return;
}
The window doesn't show at all. I've tried displaying it in an UI thread but it doesn't show either. If I do a message loop until window is created, it shows up but after a while the main message loop asserts.
I know it shouldn't be made like this but rather processing in worker thread, but with current code I'm working with it would require changes too big.
Disclaimer: I don't know MFC, but I know the windows API, which is what MFC was built on top of.
Perhaps you need to make a call to ShowWindow(). Also, are you handling the WM_CREATE message? If so, perhaps you are returning the wrong value.
If the above doesn't apply or make sense, disregard.

create a control programmatically using MFC

I just wonder how to do it.
I write :
CEdit m_wndEdit;
and in the button event handler (dialog app),
I write :
m_wndEdit.Create(//with params);
but I still don't see the control appear in the UI.
I actually wrote this in the button handler :
CWnd* pWnd = GetDlgItem(IDC_LIST1);
CRect rect;
pWnd->GetClientRect(&rect);
//pWnd->CalcWindowRect(rect,CWnd::adjustBorder);
wnd_Edit.Create(ES_MULTILINE | ES_NOHIDESEL | ES_READONLY,rect,this,105);
wnd_Edit.ShowWindow(SW_SHOW);
this->Invalidate();
id 105 doesn't exist. (I used it in the Create member function of CEdit). I just put it in there. isn't it supposed to be the id you want to give to the new control ? Should it already exist ?
Check with the following set of flags as the example mentioned in MSDN:
pEdit->Create(ES_MULTILINE | WS_CHILD | WS_VISIBLE | WS_TABSTOP | WS_BORDER | ES_NOHIDESEL | ES_READONLY,
rect, this, 105);
The Invalidate() is not necessary
Add the WS_VISIBLE flag to your create flags, you don't need the ShowWindow
You are creating the button on the location where IDC_LIST1 is - you probably want to do pWdn->Destroy() after the GetClientRect()
The id you pass to Create() can be anything, of course if you want to handle messages from this button later you'll need to use the correct id. In that case it's easiest to manually add an entry to resource.h.
What do you mean with 'I put this code in the button event handler' - which button? A different one from the one you're trying to create, I may hope? Does your code get called at all, does it stop when you put a breakpoint in? What's the value of wnd_Edit->m_hWnd after the call to Create()?
wnd_Edit is a member of your dialog, right, and not a a function local variable?
What is wnd_Edit exactly? If it's a local variable in that function, that is likely the problem. The CWnd destructor destroys the window associated with the CWnd. So when wnd_Edit goes out of scope, the edit box is destroyed too.
If that's not it, check the return value of Create(). Is it NULL? If it is, check the value of GetLastError().

QWinWidget Inside MFC Dialog Not Repainting or Responding to Tab/Arrow keys

I am using a QWinWidget inside of an MFC dialog and the QWinWidget is not drawing itself correctly and it is not handling keyboard input correctly.
Repainting [Unsolved]
Within the QWinWidget, I have a QTableWidget. When I scroll the QTableWidget, it does not redraw itself until I stop scrolling, at which point it redraws everything. Similarly, I can type into cells in the QTableWidget and the control is not updated until I force it to re-update by scrolling up or down (it re-updates when the scrolling stops).
Since this QWinWidget is housed in an MFC CDialog, I tried overriding the CDialog's OnPaint method and only call the QWinWidget::repaint method, however this has the opposite problem where now only the QWinWidget is updated and the CDialog is never redrawn, resulting in artifacts. If I call QWinWidget::repaint and CDialog::OnPaint, the result is the same as not overriding the OnPaint method. Has anyone ever seen this problem or know how to resolve it?
Keyboard Input [Solved]
None of the controls within the QWinWidget respond to the tab key or arrow keys correctly. The tab/arrow keys simply skip over the entire QWinWidget (and all child controls). Even if I click inside the QWinWidget and select a control, the next time I press the tab key, it skips the focus completely out of the entire QWinWidget.
I noticed that the QWinWidget has two functions, QWinWidget::focusNextPrevChild and QWinWidget::focusInEvent and both of them have a comment header saying "\reimp". Am I supposed to override these functions in order to get correct tab functionality? If so, how can these functions be implemented for correct tab functionality.
I have fixed the keyboard input issue. The QWinWidget class needed some changes:
in the QWinWidget::init method, the WS_TABSTOP must be added to the window style:
SetWindowLong(winId(), GWL_STYLE, WS_CHILD | WS_CLIPCHILDREN | WS_CLIPSIBLINGS | WS_TABSTOP);
Also, the QWinWidget::winEvent method needs to respond to the WM_GETDLGCODE to let Windows know that it is interested in receiving key/tab inputs. I had to add this if block:
if(msg->message == WM_GETDLGCODE)
{
*result = DLGC_WANTARROWS | DLGC_WANTTAB;
return(true);
}
I am still working on getting the widget to paint properly.
I don't know about whether you need to reimplement the focusNextPrevChild() and focusInEvent() functions, but I do know that the "\reimp" in the comment header is part of Qt's documentation generation, which merely specifies that the function was a reimplementation of another function in a parent class.
Thanks! It works for me! I have fixed an arrow keys navigation issue for a QTableView inside a QWinWidget.
I am using Qt5.3.0 and qtwinmigrate 2.8.
The QWinWidget::nativeEvent method needs to be modified.
#if QT_VERSION >= 0x050000
bool QWinWidget::nativeEvent(const QByteArray &, void *message, long *result)
#else
...
{
...
if (msg->message == WM_SETFOCUS) {
...
} else if (msg->message == WM_GETDLGCODE) {
*result = DLGC_WANTALLKEYS;
return true;
}
return false;
}
No idea about the keyboard input, but concerning the repainting: have you tried calling QWinWidget::repaint() in the CDialog's OnPaint method AFTER calling the CDialog::OnPaint()?