I'm subclassing an edit control, and I'm looking for a message I could intercept that would allow me to capitalize the first letter in the box.
WM_KEYDOWN and WM_CHAR don't seem to have anything that identifies the characters case.
I currently have this working semi-good by processing the EN_UPDATE message in the parent window, but since I'm already subclassing the edit control, I'd prefer to do it in the subclassed proc.
Any help is appreciated and thanks in advance.
No, WM_CHAR definitely gives you case. WM_KEYDOWN doesn't. It doesn't solve your problem however, you also need to deal with WM_PASTE. Using EN_UPDATE is fine, it is sent in both cases, just watch out for recursion. And the pita of the parent getting it, the kind of problem that any class library solves.
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 have to deal with a nasty MS Windows application that quits doing its job as soon as it loses focus. My question is, how can I trick this application somehow to believe that it is still in focus, although it really is not?
My thoughts are:
Is it possible to suppress the corresponding "WM" message from just this application?
Can I send a fake message to this window that it acts like it is in focus?
Sending the WM_ACTIVATE message works for some apps:
SendMessage(hWnd, WM_ACTIVATE, WA_CLICKACTIVE, hWnd);
Leaving the last parameter as NULL might work too.
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.
I've been messing with Win32 API for abit, and I've got a question regarding the GUI functions.
How does one handle user input that is not managed through popup windows? I've been reading http://www.winprog.org/ but right when the interesting features comes -- lesson9 -- it becomes more abstract and I'm not sure how to do it.
Basically what I am after is the user to write input in two windows and then press a button to send a message that the content of the input is to be processed.
I think the input windows would be some EDIT-class windows and the input BUTTON-class but that's about it.
Any ideas? I'm sure it's simple, it's just makes me want to rip my hair of in native code :p
Cheers
You're correct, you want and EDIT control which is more commonly known as a TextBox and a BUTTON class which is a command button.
To get the the input the Button will send a WM_COMMAND message to its parent window with a BN_CLICKED in the wParam high word. You can identify the particular button from the hWnd you get in that message.
After that you'll need to post a WM_GETTEXT to the edit control to retrieve the users input.
This is all from memory so I highly recommend looking up the msdn pages before you code.
I'm not sure I follow 100%. Yes, you would use EDIT and BUTTON-class controls for that. Where are you getting stuck?
Just wondering where is best to put functionality in an MFC application that is triggered when the whole window is resized. I was thinking mainfrm but I couldn't seem to capture any OnSize messages...
Can someone tell me what I am doing wrong?
Can someone tell me what I am doing wrong?
You didn't include any interesting details, so here are a few guesses (because of course the mainframe normally gets sent WM_SIZE messages...):
You didn't set up your message handler properly. Perhaps you forgot the message map entry?
You have an existing handler in place for WM_WINDOWPOSCHANGED that fails to call the default window procedure, thereby preventing WM_SIZE messages from being sent.
I am guessing that you are using the Multiple Document Interface ( MDI ) application type. In this case, you should capture the WM_SIZE message in each of your views - the classes you have derived from CView.