I'm using Visual Studio 2005 and programming a dialog-based MFC application in C++.
I have an edit box and I'm trying to make it auto-scroll.
When I make auto vscroll true, it still won't auto-scroll when I have too many lines in my edit box.
Any ideas in what could be wrong? Is there maybe some code line I have to add to my edit box?
What do you mean by "Auto-Scroll"?
Turning on auto vscroll enables the ES_AUTOVSCROLL edit control style which:
ES_AUTOVSCROLL -
Automatically scrolls text up one page when the user presses the ENTER key on the last line.
This may not be what you think "Auto-Scroll" means. A common misconception is that auto vscroll will automatically turn on/off the vertical scroll bar as more text is typed into the edit control. This is not the case, you have to either always have the scroll bar displayed or you have to come up with your own code to turn on and off the scroll bar yourself.
Related
When using a MFC ribbon based application, by default we get options to add keyboard short cuts for all our commands. So for example, I might use 'p' to bring up the print preview dialog. When I'm in a dialog, these commands are not active as you would expect, even if that dialog is not modal. However, if I click into an edit control on the ribbon these commands remain active, so for the example given I could not type 'p' into my edit control. A work-around is to add a modifier such as Ctrl + P or Shift + P but this makes the shortcut more awkward for my users. Is it possible to change the message filter either for the ribbon as a whole, or for individual ribbon controls, such that they ignore keyboard shortcuts the same way a dialog does?
Edit Some feedback here from related thread on MSDN
In windows, when you click the small icon in the upper left of the window, you get a menu with Move, Minimize, Maximize, and Close options.
Is there anyway I can add my own options to that menu?
Absolutely.
GetSystemMenu(hWindow, FALSE) gets you menu handle and you are free to modify it.
A nice way is to add a separator and append your additional items like "About...". ATL code snippet is here: http://www.assembla.com/code/roatl-utilities/subversion/nodes/trunk/FilterGraphSpy/GraphBuilderCallbackPropertySheet.h#ln1392 lines 1392-1396.
I am trying to create a tab-control that have the tab-buttons aligned from right-to-left, in Win32/c++. The WS_EX_LAYOUTRTL flag doesn't help me, as it mirrors the drawing completely both for the tab items and the tab page contents. The application itself handles the mirroring automatically (it's a cross platform UI solution), which is also a reason for us not to use WS_EX_LAYOUTRTL flag (we have mirroring implemented in a generic way for all UI frameworks/platforms).
One solution would be to override TCM_GETITEMRECT and TCM_HITTEST in the subclassed TabCtrls window procedure. This enables me to move the buttons allright, but the mouse events still acts on the positions that the control "knows" the buttons really are at (ie. mouseover on the first button invalidates the leftmost button - the coordinates are not mirrored).
So that seems to be a dead end for me.
Another possibility would be to insert padding before the first tab button, to push them all to the right edge. I haven't been able to figure out how to do that, though. Visual Studio sports this little dialog:
How did they put the buttons in front of the first tab page? Knowing this would enable me to solve this problem.
Update, solution:
The solution to my problem is to use the built-in RTL support. For this to work, the tab control must have both the WS_EX_LAYOUTRTL and WS_EX_NOINHERITLAYOUT flags. That will preserve the function of all existing drawing code while only the TabCtrl buttons are mirrored. I didn't realize that the ES_EX_NOINHERITLAYOUT flag goes on the parent (the TabCtrl), which is why I was looking for the workaround originally described.
For reference, I am still curious to have an answer to the original question, though.
If you take a look with a spy application you will see that it is not actually a normal windows tab-control but custom thing and the drawing is done by the parent window AFAIK:
Both Visual Studio and Office use a lot of custom controls, some of the features make their way into the common controls after a few years, some features stay private...
How would one prevent the little dotted square that appears on a button when it has the keyboard focus in a dialog. (w/ apologies for the technical jargon). At one point I hacked together a solution by subclassing a button WindowProc and subverting some windows messages, but wanted to know the correct way.
There's actually a problem with another control in the dialog also involving the keyboard. This other control is actually also a button, but being used as a group box or panel, not as a functioning button. But when I hit the tab key in the dialog, this group box "button" comes to the foreground obscuring the static controls on top of it, so I wanted to prevent that.
For both of the above, I tried turning off WS_TABSTOP - didn't help.)
Both of my problems mentioned above were solved by subclassing the WndProcs and returning 0 in response to message 0x128 and discarding it. Even Spy++ could not identify this message 0x128, and I don't have it in any header. But its sent to every control in the dialog the first time tab is hit in the dialog.
(I did try BN_SETFOCUS as described above and also WM_SETFOCUS but it didn't help.)
So if anyone knows where to find what windows message 0x128 is...
The correct way is to write your own button control instead of using the default Windows one.
Alternatively, you can prevent if from ever getting keyboard focus.
Is there a way to create a modeless dialog box in C++ MFC which always stays on top of the other windows in the application? I'm thinking sort of like the Find dialog in Visual Studio 2005 - where it stays on top, but you can still edit the underlying text.
(If it makes any difference, it's not MDI; it's a dialog-based app)
Note: This does not work under Windows 10, and may not work under Windows 7 and 8 (Reports vary).
From Nish:
###Making your dialog stay on top
Haven't you seen programs which have
an "always-stay-on-top" option? Well
the unbelievable thing is that you can
make your dialog stay on top with just
one line of code. Simply put the
following line in your dialog class's
OnInitDialog() function.
SetWindowPos(&this->wndTopMost,0,0,0,0,SWP_NOMOVE|SWP_NOSIZE);
Basically what we are doing is to use
the SetWindowPos function to change
the Z-order of our dialog window. We
make our dialog stay on top of all
other windows by moving it to the top
of the Z-order. Now even when you
activate some other window, our window
will stay on top. But I'd advise you
to make sure you know exactly what you
are doing when you do this, for it
might annoy people if they can't get
your window out of the way when they
want to do that.
As you mentioned in the comments, the above line makes the window sit on top of every application. You'll need to do
SetWindowPos(&this->wndTop,0,0,0,0,SWP_NOMOVE|SWP_NOSIZE);
To make a window sit on top of only your application.
The accepted answer fails for Windows 7 or above. (Or perhaps its me)
But making the modeless dialog as popup instead of child solves it.
It now gets positioned wrt main dialog window but you can write code to constrain anywhere.
Using the no border or top bar makes it a simple window.
It worked for me in Microsoft Windows Version 10.0.18362.476. Had to put SetWindowPos(&this->wndTopMost,0,0,0,0,SWP_NOMOVE|SWP_NOSIZE); in OnInitDialog and make the dialog as a PopUp.