You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to add two items to the context menu that is displayed when right-clicking the column headers:
Size Column to Fit
Size All Columns to Fit
These are copied from the items that Windows Explorer has in its context menu when right-clicking on one of its column headers, and they will behave the same way:
This issue is not asking for the code to be written—it is asking for feedback on the implementation before I write code that may end up rejected or lingering forever in a PR.
Issues/Topics for Discussion:
I want these items to appear at the very top of the context menu, just like they do in Windows. However, that may be considered a breaking change. Would it be accepted if I inserted these items at the top of the context menu (by modifying CGridListCtrlEx::OnContextMenuHeader()), followed by a separator?
Assuming that I were to do that, would it be preferred that I shift the indices of the existing items (which are numbered 1, 2, and 3) down, so that the new items are numbered 1 and 2? Or would it be preferred that I assign the new items indices 4 and 5, even though they will be inserted in the menu above item index 1?
Should the automatic insertion of these items be configurable by the client of the control, as with CGridListCtrlEx::HasColumnEditor()? Personally, I am thinking that they should always be inserted for all grid controls, so I would be inclined not to add the complexity, but I am open to doing more work if it would increase the odds of the PR getting accepted. Or, you know, if someone has a logical counter-argument. :-)
If you don't like any of these ideas, then I will need to figure out alternatives (because I really am that stubborn). Unfortunately, the only option available to me now, without modifying the code, is to override the CGridListCtrlEx::OnContextMenuHeader() function, not call the base-class implementation, and handle everything myself. I'd rather not do that, as I like most of the default implementation. But I have no way to customize the default implementation, since it creates the menu, shows it, and handles its commands all in the same function.
As a compromise, I could modify the CGridListCtrlEx::OnContextMenuHeader() function to call a new protected member function (something like OnPrepareContextMenuHeader()) immediately before it shows the context menu (with TrackPopupMenu()). I could pass a non-const (mutable) reference to the CMenu object (menu) to this member function so that derived classes could customize the menu in whatever way they want before it is displayed. Of course, I'd still need to figure out how derived classes could handle selection of the items that they add. This is why I'd rather not do it this way.
Advice? Suggestions?
The text was updated successfully, but these errors were encountered:
1) - Think extending OnContextMenuHeader is fine, so it always includes the 2 new options (with separator). Extend it for both CGridListCtrlEx + CGridListCtrlGroups
2) - Think the 2 new options should be on top. Similar to what is done in CGridListCtrlGroups::OnContextMenuHeader (Where grouping-options are on top)
3) - Think the insertion should be controlled by calling a virtual method (one for each item), and each method should also return the menu-item-name. Similar to what is done in HasColumnDefaultState
I would like to add two items to the context menu that is displayed when right-clicking the column headers:
These are copied from the items that Windows Explorer has in its context menu when right-clicking on one of its column headers, and they will behave the same way:
This issue is not asking for the code to be written—it is asking for feedback on the implementation before I write code that may end up rejected or lingering forever in a PR.
Issues/Topics for Discussion:
I want these items to appear at the very top of the context menu, just like they do in Windows. However, that may be considered a breaking change. Would it be accepted if I inserted these items at the top of the context menu (by modifying
CGridListCtrlEx::OnContextMenuHeader()
), followed by a separator?Assuming that I were to do that, would it be preferred that I shift the indices of the existing items (which are numbered 1, 2, and 3) down, so that the new items are numbered 1 and 2? Or would it be preferred that I assign the new items indices 4 and 5, even though they will be inserted in the menu above item index 1?
Should the automatic insertion of these items be configurable by the client of the control, as with
CGridListCtrlEx::HasColumnEditor()
? Personally, I am thinking that they should always be inserted for all grid controls, so I would be inclined not to add the complexity, but I am open to doing more work if it would increase the odds of the PR getting accepted. Or, you know, if someone has a logical counter-argument. :-)If you don't like any of these ideas, then I will need to figure out alternatives (because I really am that stubborn). Unfortunately, the only option available to me now, without modifying the code, is to override the
CGridListCtrlEx::OnContextMenuHeader()
function, not call the base-class implementation, and handle everything myself. I'd rather not do that, as I like most of the default implementation. But I have no way to customize the default implementation, since it creates the menu, shows it, and handles its commands all in the same function.As a compromise, I could modify the
CGridListCtrlEx::OnContextMenuHeader()
function to call a newprotected
member function (something likeOnPrepareContextMenuHeader()
) immediately before it shows the context menu (withTrackPopupMenu()
). I could pass a non-const (mutable) reference to theCMenu
object (menu
) to this member function so that derived classes could customize the menu in whatever way they want before it is displayed. Of course, I'd still need to figure out how derived classes could handle selection of the items that they add. This is why I'd rather not do it this way.Advice? Suggestions?
The text was updated successfully, but these errors were encountered: