I have a CMFCToolBarComboBoxButton on a CMFCToolBar. I want that whenever the CMFCToolBarComboBoxButton gets the focus its entire text will be selected.
What is the most elegant way to implement it?
Thanks a lot!
Adi Barda
Not sure what the most elegant way is, but I guess the most common way to do this is to make a derived class and override OnSetFocus (exact method name not checked), and call SetCurSel() on the contained edit control. WM_FOCUS is only send to the control and there is no notification message for it afaik, so you'll have not many options besides doing something that will make the control handle the event - be it reflect it to somewhere else, or just implement the behavior itself. (I guess theoretically there's all sorts of finicking one can do with intercepting messages, but that's certainly not the most elegant way...)
That should be the default behavior of the standard edit control. If it's not, something else is removing that behavior explicitly. Maybe you can find some flag you can set on the combobox button?
If not: subclass the edit control, handle the WM_GETDLGCODE message. Return a value ORed with DLGC_HASSETSEL. If the control has this flag set, then Windows will automatically select all text on focus.
Related
How can I hide vtkOutputWindow? No suppress by
GlobalWarningDisplayOff() or redirect output to file but only
hide. (And show again after some time via something like vtkOutputWindow::GetInstance()->DisplayText(" ")). Thanks.
PS. I use Qt gui on Windows.
PPS. For those who are interested in this question I bring here mailing list correspondence (hiperlink not yet available):
Bel,Ok! Now I see what you meant. As you said, probably the easiest way to do that would be sending a close signal to the window.
As you can see on vtkWin32OutputWindow reference (https://www.vtk.org/doc/nightly/html/classvtkWin32OutputWindow.html) it is "a read only EDIT control", so if you could get its handle maybe you would be able to incorporate it to a window that you have control of.
Another, more complex, solution would be to create a new class that would inherit from vtkOutputWindow, based on vtkWin32OutputWindow but with controls to hide and show the control.
Best regards, Lucas Frucht Desenvolvimento
Lucas, thanks for reply. I don't need to "save changes" while vtkOutputWindow is hidden. In generally my question is about how to hide/show this window from gui in runtime. vtkOutputWindow class is not derived from any widget so it havn't any method like "hide" or "close". Also destroy it not help too.
vtkOutputWindow *w = vtkOutputWindow::GetInstance();
w->Delete();
... (redirecting...)
don't close it. It seem to sending close signal to window is the simplest solution.
Sincerely, Bel.
08.08.2018 18:04, lucas.frucht#medilabsistemas.com.br:
>
Bel,
There is one point that is not clear to me in your question. Do you want the messages that would have been shown when vtkOutputWindow is hidden to be discarded or to be shown when you unhide it?
If you want it to be discarded, I suppose you could redirect it to /dev/null on Unix or to nul on Windows and delete the redirection when you want to unhide the window.
If you just want to delay the output, maybe, you could redirect the messages to an vtkStringOutputWindow to store the messages on a string and when you want to show then, delete the redirection and call DisplayText passing the string where you stored the messages. I never tried this, but it seems reasonable to me.
Best regards, Lucas Frucht.
On Windows, this will maybe work (I haven't tested it though).
vtkSmartPointer<vtkWin32OutputWindow> outputWindow = vtkSmartPointer<vtkWin32OutputWindow>::New();
outputWindow->SetSendToStdErr(true);
vtkOutputWindow::SetInstance(outputWindow);
The output messages will be directed to stderr instead of the output window. To turn it on again, disable the redirection. Other possibilities include subclassing of vtkOutputWindow or to install an observer for error events that do what you need.
A similar question was posted here.
I'm new to MFC,and I want to get some data in a Dialog,but this doesn't work,
CTestDoc* pDoc=GetDocument();
pDoc->Get(...);
I Google it and find GetDocument() only used in CView.
So I try this and it really works:
CMainFrame *pMain=(CMainFrame *)AfxGetApp()->m_pMainWnd;
CTestView *pView=(CTestView *)pMain->GetActiveView();
m_name=pView->v_name;
But I don't think it's a good solution,so I want to know is there any functions to solve this?Thank you.
You didn't say anything about what the dialog does but it may be desirable to pass this data to the dialog, and not have the dialog access the document data directly. This helps keep your dialog more isolated and more likely to be usable in other programs.
I would look at the command where the dialog is displayed. Is it in the view? If so, then you can pass the document data that is needed by the dialog. If not, then the code you posted may still make sense. Either way, that's where you should locate the desired document information, and then pass it to the dialog.
I would avoid making your dialog directly aware of the document if it's not necessary.
If you want to get data from dialog, first set the data, and then get it.
For example:
CString save;
filePath.GetWindowsText(save);
richBox1.AddString(save); // to display in another box
I want to change the default behaviour of a combobox (c++, win32 api). I make the combobox drop down when something is entered in its edit control I want to avoid the default behaviour that the combobox searches for the first match in the list, selects it, and enters the selected string into the edit control. Can I suppress this behaviour by catching the respective (LB_SETCURSEL etc.) messages out of the message queue myself with GetMessage()?
Does anyone habe a different idea of how to do it?
Greets
Michbeck
You likely want to implement Window subclassing. This allows you to insert your own WndProc function into the combobox control that gets called before the control's own WndProc is called. You can filter out (and drop) window messages you don't want the control to get.
I'm not booted into my windows partition right now to run Spy++ on a combobox to see what messages it actually receives. My guess is that you want to filter out WM_CHAR from being received by the combobox.
What is the proper way to subclass a tab control in winAPI, having windows perform both the default drawing and your own. Because BeginPaint() and EndPaint() are calling within the default proc, I don't see a way to do this. I did get it working with GetDC(), but it had a very bugs which annoyed the hell out of me.
If what I am asking is impossible, what is the best way to draw the tabs by myself?
Subclassing is not required in your situation. The tab control supports the TCS_OWNERDRAWFIXED style bit, which allows its parent window to handle WM_DRAWITEM messages and draw the tabs itself.
There's a nice exemple on Codeguru. It uses MFC but don't let that stop you. Check out their CTabCtrlEx::DrawItem() method.
I need to know when my Window goes out of input focus, so I overloaded the OnKillFocus() method of the CWnd.
However it doesn't invoke this method when I focus another application (alt+tab), or even minimize the window. But it DOES invoke the method when I restore it from being minimized. Are these the intended times for it to trigger this method?
I think you'll need a CWnd::OnActivateApp() handler if you need to be sure of being notified when your application is switched out.
OnKillFocus() is normally only used consistently for controls that have a concept of gaining the focus - buttons, edit boxes, list boxes, etc. Normally CWnd does not accept the focus, so you can't rely on that - I'm surprised you get it at all.
In addition to WM_ACTIVATEAPP mentioned above, there's also WM_ACTIVATE when switching between windows within the same application you might want to trap.