I am using CFileDialog to let the user select png images to display, But for png file I feel list view is inappropriate because user have to everytime change the view to Large icon, So what is needed is to by default set the view to "Large Icon" instead of list view.
Here's is what i have done, please let me know what should i add in-order to get Large Icon view. I am using Windows 7 VS 2010 MFC C++.
CFileDialog dlg(TRUE, _T("png"), 0, OFN_FILEMUSTEXIST | OFN_HIDEREADONLY | OFN_PATHMUSTEXIST, _T("Portable Network Graphics (.png)|*.png||"));
static char szTitle[] = _T("Select Icon");
dlg.m_ofn.lpstrTitle = szTitle;
static char szInitPath[] = _T("D:\\pngImagelist");
dlg.m_ofn.lpstrInitialDir = szInitPath;
Need help of all experts out their. Thanks in advance :)
You need to obtain IShellBrowser and use QueryActiveShellView to get the shell view, then QI for IFolderView on the shell view and call IFolderView::SetCurrentViewMode.
On the vista style file dialog (that is, if you don't disable the automatic upgrade in the constructor of CFileDialog, and you are running on Vista+), you can get IShellBrowser from the IFileDialog object via its IServiceProvider interface (QueryService with SID_STopLevelBrowser). On the Windows 2000 style file dialog, you can send an undocumented message WM_GETISHELLBROWSER to the file dialog to get its IShellBrowser interface. An example can be found at https://jiangsheng.net/2021/06/16/better-late-than-never/.
This is not an easy task as it requires the use of Spy++ and an understanding of the underlying Windows Shell environment. The list view control nested within the CFileDialog is actually a representation of what the Windows Shell sees. Spy++ will reveal that it's actually "ShellDLL_DefView". You can access this control using the methodology in Paul DiLascia article. It's dated, but, the idea should still be valid.
Related
I want to display CFileDialog like the image below in Windows 7.
As per msdn
if OFN_ENABLETEMPLATE is set and OFN_EXPLORER flag is not set, the system uses the template to create an old-style dialog box that replaces the default dialog box.
But even after doing that what I get is something like this.
Please help!
Try this:
CFileDialog fd(1,0,0,0,0,0,0,FALSE);
fd.m_ofn.lStructSize = sizeof(OPENFILENAME_NT4);
fd.DoModal();
The last parameter to CTOR specifies Vista-style to be false, and structure size of sizeofed with to reflect NT4 file-dialog.
I don't think you can. That windows belong to OS and is not implemented anymore. The the closest thing you can use is the old-style dialog box.
You can try to customize this one by hooking the window but it's not easy and I don't thing it worth.
In C++, is there anyway to let the user chose the icon of the app? For example, Winamp lets you select which icon you wish to use from a list of icons in it's preferences. How is it done?
There is the icon that you see in explorer. This is a resource in your executable. You could change that, but I wouldn't advise you too. Virus scanners can get nervous if executables are modified, and in Windows Vista you will not even be allowed to write in the Program Files folder.
But the icon that is displayed on the task bar or in the system tray can be changed. This is actually the icon of your application window and it can be set by sending a WM_SETICON message.
And there are shortcuts. They can be changed too, and in a shortcut you can specify which icon should be used.
I found a discussion on changing icons that has information about the first two options.
For Visual Studio 2010 in an MFC dialog based app
A. In the resource view, rightclick Icon folder and add icon. Give it an ID like IDI_MYICON. Leave it as is or draw something nice.
B. Go to OnInitDialog. Add the following two lines of code:
HICON hMyIcon = LoadIcon( AfxGetInstanceHandle(), MAKEINTRESOURCE(IDI_MYICON) );
SetIcon( hMyIcon, FALSE ); // FALSE == use as small icon
You can read about these functions in the help to understand what is happening.
This sets the icon as icon for the sysmenu (topleft) and in the taskbar. This is however not automatically reflected in all situations. E.g. for a systray icon you need to explicitly specify the icon again in the call to Shell_NotifyIcon().
I'm still working on a Data Acquisition program in MFC and am getting stuck working with the Document/View architecture. Basically, I want my application to have a couple windows. One is used to show a video that's recorded from a high speed camera, another has a plot displaying data from the DAQ system, and maybe another has controls for configuring the camera and DAQ, etc.
So, really I have a lot of modeless windows each showing a portion of the data, usually from a different source. Now, going through and using the App Wizard I get confused with the Doc/View stuff, and even though I can turn it off, it isn't technically off. Now that aside, I've tried opening modeless Dialogs and FormViews all to no success. Mostly I just can't figure out how to open the new View, the documentation isn't really helpful. I've been able to open a Modal plotting dialog from a Ribbon Button command and I mark that as a success, but not exactly what I need.
So, does anyone have helpful insight on fitting my application to the Doc/View architecture or opening a modeless dialog or FormView from within another application. I should say I'm using Microsoft Visual Studio 2010 and I'm using MFC and C++.
EDIT:
So, I've gone with MDI and will have one document that handles all the data to be shown. What I am stuck on now is how to create the multiple windows I want. I sublcassed CFormView to be the graph View of the document, and I am trying to create that window when I click a menu button. I was able to do it with a modal Dialog, like this:
void CDAQUniversalApp::OnScopebtn()
{
// TODO: Add your command handler code here
CScopeDlg dlg = new CScopeDlg(); //CScopeDlg is Subclass of CDialog
dlg.DoModal();
}
That worked, but not what I want, so I tried this, and it didn't work at all:
m_pScopeTemplate = new CMultiDocTemplate(
IDD_SCOPEFORMVIEW,
RUNTIME_CLASS(CDAQUniversalDoc),
RUNTIME_CLASS(CMDIChildWnd),
RUNTIME_CLASS(CScopeFormView)); //Subclass of CFormView
if (!m_pScopeTemplate)
return FALSE;
void CDAQUniversalApp::OnScopebtn()
{
// TODO: Add your command handler code here
CMDIChildWnd* pFrame = NULL;
pFrame = DYNAMIC_DOWNCAST(CMDIChildWnd, CWnd::GetActiveWindow());
CMDIChildWnd *pScopeFrame = (CMDIChildWnd*)m_pScopeTemplate->CreateNewFrame(pFrame->GetActiveDocument(), NULL);
if (pScopeFrame == NULL)
return;
m_pScopeTemplate->InitialUpdateFrame(pScopeFrame, pFrame->GetActiveDocument(), TRUE);
}
This just causes an unhandled exception. I really just bruteforced my way to that point finding various largely unhelpful sections of documentation code and modifying it to what I think I need.
Your different windows (for video display, data display and configuration) are actually all views (different view classes) for a single document, which manages the data (assuming the DAQ works on the video data?).
I suggest you pack your application into an MDI app, thus having a main window, with all those different views as subwindows. So you have multiple views for a single document (or even multiple documents in MDI).
MFC can be a pain, if your application does not fit the classical document/view architecture (like Word for example), but I think this would be the best way to fit your application into this framework.
I would like to use c++ without mfc(and not clr) in order to modify textbox's and activate a button on a form outside of my project. I don't know where to start. I've done a lot of searching but can only find information for VB. A starting point would help.
Thanks.
I tried this and it doesn't seem to work.
HWND fWindow = FindWindow(NULL ,(LPCWSTR)"title");
and I also tried this
HWND fWindow = FindWindow(NULL ,LPCWSTR("title"));
I ALSO tried using LPTSTR instead of LPCWSTR, incase it was a unicode deal.
Maybe I don't understand this microsoft LPCWSTR and LPTSTR crap.
I also tried
HWND fWindow = FindWindow(NULL,TEXT("title"));
and that didn't work.
I guess the windows api must just be broken.
I tried the function on other programs...I'm using xp and I tried catching the calculator, and an explorer window, and something else. But I got nothing.
Heres some of the exact code I'm using to try and figure this out.
HWND face = NULL;
face = FindWindow(NULL,TEXT("My Computer"));
LPSTR title = TEXT("");
GetWindowText(face,title,250);
if(face != NULL)
{
MessageBox(NULL,title,TEXT("WOOP"),1);
}
face = nothing.
title = ""
Bear in mind, I'm not actually trying to hook explorer, I just want to figure out how to get it to work.
Use spy++ or winspector to see the actual "text" of the window.
(Strictly speaking, the caption of the window need not match it's window text. Especially true of "fancy" windows which paint their own caption.)
The following works fine for me (using Calc.exe to test).
HWND hwnd = NULL;
hwnd = FindWindow(NULL,_T("Calculator"));
TCHAR title[251];
if(hwnd != NULL)
{
GetWindowText(hwnd,title,250);
MessageBox(NULL,title,_T("WOOP"),MB_OK);
}
else
MessageBox(NULL,_T("No such window."),_T("OOPS"),MB_OK);
Edit: You should have used _TEXT instead of TEXT.
One way to do this is to use FindWindow to get a handle to the form. Then if you know the button and edit window Ids, you can use GetDlgItem to get their window handles. If you dont know the ids, you can use EnumChildWindows to examine all of the controls on the form.
Once you have the window handles for the controls, you can use SetWindowText to set the text on the edit control, and send a WM_COMMAND message to the form window with the button ID as the command value to make the form think that the button has been clicked.
There are a lot of ways to go about this once you have the correct window handles. There are security issues when you use the window handles of another process, but if the process isn't secured, then inter-process use of window handles just works. For a secured process, you won't be able to find out the window handles.
The windows API provides Methods for this. These should be independent of MFC and CLR, as they are plain win32. I had a project once accessing the Form fields of an Applictation from a loaded DLL (don't ask why).
you might want to look here (Codeproject)
or here (msdn)
At first, you need to obtain a handle to the process you want to access.
When have this, you can use GetDlgItem() (search msdn for that) to retrieve a handle to the desired textbox.
With this handle, you should be able to modify the control in question.
If your trying to get big (and do some more UI automation), you sould have a closer look at these:
Microsoft Active Accessibility
IAccessible2
Microsoft UI Automation
Windows Automation API (Win7)
The Windows API provides an API GetDesktopWindow( ) which returns the window handle
But I tested with Spy++ and I find that the window handle of the desktop and the window handle of the "Windows Desktop" is not the same.
As the "Windows Desktop" is a list view, do I need to do the following
1) HANDLE hWnd = GetDesktopWindow() ;
2) FindWindow(hWnd, ..... ) with the SyslistView32 as the Window class.
Once I get the Window handle, I want to use SendMessage() for operations like getting selected file name, the number of files selected , etc.
Please give your opinions. I am doing this using the Windows SDk
In light of a recent discussion on Meta complaining that questions like this one have "not been properly answered", I'm going to try and give answering this one a whirl. Not to imply that I think meklarian's answer is bad—in fact, far from it. But it's clearly been deemed unsatisfactory, so perhaps I can fill in some of the additional details.
Your problem results from a fairly widespread confusion over what the desktop window actually is. The GetDesktopWindow function does precisely what it's documented to do: it returns a handle to the desktop window. This, however, is not the same window that contains the desktop icons. That's a completely different window that appeared for the first time in Windows 95. It's actually a ListView control set to the "Large Icons" view, with the actual desktop window as its parent.
Raymond Chen, a developer on the Windows Shell team provides some additional detail in the following Windows Confidential article: Leftovers from Windows 3.0
[ . . . ] While in Windows 3.0, icons on the desktop represented minimized windows, in Windows 95, the desktop acted as an icon container.
The Windows 95 desktop was actually a window created by Explorer that covered your screen (but sat beneath all the other windows on your desktop). That was the window that displayed your icons. There was still a window manager desktop window beneath that (the window you get if you call GetDesktopWindow), but you never saw it because it was covered by the Windows 95 desktop—the same way that the wood paneling in the basement of my colleague’s house covered the original wall and the time capsule behind the wall.
[ . . . ]
This desktop design has remained largely unchanged since its introduction in Windows 95. On a typical machine, the original desktop is still there, but it’s completely covered by the Explorer desktop.
In summary, then, the window returned by the GetDesktopWindow function is the actual desktop window, the only one we had way back in Windows 3.0. The Explorer desktop (the one that contains all your icons) is merely another window sitting on top of the desktop window (although one that completely covers the original) that wasn't added until Windows 95.
If you want to get a handle to the Explorer desktop window, you need to do some additional work beyond simply calling the GetDesktopWindow function. In particular, you need to traverse the child windows of the actual desktop window to find the one that Explorer uses to display icons. Do this by calling the FindWindowEx function to get each window in the hierarchy until you get to the one that you want. It has a class name of SysListView32. You'll also probably want to use the GetShellWindow function, which returns a handle to the Shell's desktop window, to help get you started.
The code might look like this (warning: this code is untested, and I don't recommend using it anyway!):
HWND hShellWnd = GetShellWindow();
HWND hDefView = FindWindowEx(hShellWnd, NULL, _T("SHELLDLL_DefView"), NULL);
HWND folderView = FindWindowEx(hDefView, NULL, _T("SysListView32"), NULL);
return folderView;
I noted there that I don't actually recommend using that code. Why not? Because in almost every case that you want to get a handle to the desktop window (either the actual desktop window, or the Explorer desktop), you're doing something wrong.
This isn't how you're supposed to interact with the desktop window. In fact, you're not really supposed to interact with it at all! Remember how you learned when you were a child that you're not supposed to play with things that belong to other people without their permission? Well, the desktop belongs to Windows (more specifically, to the Shell), and it hasn't given you permission to play with its toys! And like any good child, the Shell is subject to throwing a fit when you try to play with its toys without asking.
The same Raymond Chen has published another article on his blog that details a very specific case, entitled What's so special about the desktop window?
Beyond the example he gives, this is fundamentally not the way to do UI automation. It's simply too fragile, too problematic, and too subject to breaking on future versions of Windows. Instead, define what it is that you're actually trying to accomplish, and then search for the function that enables you to do that.
If such a function does not exist, the lesson to be learned is not that Microsoft simply wants to make life harder for developers. But rather that you aren't supposed to be doing that in the first place.
If you want the Desktop window as defined in GetDesktopWindow(), use that window handle. This is the window handle you should use to look for top-level windows and other related activities.
What you're seeing in Spy++ is just the content drawn as the desktop in your session. If you use the auto-locate in Spy++, you'll see that the SysListView32-declared window is a child window of your explorer shell. It is quite infrequent for someone to need access to this window. Also, the existence of this window may be subject to changes between versions of windows.
Edit (additional info)
If you are looking to interact or place things on the actual shell desktop, you may be better served by other APIs. Here are two such APIs that can accomplish this, depending on the target version of windows.
Windows Sidebar # MSDN
This is available on Vista and Windows 7
Using the Active Desktop # MSDN
This is available on Windows 2000 and XP, although frequently disabled by users and sysadmins.