The TextBox class already supports undo, as it is present and functional in the context menu.
I would like to implement undo/redo buttons as found in every common document editor such as Microsoft Word. They would be disabled when they have no action to take, and when there is an undo/redo stack to move through, pressing the buttons would cause the TextBox's contents to undo and redo.
Looking at the TextBox API, there doesn't seem to be any mention of how to hook into the undo data. The only discussion is a mention that undo is present on the context menu.
How are undo/redo hooks implemented on a TextBox?
If it makes a difference, I'm currently coding in C++/CX.
You definitely can record the history manually by TextChanged event. Undo command is used to display the previously input. Hook into the control seems not possible.
Handle the ContextMenuOpening event from TextBox and you can modify the Popup by your own commands, for example your own undo/redo history.
A good sample: https://code.msdn.microsoft.com/windowsapps/Context-menu-sample-40840351 also works fine with UWP.
Related
I recently migrated my source code to Gtkmm 3.20. In this versión of gtk appears an automatic popover.
How I can remove this functionality? See image.
This is a new feature of GTK+ 3.20: if the GtkEntry sees touch events, which happens if you use a touchscreen and tap the entry, then it will automatically show that popover, which contains touch-friendly editing buttons (Paste is what you see there; I presume Cut, Copy, and Select All would be available on a non-password GtkEntry as well).
There is no way to turn that off, however it should only show up when you touch the GtkEntry; if you use keyboard or mouse navigation, it shouldn't show up. If it still does, you can report that as a bug to the GNOME Bugzilla.
It seems you are implementing a PIN entry field. I agree that in that case the popover isn't needed. You should state that case directly to the GTK+ developers then; maybe they will provide an API to turn the popover off (but it will not be part of GTK+ 3.20).
I need to extend an existing MFC app with a UI that will end up very cluttered unless I use a tab control. However, the nature of the UI is that there are some controls that are global, and only some that can be localised to a particular tab.
The standard use of tab controls (CPropertySheet + CPropertyPage) more or less expects there only to be CPropertyPage instances (tabs) visible on the CPropertySheet object, and nothing else. There is a Microsoft Example Project that shows a single additional window painted outside the area occupied by the tab control... but it's not immediately clear how it is created/drawn/handled, and it is only one single additional window that generates few events (I guess it is painted, so there must be a WM_PAINT event handler lurking somewhere).
Is it possible to lay out a bunch of controls with the MS Dialog Editor, including a tab control, and create the CPropertySheet using that template, hook up event handlers in a nice way, etc... or some equivalent way of getting the MFC framework to do as much of the creating, drawing and event handling as possible when it comes to a situation like this?
Yes it is possible to create dialog templates and use them in a CPropertyPage.
Each CPropertyPage behaves nearly like a dialog and handles all events for the controls on it.
Also there are features like OnApply that help you to manage the data exchange between the controls and your internal storage.
The central CPropertySheet only creates the dialog that get active. So OnInintDialog for a page is called the first time when the page gets active.
In the MFC since 2010 are more possibilities than a CPropertySheet. You can create tabbed views, that again may be CFormViews. I don't like CDialog based applications so I would prefer a tabbed view in a standard frame with toolbar and menus if appropriate for the application. So another method to unclutter your UI is to choose the MDI interface with tabbed documents... but multiple documents maybe isn't what you want.
Here is a sample of an SDI application with multiple tabbed views.
Also Coeproject shows some more samples here and with splitters and tabs here.
There are at least three solutions paths:
Try to squeeze the situation into the CPropertySheet + CPropertyPage framework which does not naturally allow for additional dialog controls on the CPropertySheet object, and so you will get no framework support this
Place a tab control on an ordinary dialog, and then use the TCN_SELCHANGE messages to fire code that manually hides & shows individual dialog controls subject to the tab control (again no framework support, but this time "within" the tab control instead of outside it)
Follow Mark Ransom's observation that if you can embed one kind of CWnd-based control on a CPropertySheet then you can probably embed any such object, including a CDialog-based object that has been developed in the MFC Dialog Editor
All of these approaches are going to encounter challenges, and it will depend on the specifics of the situation as to which is better. But first you should really consider whether there is a cleaner UI design which would lend itself to a simpler solution.
In my specific case, I saw no cleaner design alternatives, and found it easiest to take the second approach. It left me with some reasonably simple calls to ShowWindow() to show/hide the controls inside the tab control.
When a textEdited() signal is emitted, it can be either because the user has typed/pasted/deleted/replaced some text, or it can be an Undo operation (user has pressed Ctrl+Z, or clicked Undo from the context menu).
I need to distinguish between those somehow. Is there a way to be notified when an Undo operation is performed - subscribe to signal, catch an event perhaps? I couldn't find anything in the QLineEdit documentation myself, but I might have missed it.
Or is there a way to simply check if an Undo has been performed - perhaps a flag, or is there a way to check what the size of the Undo stack is? That way I could compare it its previous size, and if it has decreased, then I would know it's an Undo.
If you want to know why I need this, I'm trying to implement Editable multi-color QLineEdit, and I need this in order to restore the previous colors in the event of an Undo operation.
QLineEdit is designed for plain text editing. It is not designed to support advanced formatting. You should use QTextEdit instead. There are a lot of samples in the internet, how to do that.
If you want to practice in creating of custom text editors, then you should implement necessary interface (methods, signals) by yourself.
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...
I have an app with a customized frame (i.e., caption/titlebar, borders). I customized the frame by removing the WS_CAPTION style, and overriding OnNcCalcSize to reserve a custom-sized area for the caption, which the app paints in OnNcPaint.
A side effect is that the menu bar no longer displays, which is OK because I want to customize the appearance & location of the main menu. Unfortunately, I don't know how to do that. I would like the "File" menu to be further from the left edge than it is with the standard menu bar.
An acceptable alternative would be to remove the menu entirely, and use OnNcHitTest, OnNcPaint and OnNcMouseMove to manage a hand-coded replacement for the top-level menu.
I've never seen a way to modify the looks of the standard menu. You can remove it (remove the creation code from your InitInstance) and then code a replacement. I wouldn't do that in OnNcXXX though, rather make a new custom control that you position at the top. Or you could have a look at the MFC Next themed menus and write a custom UI renderer. It may be enough to override a few functions left and ride to set the alignment of the menu.
It's an MFC MDI app -- InitInstance is not where the menu is being created. I have tried to get rid of the menu (and succeeded, temporarily) but the MFC framework seems to be "putting it back" -- I think the MDI model has the child windows modify the menu, but the code that does that seems to be buried in the framework somewhere (or else I just haven't been able to find exactly where it happens in the application's code, but I suspect it's happening inside the MFC framework code). If I knew where, I might be able to override the methods(s) and take control... I think.
What would be the reason to write a custom control vs. handling OnNcMouseMove & OnNcLeftButtonDown, e.g.? I don't expect to need the functionality in any other app (a new app would be coded in C#, probably), so I'm looking for ease of implementation, not code reuse.