explorer

I would like to drag and drop an element of a listbox to explorer. When the drag and drop is started, I need to prepare the file on demand and save it to a memory stream. Can you provide me with an example on how to do it using the FileGroupDescriptor data structure? Thanks. Andrea you can find an example on how to do this here Transferring Virtual Files to Windows Explorer in C# ; also some good info on the topic here: Outlook Drag and Drop in C# In short what you have to do is to init the DataObject with FILEDESCRIPTOR (you can find its declaration details on pinvoke.net) structure(s) for

How does Windows Explorer determine the "Date Modified" field for folders? [Aside: I know this is asking from an explorer-specific perspective, but the behaviour could be useful to coding search/sort type activities] Is there a definitive description of this anywhere - searches of Microsoft, MSDN, Google & Stack Overflow have been unsuccessful. Personal experiments seem to suggest that in a tree of folders: when a folder/file is added/deleted in a folder, the containing folder's date modified is updated. when the content of a file is modified, the containing folder is unaffected However, I'm

I have a file listing in my application and I would like to allow people to right-click on an item and show the Windows Explorer context menu. I'm assuming I would need to use the IContextMenu interface, but I'm not really sure where to start. Rowland Shaw There's a very good tutorial (albeit in C++) about hosting an IContextMenu on Raymond Chen's blog in 11 parts (in order): Initial foray Displaying the context menu Invocation location Key context Handling menu messages Displaying menu help Invoking the default verb Optimizing for the default command Adding custom commands Composite

I'm working on a windows shell extension, and unfortunately, when making changes to the DLL, I must restart windows explorer (since it keeps the DLL in memory). I found this program from Dino Esposito, but it doesn't work for me. void SHShellRestart(void) { HWND hwnd; hwnd = FindWindow("Progman", NULL ); PostMessage(hwnd, WM_QUIT, 0, 0 ); ShellExecute(NULL, NULL, "explorer.exe", NULL, NULL, SW_SHOW ); return; } Does any one have something they can share to do this? P.S. I realize that I can go to task manager and kill the explorer process, but I just want to do it the lazy way. Besides, this

I am displaying a list of files; i.e. xls, doc, pdf, odt etc., in my Java application (Eclipse RCP). When the user clicks on the file, I want to launch the appropriate (according to what the OS thinks) native application, just like it happens in Windows Explorer or the Finder. And while I am here: It would be nice to also display the same icons that Finder or Explorer use for the different file types. Is there a library or Eclipse plugin for this? Joseph Gordon What you want is java.awt.Desktop : Desktop.getDesktop().open( file ); I have found an API in Eclipse's SWT now that seems to do the

In Vista/7, the Windows Explorer shell window makes use of a special kind of static progress bar to display hard drive space. With default styles, this bar is blue colored and non-animated. It also turns red colored when it gets close to being full (low disk space). Using messaging, I can tell the Windows Forms ProgressBar control to update its state to Paused and Error (yellow and red colored, respectively), which works fine, but these are still specific to progress. In the Windows User Experience Guidelines , it specifically points out this "meter" variant of the Progress Bar: This pattern

How do you gracefully close Explorer programmatically? By that I mean, how do you invoke this function programmatically: Edit: Typo in the picture, it should say "Ctrl-Shift-Right-Click" instead of "Shift-Click". I debugged this out of curiosity. All it does is post a message to one of explorer's windows: BOOL ExitExplorer() { HWND hWndTray = FindWindow(_T("Shell_TrayWnd"), NULL); return PostMessage(hWndTray, 0x5B4, 0, 0); } Of course this is an undocumented WM_USER message so the behavior could quite possibly change in the future. @Luke: first of all, thanks for the detailed analysis and the