I'm trying to process the Ctrl+Z ( Undo Delete ) context menu action in my namespace extension, but I'm having trouble finding a way to do this.
I see in the doc that one needs to implement FM_UNDELETE_PROC, but no details on how to register this callback.
Also tried to set a Shell hook, but no relevant messages arrive there.
Any thoughts?
Also, how would one register a delete operation so the explorer would allow the Undo to take place.
Now it appears if I do this from another location.
Thanks,
David
Windows has per process (prior to Vista) or global file operation stack. If you use API functions like SHFileOperation or IFileOperation interface you can pass FOF_ALLOWUNDO flag BUT this flag is ignored if the source file parameter does not contain fully qualified path and file names. It means if you want use system file operation stack your shell extension objects MUST have SFGAO_FILESYSTEM attribute and you MUST return valid file path and name when IShellFolder.GetDisplayNameOf is called with SHGDN_FORPARSING parameter. Also it is necessary to implement ITransferSource and ITransferDestination interfaces. So if objects don`t not have SFGAO_FILESYSTEM attribute you must use your own implementation of operation stack.
Undo Delete command in background context menu of folder or in Edit menu is system command and it has no any relation to your shell extension. And you should not process the Ctrl+Z manually.
Related
Say I use the DebugUtils object to set the name of a logical device, i.e. a vk::Device. How can I trigger a validation message involving the object to test that the name matches my expectation?
You need to forcefully do something that the validation layers pickup. E.g. creating a buffer with a wrong alignment or flags.
Another (better) option is to run your application through RenderDoc. It'll display debug names in the trace, so you can easily see if naming of e.g. the device worked properly. You can find all Vulkan resources in the "Resource Inspector":
I have driver, that construct and return some data on IRP_MJ_READ request.
I use some symbolic link to open and read device, associated with driver.
The symbolic link is something like \\DosDevice\\Name1.
I want to use same device to get another data from same driver.
How can driver determine, which type of data it would return?
I think, if this is some way to use another symbolic link (for example: \\DosDevice\\Name2) to the same device for split requests for first type of data and requests for second type?
Else if this another way, to pass some identifying information together with thre IRP_MJ_READ?
no, you can not determinate which symbolic links used and are it used at all for open file on your device. and you not need try do this at all. this is wrong way.
when user open file on your device it specify some file name. and you can and must use this name - based on it - return different content on IRP_MJ_READ.
say your device named as \Device\MyDevice. user can open file, for example, with next names : "\Device\MyDevice", "\Device\MyDevice\" "\Device\MyDevice\Name1", "\Device\MyDevice\Name2". as result you, in your IRP_MJ_CREATE will be view next FileObject names : "", "\","\Name1","\Name2" and you, base on file name, can associate different context with file object and then use this context in IRP_MJ_READ and another points. also user can pass additional information on create by using Extended Attributes (EA) and AllocationSize
and as general note - for what use symbolic links to device at all ? why not open it direct by name ? and use IRP_MJ_READ exist sense only if you can handle this request asynchronous or pass IRP to lower driver. in case, if you always synchronous complete request - much more better use FastIoRead handler
also instead on handle read request based on file name, you can use parameters: are you using ByteOffset now ? if not you can use it for distinguish. if you use ByteOffset now, are Key parameter in use ? almost sure that no. in this case you can for Key==0 return some data, for Key==1, some another data, and so on. for use Key you need use NtReadFile instead of ReadFile in user mode.
also you can use IOCTL instead read file for return data, etc. without more knowledge about your driver and it communication with user mode hard say which is better. but formal answer - you can and need use FileName for distinguish which data need return on read
The NSDocument system is primarily for files that read and write a particular data type. What about a type that needs to be both read-only and read-write? I'm planning an e-mail app; it would need a read-write document type for composing messages before sending, and a read-only type for reviewing already sent messages (from a Sent Items folder). The Mail.app works like this.
Would this be done as two NSDocument subclasses? (They would use the same RFC822 class for their model class.) How would you make one document type read-only?
It's still one document. You just have a different UI that you display for editing.
In the case of email you would only display editing from New or Reply/Reply All/forward action methods. (Quoting the original mail as appropriate. )
You could technically go and open the "read only" mail file in any editor that can open the file.
One of the easiest way would be to create one BOOL sayingisReadOnly`.
If its value is YES(readonly mode) make the NSTextView readonly, if it is NO(edit mode) make it default one i.e, read & write enabled.
The following will work as per your BOOL isReadOnly; value
[self.yourTextView setEditable:isReadOnly];
I'd like to create a new stub file "test.mp3" for instance, and add a Window Property to it ( System.Author for instance).
the solution must be usable for several file extension as text, picture, videos, etc...
If I just create a file and use IShellItem2::GetPropertyStore I get a HRESULT fail for invalid Arguments.
Use IShellItem2::GetPropertyStore on a real music file I can read and write Its properties just fine.
Please test your suggestions first.
Property Stores typically access and store data within the file itself. In your case of a mp3 file, it would be attempting to read and write the ID3 tags. Also, Property Stores are not stored in a database and cannot be arbitrarily added to files that don't support it.
You'll most likely need to implement your own property handlers to do what it appears you're trying to accomplish. For types that already have handlers, you'll have to replace the system handlers with your own.
The most likely reason your mp3 test is failing is that you have an empty file with no data and no valid ID3 tags.
I have an addon that every 5 minuets or so checks an rss feed for a new post, and if there is one, it displays an alert(). Problem is, I'm afraid that if the user opens multiple windows, that when there's a new post a millions of alerts will popup saying the same thing. Is there anyway to have just one "brain" running at a time?
Thanks in advance!
Look up something called "Javascript shared code modules" or JSMs.
Primary docs are here:
https://developer.mozilla.org/En/Using_JavaScript_code_modules
Each .js file in your addon that needs shared memory will open with the following line:
Components.utils.import("resource://xxxxxxxx/modules/[yourFilenameHere].jsm", com.myFirefoxAddon.shared);
The above line opens [yourFilenameHere].jsm and loads its exported (see below) functions and variables into the com.myFirefoxAddon.shared object. Each instance of that object loaded will point to the same instance in memory.
Note that if you want to have any hope of you addon making it past moderation, you will need to write all your code in a com.myFirefoxAddon.* type object as the goons at AMO are preventing approval of addons that do not Respect the Global Namespace
The biggest caveat for JSM is that you need to manually export each function that you want to be available to the rest of your code... since JS doesn't support public/private type stuff this strikes me as a sort of poor-man's "public" support... in any case, you will need to create an EXPORTED_SYMBOLS array somewhere in your JSM file and name out each function or object that you want to export, like this:
var EXPORTED_SYMBOLS = [
/* CONSTANTS */
"SERVER_DEBUG",
"SERVER_RELEASE",
"LIST_COUNTRIES",
"LIST_TERRITORIES_NOEX",
/* GLOBAL VARIABLES */
/* note: primitive type variables need to be stored in the globals object */
"urlTable",
"globals",
/* INTERFACES */
"iStrSet",
/* FUNCTIONS */
"globalStartup",
/* OBJECTS */
"thinger",
"myObject"
]
[edited] Modules are not the right solution to this problem, since the code will still be imported into every window and the whatever listeners/timers you set up will run in every window. You should be careful with using modules for this -- all the timers/callbacks must be set up in the module code (not just using the observer object defined in the module) and you shouldn't use any references to the window in the module.
The right way to do this is I would prefer to write an XPCOM component (in JS). It's somewhat complicated, yes and I don't have a handy link explaining how to do it. One thing: implementing it using XPCOMUtils is easier, older documentation will throw lots of boilerplate code on you.