Related
I ran into a newbie problem with my first VC++ MFC app (actually, I ran into many problems, but RTFM and DuckDuckGo helped to solve them without crying here for help. Except this one!). Bear in mind that I am playing with this as a tutorial for myself, kind of a learn by example project, and I have a few years of Win GUI app programming experience in Deplhi/Lazarus, and now I am attempting to transition into VC++, simply for my own curiosity. While I am also good with C language programming, I have significantly less experience with C++. So the new programming environment and the less-known language together pose as my obstacle.
Here is what I did:
In a recently installed Visual Studio 2019 Community with only the Windows App development in C++ components selected, started a new project, chose C++ MFC App (Build apps with complex user interfaces that run on Windows.). Set application type to Dialog based, turn off all User Interface Features so only Thick frame is checked (unchecked System-menu, unchecked About-box), turn off all Advanced Features so only Common Control Manifest is checked (unck Printing and print preview, unck Activex controls, unck Support Restart Manager), clicked FINISH.
This prepared me an app with a single small main window, OK and Cancel buttons in its lower-right corner, and a STATIC TEXT item in the middle-center reading something like "TODO: add your own items here". Project name is TutMFC01p.
My goal was to hide that STATIC TEXT when I click one of the buttons, and make it visible again when I click the same button again.
It took me some time to realize that I should not fiddle with the OK and Cancel buttons to add them this functionality, and clicking either of these two buttons also quits my app (hence, no chance to click again). So I placed a new button on the dialog and worked with that instead. Clicking my button while my app was running did absolutely nothing - which was exactly what I wanted.
Double-clicking my button in the Dialog Editor dropped me into Source Editor with a new function autogenerated at the bottom of TutMFC01pDlg.cpp.
void CTutMFC01pDlg::OnBnClickedButton1()
{
// TODO: Add your control notification handler code here
}
Allrighty, so this is where I will add the code of what the button is supposed to do.
It also injected an ON_BN_CLICKED line to the MESSAGE MAP, which now looks like this.
BEGIN_MESSAGE_MAP(CTutMFC01pDlg, CDialogEx)
ON_WM_PAINT()
ON_WM_QUERYDRAGICON()
ON_BN_CLICKED(IDC_BUTTON1, &CTutMFC01pDlg::OnBnClickedButton1)
END_MESSAGE_MAP()
Allrighty again. So this is the way to tell the system that clicking my button should run the code given in CTutMFC01pDlg::OnBnClickedButton1().
The way I first tried to complete my goal was to alternate the STATIC TEXT object between the TRUE and FALSE value of the VISIBILE property upon the click of my button. A Delphi/Lazarus way of doing it is a single line of code like mainform.mystatictext.visible := not mainform.mystatictext.visible but I was not able to find a way to directly reference the property of an object and change its value with a simple assignment operation. What I found instead is that the way to hide objects is using the ShowWindow() method. I also run into difficulties trying to point this (or any other) method to the STATIC TEXT object, because apparently it has an ID of IDC_STATIC, which, apparently, cannot be referred to, as all static objects have this same ID. To simplify the task ahead, instead of hiding the STATIC TEXT I settled for hiding the button itself, and ended up with this code:
void CTutMFC01pDlg::OnBnClickedButton1()
{
// TODO: Add your control notification handler code here
CWnd* pMyButtonObj = GetDlgItem(IDC_BUTTON1);
pMyButtonObj->ShowWindow(SW_HIDE); //or SW_SHOW
}
This compiles and works very well. Obviously, once the button is pressed and disappears from the window, there is nothing to press again in order to unhide what was hidden. So I tried to move on from this already working code and modify it to act on the STATIC TEXT instead of the button itself. Logic suggested (my logic, anyways) that in order to gain the ability to refer to the ID of the STATIC TEXT, I need to assign a different ID to the STATIC TEXT. Something I can refer to. Something other than the not referrable IDC_STATIC. So I selected the STATIC TEXT object on the Dialog Editor, and in its Property palette I changed the value of the ID property from IDC_STATIC to IDC_STATIC1. This strangely has also changed the NAME property of the object to IDC_STATIC11. Earlier the NAME was IDC_STATIC1. Then in the code of OnBnClickedButton1() I replaced IDC_BUTTON1 with IDC_STATIC1, but that fails to compile complaining that there is no such object. Same happens when tried with IDC_STATIC11.
A little experimenting revealed another phenomena I am unable to explain (or understand). Similarly to how I changed the ID of STATIC TEXT, with my button selected in the Property Editor, I changed its ID from IDC_BUTTON1 to IDC_HideBtn. This also changed its NAME property.
Saved All, rebuilt project, and clicking my button still made it disappear, exactly as it was working before. HOWEVER, the source code of OnBnClickedButton1() and the MESSAGE MAP did not get updated to refer to the new ID, IDC_HideBtn, they still refer to IDC_BUTTON1, same as before.
void CTutMFC01pDlg::OnBnClickedButton1()
{
//TODO: Add your control notification handler code here
CWnd* pMyButtonObj = GetDlgItem(IDC_BUTTON1);
pMyButtonObj->ShowWindow(SW_HIDE);
}
But at this point, IDC_BUTTON1 should be a non-existing ID. Compile should fail. Yet it compiles fine, and it works fine.
QUESTIONS:
Why does the code compile and work with IDC_BUTTON1 in the source while the ID of the button is now IDC_HideBtn?
What can I do to be able to address the STATIC TEXT item as the argument to GetDlgItem() the same way as I could do with IDC_BUTTON1?
If STATIC TEXT items are not supposed to be programmatically changed then what other kind of item could I use instead? In Delphi/Lazarus there is a LABEL object similar to STATIC TEXT, but designed to get different Caption or other values many times while the program runs. In the toolbox of the Dialog Editor I see nothing like that, only STATIC TEXT. Or should I use an Input field instead, to display text in the dialog window?
Is there a way to implement the button click method in the way I initially tried to do the Delphi/Lazarus way? Changing the target object to visible from hidden, and to hidden from visible. Preferrably as a one-liner.
Is there NO WAY to directly refer to the property of an object and change its value with an assignment operation? Or only I did not find it how?
I have some small corrections (as I think), and I wanted to issue them as comments, but according to the comment policy it is better to post an answer despite that the answer has already been given.
Question 2:
It's strange that VS didn't add a new define for IDC_STATIC1 in resource.h on renaming a CStatic component (after all VS created a new id for a new button).
But of course, manual editing of resource.h is a very frequent procedure during programming with MFC, but it is necessary to update the _APS_NEXT_CONTROL_VALUE (and much less often _APS_NEXT_COMMAND_VALUE ) definition so that it points to a new correct value (not equal to previous definitions).
Question 3:
But you can write in you .rc file something like this:
BEGIN
DEFPUSHBUTTON "OK",IDOK,209,178,50,14
PUSHBUTTON "Cancel",IDCANCEL,263,178,50,14
CTEXT "TODO: Place dialog controls here.",IDC_MidTextObj,13,96,300,8
PUSHBUTTON "Hide object",IDC_HideBtn,135,106,50,14
END
and then in CTutMFC01pDlg.cpp:
void CTutMFC01pDlg::OnBnClickedHidebtn()
{
if (CWnd * pMyStaticObj = GetDlgItem(IDC_MidTextObj))
pMyStaticObj->ShowWindow(!pMyStaticObj->IsWindowVisible());
}
Question 4:
Also you can use the the DoDataExchange mechanism for getting/setting text for components like CStatic, CEdit, etc., and you can use ON_UPDATE_COMMAND_UI macros for enabling/disabling components.
But the basic way is to get a component as a CWnd class:
CWnd * pMyStaticObj = GetDlgItem(IDC_MidTextObj)
or get the component explicily:
CStatic* pMyStaticObj = static_cast<CStatic*>(GetDlgItem(IDC_STATIC1));
(don't use dynamic_cast here)
and then call methods of this fetched instance.
Thanks to the comments my question received, I could refine the direction of my web searches and also examine other files in my project folder to identify where trouble originates from, and understand how pieces of my MFC app fit together. Also, sometimes the inner workings of Visual Studio 2019 require a little manual editing help.
ANSWER 1)
All those IDC_xyzwq identifiers I can assign to the object in its property palette (values are selectable from a list) are predefined macros pointing to their respective numeric value. These live inside the resource.h file of the project. Unfortunately, VS2019 never allowed me to open this file as readable text - it always complained that the file is already open and asked me if I want to close it instead. To study the contents, I actually had to close my VS2019 solution, and open the resource.h file in a text editor. Here is what I found in there:
//{{NO_DEPENDENCIES}}
// Microsoft Visual C++ generated include file.
// Used by TutMFC01p.rc
//
#define IDD_TUTMFC01P_DIALOG 102
#define IDR_MAINFRAME 128
#define IDC_BUTTON1 1002
#define IDC_ButtHide 1002
#define IDC_HideBtn 1002
// Next default values for new objects
//
#ifdef APSTUDIO_INVOKED
#ifndef APSTUDIO_READONLY_SYMBOLS
#define _APS_NEXT_RESOURCE_VALUE 130
#define _APS_NEXT_COMMAND_VALUE 32771
#define _APS_NEXT_CONTROL_VALUE 1000
#define _APS_NEXT_SYMED_VALUE 101
#endif
#endif
So it seems that each time I invented a new ID for my button and entered it in the Property Palette, VS2019 injected a new macro definition into the resource file, assigning it to the same numerical value of 1002. But other than auto-creating such entries, Visual Studio performs no maintenance on them and it is the responsibility of the programmer to keep order there. Which requires that the programmer understands what is what, and where it is stored in the project files.
So, even though my button object already had the ID value of IDC_HideBtn in its Property Palette, the earlier IDs of IDC_ButtHide and IDC_BUTTON1 were still valid and referred to the same numeric value of 1002, hence the source code using the old ID compiled, and the button worked fine.
Mind you, I also had to manually replace the button ID NAME to the chosen one in my apps MESSAGE MAP in TutMFC01pDlg.cpp before Visual Studio could reopen my solution/project. See the next section of my answer too.
ANSWER 2)
IDC_STATIC being a peculiar ID with some special treatment, I cannot just invent and type-in any new name into the ID property field of my STATIC TEXT item. More precisely, I actually CAN invent any new ID and enter that into the property field, but Visual Studio DOES NOT automatically generate the corresponding new macro definition in resources.h, most likely because it does not know what numeric value to assign to an object that is supposed to have no numeric value (as it was supposed to have the special value of -1). So instead of entering a new name in the ID property field, the programmer should close the solution, and manually edit the resources.h file in a text editor. YES, against all warning and discouragement in Microsoft Documentation and by seasoned developers, in this particular case it must be done manually. (Or at least, I do not know a better way than directly editing the resource file as text.) Here is what I changed my macro definitions to, by removing the two obsolete and unwanted button identifiers with the value of 1002, and manually adding a new definition entry intended for my STATIC TEXT item - with a numeric value that was not in use by any other entry. In my case, 1001 was not yet used, so that is what I assigned to my invented ID of IDC_MidTextObj.
//{{NO_DEPENDENCIES}}
// Microsoft Visual C++ generated include file.
// Used by TutMFC01p.rc
//
#define IDD_TUTMFC01P_DIALOG 102
#define IDR_MAINFRAME 128
#define IDC_HideBtn 1002
#define IDC_MidTextObj 1001
// Next default values for new objects
//
#ifdef APSTUDIO_INVOKED
#ifndef APSTUDIO_READONLY_SYMBOLS
#define _APS_NEXT_RESOURCE_VALUE 130
#define _APS_NEXT_COMMAND_VALUE 32771
#define _APS_NEXT_CONTROL_VALUE 1000
#define _APS_NEXT_SYMED_VALUE 101
#endif
#endif
With these changes saved in resource.h I could close my Text Editor and reopen the solution/project in Visual Studio. Then I could select the STATIC TEXT item in the UI Editor, and in its Property Palette, in the field of the ID property, I could drop down the list of values and select my prepared value of IDC_MidTextObj. Mind you, there is another way to do this, by manually editing the .rc file of the Dialog. Which you will likely need to do for other reasons anyway. See next section of my answer.
ANSWER 3)
Here is the relevant part of my TutMFC01p.rc file.
IDD_TUTMFC01P_DIALOG DIALOGEX 0, 0, 320, 199
STYLE DS_SETFONT | DS_FIXEDSYS | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_THICKFRAME
EXSTYLE WS_EX_CLIENTEDGE | WS_EX_APPWINDOW
CAPTION "My VisualC++ Tutorial App 01"
FONT 8, "MS Shell Dlg", 0, 0, 0x1
BEGIN
DEFPUSHBUTTON "OK",IDOK,209,178,50,14
PUSHBUTTON "Cancel",IDCANCEL,263,178,50,14
CTEXT "TODO: Place dialog controls here.",IDC_STATIC,13,96,300,8
LTEXT "Hello MFC!",IDC_STATIC,22,33,86,8,WS_DISABLED
PUSHBUTTON "Hide object",IDC_HideBtn,135,106,50,14
END
I could just change the line starting with CTEXT and replace IDC_STATIC with IDC_MidTextObj to make sure that the STATIC TEXT item uses my pre-created value.
ALSO, if you look carefully, you see that the next line defines another STATIC TEXT item (a new static text item I added to the window in the Dialog Editor). But this is LTEXT instead of CTEXT. Without peeking at this code as text, I would not have known that there are these two different types. Maybe LTEXT is what I was after. I will see what I find about this in the documentation.
ANSWER 4)
Not as a one-liner. See also the next section of my answer for details. But it can be done with multiple lines of code, calling methods to first query the current state of visibility of the object, then hide it if it is visible, or show it if it is hidden.
ANSWER 5)
NO, there is no way to do that in VC++. It works in other languages, but in C++ you have to call functions/methods. See answer from Mark Ransom at the bottom of a similar issue.
I am trying to create a simple panel for Openbox in Arch Linux using c++, but I cannot figure out how to remove the title bar from a window.
I am creating the window with XCreateWindow(...), and that gives a window with the correct size, but it contains a title bar, and the window also opens in the top-left corner of the screen, no matter what offset coordinates I specify.
I read here that both of these problems are probably caused by the window manager (Openbox), which overrides the window attributes I specified in XCreateWindow(..., &window_attributes). This could be solved by adding window_attributes.override_redirect = True;, although this does not seem to do anything for me. When I try this I get the exact same window as before. (I did compile the file after this change.)
Also I read into the code of Tint2 (link), which is another panel for Openbox. They create a window using the following code:
XSetWindowAttributes att = { .colormap=server.colormap, .background_pixel=0, .border_pixel=0 };
p->main_win = XCreateWindow(server.dsp, server.root_win, p->posx, p->posy, p->area.width, p->area.height, 0, server.depth, InputOutput, server.visual, mask, &att);
I don't see an override_redirect anywhere in their code, so I'm not sure how they are removing the title bar.
As additional information, I thought it would be worth mentioning how I'm executing the script:
/* The c++ file is saved as 'panel.cpp' */
$ gcc panel.cpp -lX11 -o panel
$ ./panel
Also, I am running Arch Linux through VirtualBox with Windows 8 as host. I'm not sure if this changes anything, but it won't hurt to mention.
Since I found the solution, I figured I'd post the solution here if anyone else needs it.
As #JoachimPileborg mentioned, I needed to alter the Openbox settings in ~/.config/openbox/rc.xml. Inside the <applications> tag, I added the following code:
<application class="*">
<decor>no</decor>
<position force="no"></position>
</application>
The class="*" means that all applications will follow these rules, you could fill in the class name of the application instead. The <decor>no</decor> removes the title bar, and <position force="no"></position> ensures that my own script is able to handle the positioning. You could also add another <application> tag after this one to make exceptions to this rule.
Also, the window_attributes.override_redirect = True; is not needed anymore.
A more correct way is to use the Extended Window Manager Hints.
The idea is that you don't tell the window manager how to decorate or not your window, you just indicate the window type with _NET_WM_WINDOW_TYPE :
Atom window_type = XInternAtom(display, "_NET_WM_WINDOW_TYPE", False);
long value = XInternAtom(display, "_NET_WM_WINDOW_TYPE_DOCK", False);
XChangeProperty(display, your_window, window_type,
XA_ATOM, 32, PropModeReplace, (unsigned char *) &value,1 );
"Dock" is the type for panels and taskbar. Usually they are undecorated and appear on all desktops. As written on the documentation, previously the _MOTIF_WM_HINTS property was used to define the appearance and decorations of the window. Window managers still support it, but _NET_WM_WINDOW_TYPE is prefered as it describe the function and let the window manager (and user) decide on the appearance and behavior of that type of window.
Another interesting property for a panel is _NET_WM_STRUT_PARTIAL, to "reserve" space.
Does anyone know which relation may exist between registration-free COM and drag/drop functionality?
Specifically, we have a huge C++ CAD/CAM application comprising a number of EXEs and several hundreds DLLs. Many of them serve as COM servers (both in-proc and out-of-proc) and/or clients, and also implement ActiveX controls.
The most of ActiveX controls and the main CMDIFrameWnd-based window of one of EXEs implement drag/drop functionality. ActiveX controls implement the both drop source and drop target, and the main window is only drop target, in particular, for files from Windows Explorer.
The drag/drop implementation is pretty standard and based on two data members derived from COleDataSource and COleDropTarget for drop source and drop target respectively. The COleDropTarget-derived member is registered with respective window in the window's OnCreate method. It also overrides OnDragEnter, OnDragOver and OnDrop methods in a similar way. Namely, the system-supplied COleDataObject parameter is asked for specific format (in particular, CF_HDROP), and in the case of positive answer, the data (e.g., file path) is extracted from the clipboard. The code looks like the following:
static FORMATETC g_FileFmt = {CF_HDROP, 0, DVASPECT_CONTENT, 0, TYMED_HGLOBAL};
....
// Inside OnDragEnter, OnDragOver or OnDrop method
STGMEDIUM stgmedium = {0,0,0};
if (pDataObject->IsDataAvailable(g_FileFmt.cfFormat))
{
HRESULT hr = pDataObject->GetData(g_FileFmt.cfFormat, &stgmedium);
HDROP hdrop = (HDROP)GlobalLock(stgmedium.hGlobal);
if (hdrop != 0)
{
int FilesCount = DragQueryFile(hdrop, (UINT)-1, 0, 0);
if (FilesCount != 0)
{
TCHAR FileName[_MAX_PATH];
DragQueryFile(hdrop, 0, FileName, _MAX_PATH);
// Check file extension and store the file name for farther use.
}
GlobalUnlock(hdrop);
}
}
The drop source implementation is also straightforward and looks like the following:
void CDmDocListCtrl::OnBeginDrag(NMHDR* pNMHDR, LRESULT* pResult)
{
NM_LISTVIEW* pNMListView = (NM_LISTVIEW*)pNMHDR;
if (pNMListView->iItem != -1 && m_pOleDataSource && prv_BeginDrag())
{
DROPEFFECT DE = m_pOleDataSource->DoDragDrop(
DROPEFFECT_COPY | DROPEFFECT_MOVE | DROPEFFECT_LINK, 0);
}
*pResult = 0;
}
where prv_BeginDrag() function collects dragged data, packs it and puts on the clipboard by calling SetData method from the m_pOleDataSource object's IDataObject interface.
The all this stuff worked perfectly until it was decided to make the whole application registration-free. It took me three months to force the application run isolated (without registration of COM components) by embedding manifests, launching out-of-proc COM servers on demand and altering CLSID of some classes in order to separate instances of the same server launched from different folders. At last it begins to work - but without drag/drop functionality, despite it wasn't even touched by my changes.
On the drop target side, when I drag file from Windows Explorer, depicted above call to COleDataObject::IsDataAvailable returns false, although before my changes returned true. At the same time, if I add a single line of code "DragAcceptFiles();" to the main window's OnCreate method, drag/drop begins working via the standard CFrameWnd's WM_DROPFILE message handler.
On the drop source side, the dragged data are successfully packed and placed on the clipboard, but COleDataSource::DoDragDrop method fails, because a call to ::DoDragDrop API inside MFC implementation returns REGDB_E_CLASSNOTREG "Class not registered" result.
It means, that COM activation changes somehow influence drag/drop behavior. How?
P.S. 1) The EXE, to which I drag files from Windows Explorer, has in its project properties "UAC Execution Level = asInvoker". As far as I understand, it tells that the EXE will run at the same UAC level as Windows Explorer when launched by double-click on the file.
2) Quite surprisingly, although drag/drop stopped working with symptoms described above, Copy/Paste continues work well, despite the both technologies have similar implementation.
3) I believe, that if find out when ::DoDragDrop API returns "Class not registered" error, and which class it is looking for, it would be possible to solve the problem.
Thanks for help,
Ilia.
Following to MartinBa advice, I solved the problem with the help of Process Monitor. The Process Monitor showed me that while I drag an item in the ActiveX control (mentioned in the question), the system unsuccessfully tries get access to a class ID in the Registry. Looking for that ID, I found that it is really not class ID, but IDataObject interface ID. It was referenced in one of my manifest files.
The most of manifests I have written by hand, but a few, especially at the beginning of the project having no experience in the area, I generated automatically by Visual Studio from existing type library. In one of them Studio included the comInterfaceExternalProxyStub statement for a couple of system interfaces, in which proxyStubClsid32 element was (erroneously) equal to the interface ID.
I'm still not sure whether those system interfaces should present in the manifest; for example, the IDataObject is only mentioned as a method's parameter in one of IDL definitions. Anyway, I corrected only the proxyStubClsid32 value, and the problem disappeared...
The moral of this very painful for me story is to always check output of automatic tools...
How do I create a Motif main window that doesn't have a system menu, minimize and maximize boxes? I just cannot find out how by googling and reading docs and tutorials. I believe that it should be possible with some additional parameters for XtVaCreateManagedWindow, but which?
I have tried several variants of XtVaSetValues (topWid, XmNmwmDecorations, ...) but none worked. Instead I get an error message that I need to use a vendor shell for this. Most widget types aren't derived from vendor shells however, and when I e.g. try to use a dialog shell and put a scrollable text widget inside of it, then then text widget seems to control the dialog.
Apparently it's not (easily) possible to get rid of the window (system) menu, but it seems to be possible to disable window menu items with some code like this:
int i;
XtVaGetValues (widget, XmNmwmFunctions, &i);
i &= ~(MWM_FUNC_ALL | MWM_FUNC_MINIMIZE | MWM_FUNC_MAXIMIZE | MWM_FUNC_CLOSE);
XtVaSetValues (widget, XmNmwmFunctions, i);
which removes the related window decoration too and apparently even works for non vendor shell widgets.
There should also be the possibility to remove the decorations (i.e. make them invisible). However, please note that these "system menu" decorations belong to the Window Manager, not your Motif program itself. It is up to the Window Manager to handle your requests or disregard them--you might get vendor-specific behavior with any MWM resources.
Anyway, here's the code sample to try out:
int decors; //bit-mask of flags defining the decorations, from Xm/MwmUtil.h
XtVaGetValues(dlg, XmNmwmDecorations, &decors, NULL);
decors &= ~MWM_DECOR_MENU;
decors &= ~MWM_DECOR_MAXIMIZE;
decors &= ~MWM_DECOR_MINIMIZE;
XtVaSetValues(dlg, XmNmwmDecorations, decors, NULL);
If you intend to run your application from Mwm, you can achieve the desired behavior by setting (e.g. via XtVaAppInitialize()) the following X11 resources:
! Title bar buttons
Mwm*YourApplicationClassHere.clientDecoration: -minimize -maximize
! Window menu functions
Mwm*YourApplicationClassHere.clientFunctions: -minimize -maximize
These resources are explained in more detail here and here.
Speaking of window menu, this one depends on a specific window manager in use. Mwm, for instance, allows the client to set the menu name using Mwm*YourApplicationClassHere.windowMenu resource, the menu itself must be defined in either ${HOME}/.mwmrc or global mwmrc, or XmNmwmMenu resource of VendorShell. The resulting custom window menu is exposed as a _MOTIF_WM_MENU atom, which seems to be ignored by modern window managers.
Sample mwmrc menu definitions may look like this
Menu CustomMenu0
{
Restore _R Alt<Key>F5 f.restore
Move _M Alt<Key>F7 f.move
Size _S Alt<Key>F8 f.resize
Minimize _n Alt<Key>F9 f.minimize
Maximize _x Alt<Key>F10 f.maximize
Lower _L Alt<Key>F3 f.lower
no-label f.separator
Pass\ Keys _K f.pass_keys
no-label f.separator
Close _C Alt<Key>F4 f.kill
}
Menu CustomMenu1
{
Your\ Application\ Name\ Here f.title
no-label f.separator
Close _C Alt<Key>F4 f.kill
}
(see the function descriptions). Custom menu items can be added using f.send_msg (examples here and here).
I'm pretty sure all of the above also applies to Dtwm (CDE).
Building a file open dialog replacement. Much of it works now, but I would like to generate the view-mode drop-down for the toolbar directly from the shell view object.
Looking at IShellView2, I can see IShellView2::GetView() will give me the FOLDERVIEWMODE's supported. However, that doesn't give me the names of these modes, nor format that popup menu for me, nor immediately give me a way to actually set one of those modes (it would appear it is necessary to destroy the shell view window and create a replacement one for the current folder and specify the new FOLDERVIEWMODE desired... yeesh).
At any rate, if one right clicks on an IShellView window, one gets a context menu, the first submenu of which is exactly what I want to place in my drop-down toolbar button (ie. the "view" fly-out menu (e.g. Small Icons, Medium Icons, etc.)).
It seems like there ought to be a way to grab that submenu directly from the IShellView, rather than having to hardcode my values (and that way, if a given instance of IShellView supports extra view modes, they'd be there. Similarly, those which should be disabled would be, since it would all be under the IShellView's control).
I have read Raymond Chen's excellent How to host an IContextMenu. Unfortunately, that just gives me a very simplistic context menu - the one for the folder itself, or for a file in a given folder, but NOT the context menu for the IShellView's shell view window (from which I might obtain the view fly-out).
I have tried the following, based on Chen's article:
CComQIPtr<IContextMenu> pcm(m_shell_view); // <<-- FAIL resulting pointer is NULL <<<
// create a blank menu
CMenu menu;
if (!menu.CreatePopupMenu())
throw CContextException("Unable to create an empty menu in which to store the context menu: ");
// obtain the full popup menu we need
if (FAILED(m_hresult = pcm->QueryContextMenu(menu, 0, SCRATCH_QCM_FIRST, SCRATCH_QCM_LAST, CMF_NORMAL)))
throw CLabeledException("Unable to query the context menu for the current folder");
// display the menu to the user
// menu.getsubmenu
::TrackPopupMenu(menu, ::GetSystemMetrics(SM_MENUDROPALIGNMENT)|TPM_TOPALIGN|TPM_LEFTBUTTON, pt.x, pt.y, 0, m_shell_view_hwnd, NULL);
Unfortunately, the attempt to query the m_shell_view (which is an IShellView*) for its IContextMenu interface fails. This "works":
// retrieve our current folder's PIDL
PidlUtils::Pidl pidl(m_folder);
// get the context menu for the current folder
CComPtr<IContextMenu> pcm;
if (FAILED(m_hresult = GetUIObjectOf(m_owner->m_hWnd, pidl, IID_PPV_ARGS(&pcm))))
throw CLabeledException("Unable to obtain the PIDL for the current folder");
But here I get only a very few options in the context menu (Open, Explore, ...). Not the detailed context menu that I get if I simply right click on the shell view itself.
I'm out of ideas as to how to proceed. Help?! ;)
Try IShellView::GetItemObject with SVGIO_BACKGROUND as uItem to get a IContextMenu on the view object : http://msdn.microsoft.com/en-us/library/bb774832%28VS.85%29.aspx
There is the SHCreateDefaultContextMenu (Vista an up) that may be of help. Bjarke Viksoe website contains great info as well.
SVGIO_BACKGROUND will get you the background context menu of the shell view. You may need to call repeatedly pShellView->SelectItem for each PIDL you may have, then do the GetUIObjectOf call (then QI for IContextMenu, create a menu, call IContextMenu(3)::QueryContextMenu and finally display it with TrackPopupMenu).