I have an application written to process files dropping using WM_DROPFILES. And later I decided to add an OLE IDropSource to application so users can DnD an icon to other applications to open that opened file in other applications.
And I want to prevent users DnDing that icon on same window (to prevent file opening accidentally), any ideas?
Related
On Windows, how do I get my app to tell another app to open a file that I just generated. For example, "WordPad, please open 'foo.rtf' that I just made." Or Word, or other big apps that may already be open with other files. I have to assume that the app may or may not be open already.
Alternatively, if I could only do the equivalent of double-clicking the file, so as to open it with its default application, that would still be all right.
Depends on how your application handles opening other files.
One would think that assuming filetype associations are configured properly in Windows, it should know what application to open .rtf files with (per your example).
In powershell, you could use gc if you're only looking at plaintext data.
http://www.ats.ucla.edu/stat/mult_pkg/faq/general/powershell_examples.htm
In Python, you would handle the file as an object, per the example here:
https://docs.python.org/2/tutorial/inputoutput.html#reading-and-writing-files
But if you wanted to launch a specific secondary application to open the file, you might try running an outside program (executable) in python?
I've implemented a user mode program and a Windows file system minifilter that creates a skeleton view of users files for a remote file storage system. It maps the remote files to the local drive. The user mode program creates a reparse tag for each file on the remote system. When a create request (e.g., CreateFile for read) is detected, the minifilter asks the user mode program to download the file. This should only happen when a program wants to open the file for viewing or editing.
But, I'm finding that Windows Explorer is triggering my files to download. I'd like to prevent the Explorer File windows and File Open/Save dialogs from
triggering downloads. And, I also want to display the file thumbnails and file
size.
[Update: I've found I can use Windows sparse files to show my remote
file size in Explorer. ]
Therefore, I have also implemented a Shell Extension, IThumbnailProvider, that downloads a rendition of the file. This provides the file thumbnails.
For my testing, I've registered the IThumbnailProvider for all files (*) and for .jpg files.
I'm seeing two interesting behaviors using a combination of Process Monitor and DebugView (both from SysInternals):
1. If I make my minifilter reject requests to open the file from Explorer, then my IThumbnailProvider is invoked.
2. If I permit open requests from Explorer, I see thumbcache.dll in the call stack trying to open the file and my IThumbnailProvider is not called. It appears that the default thumbnail provider reads the downloaded file and creates the thumbnail.
I must be missing something.
Update: if I use InitializeWithStream instead of InitializeWithFile, it appears my handler is invoked. But, that also triggers a download of the file.
There are many shell extension types which can access to your files. Icon handler can read file to create icon, Info tip handler can read file to create text hint, Data object handler can read file to create clipboard data and so on.
Questions from developer with the same problem: first and second. Solution was to create namespace shell extension. NSE can control all access to your files.
I want to write a custom save as dialog that is hooked into the File -> "Save As" of most Windows program. This custom dialog will allow the user to enter their username, password, destination folder and uploads the file to the web server via a POST. If the user clicks cancel, it will call the original file dialog.
I've been reading up about Windows API hooking and this is vaguely how I think I would approach this:
Intercept "Save As"
Display my custom dialog, return some temporary path on the drive
Let the program write file to the temporary path, assume it calls WINAPI CreateFile(...) for now
Read the temporary file and upload to web server
Clean up temporary file
But I still can't get my head around the steps required to pull this off. Assuming I can intercept the "Save As" and CreateFile function, how do I detect the CreateFile was called from a "Save As" and not just any random file creation? I can think of a hack where I keep track of the time difference of when the File dialog got open and CreateFile got called.
My alternative solution is to use the existing file dialog and create a special folder on the disk, that is constantly monitored. When a file gets written there it will call an external program that uploads the file. I haven't looked into how to do this yet. I suspect this is easier.
UPDATE
As a first baby step, I wrote a .NET task tray application that allows the user to enter their login details and a folder to monitor. Whenever a file gets dropped in there there it will upload to the web server. So far it seems to work. Now I just need to figure out how to add a nice shortcut to the left pane of the file dialog. Once that's done I think I got a solution I'm happy with.
There is no need to hook or patch anything. Create a shell namespace extension that supports IStorage::CreateStream and implements it by returning a stream that POSTs its data to the Web server. The user can then choose to save the file to your namespace extension in order to upload the file.
Hooking the standard save dialog requires you to inject a DLL into every running process and have it replace the import stub of the the Win32 API GetSaveFileName() function in the process's PE header (something anti-virus and anti-malware apps are not likely to be happy about).
Then there is the new-style save dialog that was introduced in Vista using the new IFileSaveDialog COM interface instead of GetSaveFileName(). For that, you would have to uninstall and replace Microsoft's default FileDialog COM object with a custom implementation.
That does not count custom-made save dialogs, which you are not likely to hook.
If, by some miracle, you can hook the dialog and have it return a custom path of your own creation, you don't need to hook CreateFile() itself, Just monitor the folder that you create for your purposes. Place it where it is unlikely that any other app (or user) besides you will write files to. You can create a custom subfolder in the user's or system'ss AppData folder for that purpose. You can use SHGetSpecialFolderPath() and/or SHGetKnownFolderPath() to find those folders.
The tricky part will be detecting when the file is finished being written to and has been closed. You will have to monitor the folder for changes, such as with ReadDirectoryChangesW() or SHChangeNotifyRegister(), and periodically open new/modified files for exclusive access. If a file is still open by someone else, you won't be able to open it yourself. But once you do open it, you can do whatever you want with it.
My requirement is to open a file like pdf/ppt etc and close it after 20 minutes. I am able to open the files appropriately thanks to NSWorkspace. But how can I close the files ?. NSWorkspace does not seem to have a close method.
NSWorkspace just asks the operating system to open the file, it doesn't maintain any connection to the file at all. The OS will open the file with whatever the default application is for that file type, unless you specify a particular application to use. Anything that happens with the file after that point is completely outside of your application's control because the file is being managed by another process.
You would need to use either AppleScript/Apple Events or the Accessibility Framework to control whatever application currently has the file open and ask it to close the file, but there is no guarantee that it will do so.
The only way to guarantee that you will be able to close the file is to open it in your app. Obviously, this is impossible if you need to open a variety of diverse and possibly proprietary file types.
We have a VB6 application here that automates the process of opening drawings and printing them with a specific printer that turns them into TIFF files.
I'm in the process of testing the application as we upgrade from V8 to V8i and I'm running into some problems just launching the application.
If I open the Microstation normally via the exe file everything works ok. But when I do:
Set msApp = CreateObject("MicrostationDGN.Application")
It opens a blank microstation window with no menus or anything (basically what the window looks like behind the file open dialog)
And then I do
msApp.OpenDesignFile ("dummy.dgn")
that looks like this: imgur.com/A5rc4.png
Is there something new with v8i where it doesn't bother loading the gui when opened as an object?
Did your application depends on some user preference of Microstation? I think you can debug your aplication step by step.
You can call the ustation.exe with the parameter -debug. This creates a file called debug.txt in the current working directory.
There you might find some helpful info.