I tried to write a program for safe deleting files. However, I have a problem with deleting system files (recycle bin etc.). Now my question is. Which way to hidden files (from users) at this dialog. Other files I add to listview and then rewrite them zeroes. After that I delete this files without recycle.
The only way guaranteed to do this is to write your own open file dialog. But I'd advise that you find a better way of doing this, since that's considered pretty bad form.
It just occurred to me, but what you could do (and I'm not saying it's easy or nice) is launch the open file dialog, then using the handle to the window gain access to the listbox, and manually remove any system files from that list per your own heuristics. It should work, but I can't guarantee that the items will remain removed (i.e. I think Windows will auto-refresh every so often), so you'll have to experiment and YMMV.
Bottom line: find a different way of preventing the user from selecting them. Like Mat says, perhaps just give a message and leave it at that. Failing that, write your own dialog (yuck!).
Related
I'm new to rc files and I'm used to being able to close files in VS and be prompted to save or not save. This way I can quickly undo changes I've made to the file. How do I get similar functionality for rc files?
Thanks.
You can't! This is just one of the many infuriating things about both RC files and VS.
The only easy way I have found is to close the solution, discard the changes, and open the solution again.
I've got into the habit of editing resource files in a text editor most of the time. That saves a lot of pain. I also use Git, so it's often quite easy to revert any unstaged changes or cherry-pick those that I want to keep. The bonus is when I modify the resource this way, VS will detect it and prompt me to reload the file, discarding any changes.
I found one tricky workaround to do what you asked for without solution reloading.
Ctrl+Shift+F to open find dialog.
In the "Find what" field, type any text which should preset in the resource-file (for example, ID of some control).
Along with other files, records corresponding to your resource-file should be appeared in search results.
Double-click on any of this records. If the resource-file was opened (exactly as a resource file) at this stage, VS will inform you about this and ask you what to do: to close other editor or to leave all as it's. The first option is our goal.
I have preferences file for my application in Qt.
Whenever I launch the application it loads the file & depending the contents creates the widgets accordingly. I have given some customisation option for the user. Now when my application is closed I am checking whether the preferences are changed. If yes then I am opening the preferences file again & then just adding everything again in it. I am not creating a temporary file, I am directly editing the file. Is this method an efficient one? or am I doing it wrong? because I found these threads:
1. What is the best way to edit the middle of an existing flat file?
http://qt-project.org/forums/viewthread/25924/
Should use I binary file? Currently I am using ASCII file.
Thanks.
UPDATE: In the stackoverflow link above the correct answer has
If you're stuck using flat, then you're stuck using the old fashioned
way of updating them
I meant to ask whether the method I am using is old fashioned & is there a better method used nowadays? & what does flat file mean?
Don't try to edit the file. Rewrite the whole thing
Rewrite by using a temporary file. i.e. write the current state of preferences into temp file. And then move/rename the file to your actual preference file after making sure the temp file has been written successfully. This helps in case there is a crash when you rewriting the file. If you rewrite it directly, you will be left with neither the old one nor a good new one. In case you do it through a temp file, then do it this way ensures that in case of a crash, you atleast have a good preferences file(though it contains the old preferences).
Text/Binary doesn't make much difference unless it's a really huge file. Text will help to hand edit it if required.
That's a perfectly fine way of doing it. Since you already seem to have all of the preferences loaded into memory and you have edited them there, you don't need to bother with a temporary file (unless you want to ensure safety if your program fails during writing). Just write all of the preferences back into the original file.
Whether you choose a binary file or text file is up to you. Preferences tend to be text files because they have the added benefit of being human readable with just a text editor, rather than some specialised software for viewing them. A binary file may, however, have slightly better performance due to simpler decoding.
Vista introduced an interface: IFileDialog::SetFilter, which allows me to setup a filter that will be called for every potential filename to see if it should be shown to the user.
Microsoft removed that in Windows 7, and didn't support it in XP.
I am trying to customize the our Open file dialog so that I can control which files are displayed to the end user. These files are marked internally with a product-code - there isn't anything in the filename itself to filter on (hence file extension filters are not useful here -= I need to actually interrogate each one to see if it is within the extra filter parameters that our users specified).
I would guess that Microsoft removed the SetFilter interface because too often it was too slow. I can imagine all sorts of similar ideas to this one which don't scale well for networks and cloud storage and what have you.
However, I need to know if there is an alternative interface that accomplishes the same goal, or if I really am restricted to only looking at the file extension for filtering purposes in my File dialogs?
Follow-up:
After looking further into CDN_INCLUDEITEM, which requires the pre-vista version of OPENFILENAME, I have found that this is the most useless API imaginable. It only filters NON-filesystem objects. In other words, you can't use it to filter files. Or folders. The very things one would filter 99.99% of the time for a file open or save dialog. Unbelievable!
There is a very old article by Paul DiLascia which offers the technique of removing each offending filename from the list view control each time the list view is updated.
However, I know from bitter experience that the list view can update over time. If you're looking at a large folder (many items) or the connection is a bit slow (heavily loaded server and/or large number of files), then the files are added to the dialog piecemeal. So one would have to filter out offending filenames repeatedly.
In fact, our current customized file open dialog uses a timer to look at the view's list of filenames periodically to see if any files of a given pattern exist, in order to enable another control. Otherwise it's possible to check for the existence of these files, find none, but a moment later the view updates to have more filenames, and no events are sent to your dialog to indicate that the view has been changed. In fact, my experience with having to write and maintain code for the common controls file dialogs over the years has been that Microsoft is not very cluefull when it comes to how to write such a thing. Events are incomplete, sent at not-useful times, repeated when not necessary, and whole classes of useful notifications don't exist.
Sadly, I think I might have to give up oh this idea. Unless someone has a thought as to how I might be able to keep up with the view spontaneously changing while the user is trying to interact with it (i.e. it would be awkward to go deleting out entries from the list view and changing the user's visual position, or highlighted files, or scroll position, etc.)
You need to initialise the callbacks for your CFileDialog. Then you need to process CDN_INCLUDEITEM notification code to include or exclude items.
You can also check this great article. The author uses some other approaches in addition to callbacks
As you have already discovered, starting in Windows 7 it is no longer possible to filter out files from being displayed based on content, only file extension. You can, however, validate that the user's selected file(s) are acceptable to you before allowing the dialog to close, and if they are not then display a message box to the user and keep the dialog open. That is the best you will be able to do unless you create your own custom dialog.
I want to make sure no other process changes the contents of a particular folder. I'd like to stop other processes from creating, deleting, or modifying files within a folder. Further, I'd like this restriction to nest down into subfolders.
I can get close to what I want by enumerating the contents of the folder and calling CreateFile on each file. This has problems in that it doesn't stop new files from being created and requires I acquire lots of handles.
Is there an easier way to get what I want?
Update: Addressing some comments, what I want to do is to prevent modification while my program is running. It's OK if the file get modified between runs.
In terms of ACLS, the app has read access to all files within the folder.
ACLs would be the best way to go but if you can't get that to work for whatever reason (you're fairly thin on the details) then use a file system filter driver. Note that this isn't very straightforward. Not rocket science either, but you have to be extra careful with driver development.
http://www.microsoft.com/whdc/driver/filterdrv/default.mspx
Like when you drag a file on top of another one and change the order, like that.
I'm going to assume you're asking about how to rearrange the order in which files are displayed in a folder. I'm not exactly sure how to do it, but you'll want to use the various functions from the Windows shell to accomplish this. See the Shell Developer's Guide.
There is no way to do this (except maybe by hacking the directory structures on the disk using raw, sector-based APIs). The order of files on the disk is managed by the file system according to it's design and needs.
For what its worth, FAT directory entries are stored in the order in which they are added. NTFS actually indexes its directory entries, but I thought creation order still played some role in which order they're retrieved. Maybe not. Nearly every UI that does file listings does some type of sorting on display, though, usually alphabetical.
Bottom line-- if its not application-sorted and its not creation time, then there's nothing you can do.