This is my first time here. Anyway I have a question.
I just decided to try using Applescript studio, but currently I have trouble converting my script and linking actions to the GUI. I will provide more info if needed, but I just need to convert an applescript for use in Applescript studio. Is there any specific code I need to inject or something? Thanks.
Running on Mac OS X 10.6.8 Snow Leopard, Xcode 4.2
Using AppleScriptObjC in Xcode, the Interface Editor will use any handler with the right definition as an action method. An action handler takes a single parameter, which means that it has a single trailing underscore in the name - see the AppleScriptObjC Release Notes.
Once a handler has been declared, it will show up in the Interface Editor and can be connected by dragging from the Connections Inspector to the desired UI object, or by right-clicking on a UI object and dragging from the popup to the desired script class.
Example projects are a bit scarce, but a couple of resources to bring you up to speed are the introductory tutorials at MacScripter.net, and Shane Stanley's excellent AppleScriptObjC Explored ebook.
Related
On Mac it is usual that there is a "hidden" main window.
The usual example is "Text Edit". When you open a file you with you don't see a "main frame". Instead every single file will be opened in its own "Text Edit" instance. This is OSX way of emulating the so-called MDI interface.
However, there is an exception. If you open Xcode and open the project there, you can click on the file and it will be open inside the main Xcode window. And if you double click the file it will be opened in its own independent editor window, keeping the main Xcode window visible.
My question would be: do I need to do anything special in order to make my program behave like an Xcode? Should I use different class for the main frame or maybe react differently on the opening document event?
Any hints/pointers where to look or even to the official Apple documentation would be helpful.
The TextEdit behavior you're describing is much more like “SDI” than “MDI”, and the terms “SDI” and “MDI” weren't even needed until Microsoft invented MDI long after Xerox invented the SDI-type interface of which macOS is a derivative.
Anyway, I think you are misunderstanding Xcode's behavior. You seem to think “its own independent editor window” is a different kind of window than “the main Xcode window”. But in fact the new window is of the same kind as the old window, with some optional parts hidden. You can show those hidden parts and make the new window look exactly like the old window. Demo:
The ability to open multiple windows showing the same document (or, in Xcode's case, project) is a matter of software architecture. If you carefully design your app so that multiple windows can share a single model object graph, and can be notified and redraw themselves when the object graph changes, then you have an app that supports multiple windows showing the same document. If you want multiple kinds of windows showing the same document, nothing about Cocoa stands in your way. As a matter of fact, Xcode does have at least one other kind of window in which it shows some properties of a project:
That project settings sheet is really another window; macOS keeps it attached to the main window, but it is in fact an instance of NSWindow (or a subclass of NSWindow), no doubt with its own custom window controller that references the same project objects as the main window.
If you use the Cocoa NSDocument architecture, then a small amount of multi-window support is built-in: an NSDocument knows about its associated windows (via their window controllers). If you want to use the NSDocument architecture, you should read Document-Based App Programming Guide for Mac.
It is unclear what you are after. The traditional Mac UI has been one window per document - i.e. SDI with a single instance of the app running multiple windows - but there has always been the ability for any app to organise the content of that window as it sees fit, including showing multiple "documents" within one window - i.e MDI type UI.
Apps approach such "MDI" in different ways, e.g. some use panes (views) and others tabs. From macOS Sierra the standard NSWindow supports tabs, this system is (semi)automatic for standard document apps. Read Apple's NSWindow Automatic Window Tabbing section in the Sierra release notes for more details.
If you wish to use multiple panes - e.g. like Xcode - you just use views (NSView) and arrange them how you wish.
HTH
There is one application that controls Microsoft Word 2011 for Mac using AppleScript.
It does really nice things that I want to implement in my own app.
So, is it possible to intercept AppleScript calls to particular application, and reconstruct source code of AppleScript that made that calls?
It is impossible to view source code of applescript that executes on particular app.
But debugging apple events, can make sense to cast a light on what is going on.
So I just opened Terminal.app and executed a command:
env AEDebugReceives=1 /Applications/Microsoft\ Office\ 2011/Microsoft\ Word.app/Contents/MacOS/Microsoft\ Word
That will force Microsoft Word (in fact almost any application) to print all received apple events in terminal.
I'm working to an application for OSX and I would to add a new menu item on the menu shown when you click on a dock icon.
The menu isn't for my application but it must appear for all running apps.
I've found only this doc http://cocoadevcentral.com/articles/000036.php but it adds to its own app.
My app will run on OSX 10.6 or superior
You can't do that with the public API. You need to inject code into the Dock. In 10.6, the standard way to inject the code is to use the OSAX loading trick, described in this blog post for that. Then you need to do Objective-C runtime hackery to replace the method, using method_exchangeImplementations.
Anyway it's a tricky process. But if you have the will, you can. SIMBL might (or might not) help you.
I'm porting a UNIX application which uses the Qt framework (Qt, not QuickTime) to Mac/Cocoa. Life is good, generally. Qt has a Cocoa implementation, so with some Objective-C++, I've gotten lots of Mac-specific bits working.
I can't get the main menu (i.e., the Application menu) to translate. It's set using:
[NSApp setMainMenu:menu];
I've got my en.lproj, ja.lproj, fr.lproj, etc. folders set up, and they have InfoPlist.strings files. Qt handles the internal localization of application-specific menus. But if I switch languages, I still have "Quit Avogadro".
I've read through as much documentation in the Mac Dev Center as possible, but can't find an answer.
I know that strings in the mainMenu are handled by Cocoa -- they're not localized in any Apple application. Any ideas on the magic trigger? Any ideas for where to look?
Thanks in advance!
I wanted to add some information to this, in case someone else is looking to do this. I was also trying to modify the application main menu and I was attempting to set it in the awakeFromNib method. This never worked because according to this thread we need to modify the application main menu AFTER the menu has been set. Otherwise, the application will always use the title found in its Info.plist. So, this means that if you ever change your application's name, you never have to update your application's MainMenu.nib.
It turns out that this was a Qt bug: https://bugreports.qt-project.org//browse/QTBUG-4463
It's fixed in Qt 4.7 and later
Is it possible to embed Finder functionality in a cocoa app, now that Finder is itself cocoa (assuming the app were to function only in snow leopard)?
What I mean is to have a file browser pane as part of the app, actually browsing the file system itself (to edit in another pane), but without writing all the functionality of the Finder. Thanks!
The Finder itself is just an application. It is not a components library nor a framework. While you cannot "embed" Finder functionality in your application, you can influence Finder functionality and invoke Finder functionality.
First off, you can attach Folder Actions to folders. These will trigger when a user does something to the contents of a folder - for instance, they drop a file into it. You set this up in the Finder. You should to learn a little AppleScript, if interacting with the Finder is something you want to do.
Second, since the Finder supports AppleEvents, you can affect the Finder using AppleScript. Take a look at My First AppleScript and My First AppleScript Part II to see how to do this. Here is much more in-depth information, in AppleScript Overview: Scripting with AppleScript. Here is some More Finder Scripting.
Third, there is also support for developing ways for the Finder to do complex things for the user at the click of a button, using Automator (Mac OS X 10.5). You can also create a Service in Automator, beginning in Mac OS X 10.6 ("Snow Leopard"). Take a look at Automator and Finder Actions in Mac OS X 10.6 for an introduction to this latter technique.
Even though Finder windows themselves are not an embeddable component, if you really want to provide the ability to pen, Print, Delete, Duplicate, etc. Files/Folders, and navigate from Folder to Folder, you can develop a simple Folder browser in your application.
It should not be a huge amount of work to do this so long as you do not set your sites on mimicking the finder or duplicating all of its functionality, just the essential basics I have mentioned.
You would need to know how to program the Macintosh, however - not just use AppleScript. The normal way to do this would be to learn the Objective-C programming language and the Cocoa framework. You would need to get familiar with writing applications using a Model-View-Controller architecture.
You would create a subclass of NSObject named something like MyFile, and a subclass of a collection class named something like MyFolder. When the application creates the browsing Windows, and each time the application activates (becomes the frontmost application), you8 would refresh the contents of the browsing menu.
You could put a menu in your menu bar with commands in it: Open, Print, Delete, Duplicate. When the user does one of those commands, your application performs the appropriate actions itself or sends the request to the Finder. After the action has been completely carried out, then you refresh the browsing window for currently displayed Folder, or newly displayed Folder if the user navigated to a different Folder.
If you are familiar with design patterns, object-oriented programming, and frameworks in general - reading up on Cocoa Design Patterns will speed your learning curve immensely.
These are various techniques you can use to harness some of the power of the Finder. As you look these over, I suggest getting very clear in your mind just what benefit this brings to the user of your application. Writing down what the overall objective of this feature is, and what commands you wish to support, will make it easier to choose the path you take in developing it.
The user can always click on a Finder folder window at the click of a button, since Finder is always running. So avoid simply duplicating that functionality for its own sake. Focus on the benefit you are providing the user. Make sure that you do handle the situations where the user updates the Folder you are showing the contents of from another application and then switches back to your application.
No, they have not made Finder simply a host for a framework, like Preview. You still have to write this yourself.