What are my options, if any, of adding additional, arbitrary data to the standard Cocoa about dialog that is displayed by an NSApplication when it receives a orderFrontStandardAboutPanel message.
If you add a file named Credits.rtf to Resources the contents will automatically be used in the expanded standard about panel and you can put whatever info you want in the file. It will still pull the standard copyright, version info, etc from the info.plist. It is the easiest way I know of to add arbitrary info, otherwise you pretty much will have to roll your own about panel.
-[NSApplication orderFrontStandardAboutPanelWithOptions:]
Expanding further on the answers from Darrell Root and theMikeSwan above, Apple's documentation for the credits property of NSApplication.AboutPanelOptionKey states:-
The value of this key is an NSAttributedString displayed in the info
area of the panel. If not specified, AppKit then looks for a file
named “Credits.html”, “Credits.rtf”, and “Credits.rtfd”, in that
order, in the bundle returned by the Bundle class method main. The
first file found is used. If none is found, the info area is left
blank.
Expanding on theMikeSwan's answer, by accident I found that if you add a file named Credits.html to the Resources folder, it's contents get used in the expanded standard about panel. In fact Credits.html appears to override a Credits.rtf.
So your choice whether to use html or rtf format, or wire up "About" to a completely different custom window controller.
Related
I am trying to intergrate our input method to the 10.10.3
And I found it's not easy to act like SCIM.app as the pic shows
I opened the activity monitor to see what file it opened (the SCIM.app was not running) As you can see in the following images:
The left shows the file list opened by System preference, and the right shows after I click the pinyin-chinese, the file list opened.
So I guess the little view was created by CoreChinese.framework. Since it was in /System/Library/PrivateFramework , It seems impossible for me to show this view as SCIM.app by a normal way.
I turned to nm and hopper disassembler...But I found it a long way to go
I guess you guys may encounter the same question, maybe you can help me.
Yes, I came across the same problems with yours.
1.It's easy to know that the view you saw, is provided by two part, the upper keyboard is a webview, which takes data in /System/Library/Input Methods/SCIM.app/Contents/Resources/*.keylayout, and finally shown by IntlKeyboard.prePane located in resources directory of Keyboard.prePane. and also you can find the actual html and pics, and 2nd part is a self-defined view provided by Preferences.prefPane.
2.Then 2nd part is to show the view you saw under the keyboard. as SCIM.app does, a file named Preferences.prefPane(must in the Resources directory of SCIM.app) was taken by IntlKeyboard.prePane.
How do you export a NSDocument in one format into another NSDocument in another format?
I would like to implement the typical Export option in my document-based app. I'm not sure where I should put the format conversion code, and what is already provided by Cocoa.
All the writing options in NSDocument get a string parameter to specify the type of file that should be written. So in your dataOfType:error: or fileWrapperOfType:error: methods you should implement the conversion code for each file type you want to support.
To start your export operation you can use the method saveToURL:ofType:forSaveOperation:completionHandler: with the desired type and a save operation of NSSaveToOperation.
For more information on the methods you can override to support loading and saving document data take a look at this programming guide.
You can get the available types from the class method writableTypes or the instance method writableTypesForSaveOperation:, again with NSSaveToOperation.
The file types you want to support need to be declared in your Info.plist file.
If your NSDocument subclass supports in-place autosaving, and all writable types are also readable (as they should be), I would recommend to use the already provided type-conversion workflow, where the user should use "Duplicate" followed by "Save".
In this workflow, when the user "Duplicate" the document, it's written/copied to a temporary file (where autosaved files are saved) as an untitled document. When the user closes the document window, the app suggests her to save the document or delete it. Since the document has no permanent URL yet, an NSSavePanel will appear with an accessory view that lets the user to select the document type.
In this solution everything is already provided by Cocoa and you don't have to do anything to support a special "Export" functionality as the user can use "Duplicate" followed by "Save".
You only have to be able to save your document to all writable types from dataOfType:error: or in fileWrapperOfType:error: according to the typeName argument (as Sven said).
The advantage here is that the user has to choose the URL only when she closes the file (and chooses not to delete it) - and is compatible with the new workflow in document-based apps where the "save as" operation has been replaced by "duplicate" followed by "save".
Note that you also have to make sure that you can duplicate documents of non-writable documents (you can achieve that by copying the original file instead of using writeSafelyToURL:ofType:forSaveOperation:error:).
How can I change the order of the entries in the context menu?(e.g. for Directories) I need to know how Windows determines the order when showing that so I can control it. For example I want to place my custom action at the end of the context menu list
Thank in advance!
My Google-fu led me to this:
So the sorting is based on the following elements in decision order:
Key priority (eg, txtfile, *, AFSO)
Registry Enumeration order of shellex\contextmenuhandlers with a special case for static verbs always being first
IContextMenu Implementation order
So if there is any contention for position, there is no consistent way for an extension to guarantee their relative position within the menu.
Obviously you can't do anything about phase 1. Phase 3 only applies to the verbs implemented in your handler. That leaves phase 2. The only thing you can do is name your entry under ContextMenuHandlers such that it would be enumerated first, but nothing's stopping someone else from doing the same thing.
This is for Windows 7, maybe same for newer versions. It was inspired by the other answers, all is affecting the order.
I'm explaining entries for "*" (all files), but the same goes for special extensions.
I take no responsibility for any changes made in registry!
There are three sections in the context menu, as it says in How to Change the Order of Options in Context Menu (from answer by #Anonymouse)
They call them:
2 - Default menu position (at the top).
1 - Send to, copy to folder and move to folder menu part (in the middle).
0 - Rename menu part (at the bottom).
Within these sections the position is decided by the rules in answer by #Luke
The easiest way to change the order within the "section" is to change the name of the registry key under HKCR-*-shell or HKCR-*-shellex. All under subkey shell will be before them under shellex. Keys that have the CLSID as the key name will be as last entry since they are last in the used order.
As an example, I was following a sample from MSDN to build a Context Menu Handler
EDIT 2021-04-14:
The MSDN link is no longer valid, it redirects to a "Browse code samples" page. You can search there for Context menu sample, but the one I followed seems to have been removed.
The closest to the old one I followed is perhaps this
The one I followed is using the CLSID as the name for the key under shellex, and a "friendly name" as default value. It was placed at the bottom of "section" 2 (top section). I changed the key name to something like Asample and changed the default value to be the CLSID instead. Now it was directly after entries under shell.
There are some more ways of changing the order.
For keys under shell you can add the value Position with string data Top or Bottom. Not possible to decide in what "section".
For keys under shellex the value Position has no effect. Instead it's possible to decide in what "section" the entry will be using flags, described in the link above.
Use the CLSID for the shellext you want to move. It's like
{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}. Get it either from the key name or the default value, it depends on how the entry is done.
Find the entry under HKCR-CLSID, the key has the name of the CLSID.
Add a value with name flags and data DWORD with the "section" number described above under the found CLSID.
This did it for me... Steps 4 through 7 - setting the "flags"
http://techoqueries.blogspot.de/2012/08/how-to-change-order-of-options-in.html
This Q&A shows a simple way to CREATE (not move) an item within the context menu. I managed to duplicate an existing item. Then I moved my item to a higher and more accessible position within the context menu, by renaming the key to start with something "aMyItem" or "0MyItem".
I've been trying to find a way to re-order things, it irritates me that the daily use options are pushed to the end, when obscure utilities you might use once in a blue moon are filling up the top of the list.
I found a lazy way to do this, using a little utility package called "Windows 10 Manager" Windows 10 Manager - it's a few quid, but it's a lot easier than registry hacking. It can't do everything, but it does let you add items into the top section at least - and also to suppress cheeky ones that installed themselves in there without asking.
As you can see, it's actually duplicated some entries rather than moving them, but never mind.
Is there a way to add an item that doesn't point to a file that exists on the file system to the "Open Recent" menu?
In an application not based on NSDocument, I can add an item to the "Open Recent" submenu with the following code:
[[NSDocumentController sharedDocumentController] noteNewRecentDocumentURL:[NSURL URLWithString:stringToFilePath]];
It works as documented, as long as the URL points to a file that exists on the file system.
If the url doesn't point to a file on the system, such as a web url, or a custom url scheme, nothing happens.
For example, this code has no effect, and produce no log during execution, even if my app handles the scheme used in the URL:
[[NSDocumentController sharedDocumentController] noteNewRecentDocumentURL:[NSURL URLWithString:#"http://www.stackoverflow.com"]];
Update: someone found (a long time ago) a way to tweak this menu to have it show files whether they exist or not: http://lists.apple.com/archives/cocoa-dev/2007/Apr/msg00651.html
I successfully managed to subclass NSDocumentController, but my override of the method - (NSArray *)recentDocumentURLs is never called.
It's not very surprising, as the doc says:
This method is not a good one to
override since the internals of
NSDocumentController do not generally
use it.
But the doc doesn't say what to use instead and the poster didn't give more detail. Any idea?
If there is no solution, on workaround would be to rewrite the entire menu from scratch.
If possible, I would prefer to avoid that, for all the stuff I get for free (like when you have two items with the same name, it displays the parent directory as well to help differentiate them).
It looks like you'll probably have to create your own menu and maintain your own separate list. This menu automatically excludes files that don't exist.
I believe this is also true of files on removable media that is absent (ie, if the media comes back, the I believe the file is once again available in the list if it hasn't been pushed off by more recent items).
Does this control have a name? Or is it just a bunch of simple controls merged together? If so, what controls are they?
http://img8.imageshack.us/img8/3002/picture2xrb.png
It looks like an NSTableView with an a custom cell type and no column header. Have a look at the documentation for NSTableView's tableView:dataCellForTableColumn:row:. For columns which have the same type for all rows you may also set the cell class in interface builder.
I doubt the search box is part of the same control.
You could open the Application's Nib file to see what is in there. Look inside the application bundle. If the application is called Example then you should be able to find the Nib at Example.app/Contents/Resources/English.lproj/MainMenu.nib.
The best tool for investigating this is fscript, specifically FScriptAnywhere which will let you determine the class and much other information about any visual element of any Cocoa program (and do a lot of other interesting things with Cocoa programs).
In addition to what toholio said, an easy way to get the look and feel of the bottom button bar is with BWToolkit.