Delphi with mac os

Delphi XE 2. Приложения под Windows, Mac OS и iOS

Да, вам не показалось — в одном заголовке рядом Delphi и Mac OS. Не смотря на то, что многие на хабре, да и вообще, уже давно «похоронили» Delphi, её разработчики каждый год обновляют свой продукт и на этот раз — удачно…

Здесь можно было бы рассказать какая у Delphi интересная история, как всё развивалось и «завивалось», но не буду, все и так знают какая это история… Поэтому, лучше процитирую часть комментария хабрапользователя:

Ребята просрали все полимеры, однозначно.

Это в точности отражает, что происходило последние годы с Delphi. И кто с этим не согласится? Но вот недавно, была выпущена новая версия. С весьма заметными изменениями:

• 64-битный компилятор для Windows;
• поддержка Mac OS и iOS;
• FireMonkey;
• LiveBindings;
• FastReport;
• Documentation Insight теперь часть IDE;
• полный список.

Собственно, самое интересное это первые три пункта. О них и поговорим, а также сделаем программу в Windows, скомпилируем и запустим в Mac OS.

В общем-то, в плане интерфейса IDE мало что изменилось с последних версий и, это наверно хорошо, нет необходимости искать старые команды в новых меню. Хотя для нашего тестирования особых знаний среды и не потребуется. Поэтому, не будем тянуть, и сделаем тестовое приложение. Процесс, нахождения дистрибутива и установки, думаю можно пропустить 🙂

Как видно на скриншоте, в окне создания проекта появились новые типы приложений. Помимо известного VCL Forms Application, появились приложения FireMonkey. Вот они то нам и нужны. Как говорится: «Не знаешь 2D – не лезь в 3D», поэтому выбираем FireMonkey HD Application и создаем проект.

FireMonkey

Небольшая справка, что такое FireMonkey.
Это новая платформа для создания приложений под Windows, Mac OS и iOS. Новая она для Embarcodero, потому что создателем являлась компания KSDev, а сама библиотека называлась VG-Scene. Потом Embarcodero купила её и сделала частью FireMonkey.

В отличии от обычных VCL компонентов, компоненты FireMonkey являются контейнерами. Это позволяет создавать свои компоненты на основе уже имеющихся, буквально движением мыши, а с помощью встроенного редактора стилей вы сможете дать своему приложению поддержку скинов. Я уже не говорю про кучу всяких эффектов в FireMonkey: затухание, размытие и т. д. Все уже сделано, можно пользоваться. Ну конечно же — возможность всё это скомпилировать и отладить в Mac OS. Интересно? Продолжим.

Тестовое приложение

Напишем небольшое приложение, которое получает HTML код указанной страницы, сохраним его и запустим в Windows. Тут ничего чудесного нет, разве что исполняемый файл, стал меньше по сравнению с XE. Да-да, обычно было наоборот, с каждой новой версией Delphi ехешник с пустой формой добавлял килобайтов. Это так, приятная мелочь, самое интересное впереди.

Для того чтобы проверить наше приложение в Mac OS, запустим её в виртуальной машине (VMware), т. к. рабочего мака под рукой нет. Кстати, при тестировании в виртуальной машине возникли некоторые проблемы с графикой, о них ниже.

Для отладки в Mac потребуется PAServer – Platform Assistant Server, установщик можно взять из директории Delphi. Копируете на Mac, устанавливаете и запускаете через paserver.command. Более подробно можете прочитать в документации. Этих действий достаточно чтобы приложение запустилось.

Теперь нужно добавить дополнительную платформу к нашему проекту. Возвращаемся в Windows и Delphi. Жмете правой кнопкой на «Target Platforms» в узле проекта и добавляете OS X. Там же есть и 64-битная версия под Windows.

После этого нужно создать профиль отладки. Жмете правой кнопкой по только что добавленой OS X и создаете новый профиль. В окне настройки профиля нужно указать адрес, порт и пароль (если задавали) к маку с PAServer’ом. После создания, делаем новый профиль активным.

Всё. Билдим проект и запускаем. Если вы запускаете через VMware, то очень может быть что приложение не запустится. Там есть какие-то траблы с графикой в VMware, поэтому нужно сделать несколько несложных манипуляций:

1. Скопировать юнит FMX.Filter.pas в папку с проектом;
2. Изменить в этом юните две функции;
3. Установить в проекте переменную FMX.Types.GlobalUseHWEffects := False перед инициализацией.

function FilterByName(const AName: string): TFilter;
var
i: Integer;
begin
Result := nil;
if Filters = nil then
Exit;
if GlobalUseHWEffects then
begin
for i := 0 to Filters.Count — 1 do
if CompareText(TFilterClass(Filters.Objects[i]).FilterAttr.Name, AName) = 0
then
begin
Result := TFilterClass(Filters.Objects[i]).Create;
Exit;
end;
end;
end;

function FilterClassByName(const AName: string): TFilterClass;
var
i: Integer;
begin
Result := nil;
if Filters = nil then
Exit;
if GlobalUseHWEffects then
begin
for i := 0 to Filters.Count — 1 do
if CompareText(TFilterClass(Filters.Objects[i]).FilterAttr.Name, AName) = 0
then
begin
Result := TFilterClass(Filters.Objects[i]);
Exit;
end;
end;
end;

Пробуем ещё раз.

Собственно, «вот до чего техника дошла» (с). Сделали программу в Delphi на Windows и работаем в Mac OS – не изменив ни строчки кода. Для компиляции под iPhone и iPad, необходимо уже экспортировать проект и xCode, но это я думаю в другой статье.

Теперь вы можете достать из архивов свои старые игры на Delphi и попробовать переделать их на iOS. Удачи в экспериментах!

Источник

Marco Tech Blog

January 29, 2016

Editing Delphi Code on a Mac

Over the last year, there has been an increasing push in the development of source code editors and even full development environments based on portable code and available on multiple platforms, including Mac OS X. Here are some notes about my experiments with Object Pascal enabled editors on the Mac.

Over the last year, there has been an increasing push in the development of source code editors and even full development environments based on portable code and available on multiple platforms, including Mac OS X. Here are some notes about my experiments with Object Pascal enabled editors on the Mac.

As a side note, most of this editors are based on HTML + JavaScript (and variations like TypeScript), but there are some exceptions. And before you ask, Embarcadero is not currently officially endorsing any of these solutions, but we are looking into this area to understand how valuable this would be for Delphi (and C++) developers.

Visual Studio Code

Microsoft entrance into the area of cross platform hosted development tools made a significant splash last year. Visual Studio Code is a very interesting project, mainly oriented to development with scripting languages and web technologies, but with capabilities that go well beyond those of an editor. While not a replacement of Visual Studio for C# development, it works pretty well on Mac OS X and has a couple of Object Pascal language extensions (among many others). Being backed by Microsoft, makes this project highly visible. Some links:

• The main Visual Studio Code page is at code.visualstudio.com/
• The OmniPascal plugin is available at https://marketplace.visualstudio.com/items?itemName=Wosi.omnipascal and more information is available on the project web site at www.omnipascal.com/. The main limitation is that all of the features beyond syntax highlighting currently work only on Windows (and they also don’t support fhe full Delphi Object Pascal language)
• The simpler Language Pascal plugin offers only core features and is available at https://marketplace.visualstudio.com/items?itemName=alefragnani.pascal.

Below is a screenshot of some Delphi code on my Mac in Visual Studio Code.

Another very interesting open source and cross platform editor is Atom, which is backed by GitHub. Atom is more of an editor than a full development environment, is focused on customization (or hack-ability), and is extremely fast. There are Object Pascal language bindings also for it (done by the same developer of the Pascal VSCode plugin). Links:

And here is a screen shot, with the same Delphi source code file.

Trolledge

This is not such a popular editor, but a very interesting one for me. In fact, rather than in JavaScript/HTML technologies it is written in Delphi and uses FireMonkey for the user interface. Trolledge comes natively with Delphi support, and it is available (not surprinsingly) for Windows and Mac. It does support many different programming languages, though, from JavaScript to C#. Links:

As you can see in the image below, opening a form automatically opens the matching designer in a second text editor. This is the only editor with a core knowledge of Delphi and its language and architecture.

What’s Your Take?

So, what’s your take on these editors and IDEs? I end up using Delphi code editors on the Mac almost only for reading code, as writing in the Delphi editor is significantly better. But I increasingly use these editors for my HTML and JavaScript work. While the lack of designers and other integrated tools severely limits their scope, for the developer who are focused mostly on code writing and those using operating systems other than Windows, these editors can be handy.

Have you used any and what’s your experience? Which one do you like most? And do you think taht Embarcadero as a development tools company should invest in this area alongside with improving and modernizing the RAD Studio IDE on Windows?

Источник

Delphi on the Mac — possible? [closed]

Want to improve this question? Update the question so it’s on-topic for Stack Overflow.

Closed 7 months ago .

I am responsible for a Delphi/Win32 project management application. I have just completed a move to Delphi 2009.

More and more US based users want to use the application on their Mac computers, while the majority are Windows users.

Are there solutions out there to easily build a Delphi app that will natively run on MacOS?

With the release of RAD Studio XE2 in late 2011, Delphi developers should be able to build once and distribute on Win 32/64 and MacOS 32, with iOS support promised.

11 Answers 11

You might want to try Lazarus:

Mac OS X doesn’t run Windows programs. It doesn’t provide any of the API you’d need, such as the functions in kernel32, user32, etc.

You could try running your program via Crossover. Other options include virtual machines, such as VMware Fusion and Parallels.

Another thing you might try is to use .Net. Convert your program to use the .Net version of Delphi and then run it on Mono on the Mac. I wouldn’t put a lot of confidence in this method, though.

Your options to run native Delphi code on OSX are pretty limited. You can use Lazarus/Freepascal but that is a long way behind Delphi. It will produce native code.

Alternately you can use Prism and Mono. That apparently works well. Have a look at http://devcenter.remobjects.com/osx or http://wiki.remobjects.com/. Also, check out the remobjects blogs, and the embarcadero.public.delphiprism.mono.osx newsgroup.

That needs the mono redistributable. However mono also supports linking and ahead of time compilation so you might be able to get something close to native code on it.

In either case, you will need to rewrite your ui as the osx look and feel and conventions are different.

This is a very old thread but for people browsing here and looking for an answer in Q3 of 2011 or later the answer is yes.

With the release of Rad Studio XE2 this year, Delphi Developers will be able to create native applications for Mac OS as well as Win32, Win64 and iOS more platforms coming soon.

There may be some hope for the future for Delphi and the Mac.

The Podcast at Delphi.Org reviewed the closing keynote at CodeRage III (Dec 2008) when Embarcadero’s Wayne Williams talked about the Future. It said this:

I think the most exciting part of Wayne’s talk was the slide marked “The Future” which listed some of the company wide research initiatives underway. It specifically listed Mac, Linux, Cloud, Application Virtualization, FireBird, Touch, 64bit, SMP and Multi-core. When I asked about a Delphi for Mac and Linux they said that today, with Delphi Prism and Mono you could reach Mac and Linux, but in their labs they were working on native support, and that they had a significant head start.

Источник

Delphi со вкусом Cocoa

Задача

Точка отправления: наш главный продукт TamoGraph Site Survey – инструмент для инспектирования Wi-Fi-сетей, который позволяет строить карты покрытия, оптимизировать размещение access points, создавать виртуальные модели распространения сигнала и делать еще много полезных вещей для инженеров, работающих в этой области. TamoGraph работает под Windows. Точка назначения: ну вы уже догадались. TamoGraph, который бы работал под macOS.

Продукт написан большей частью на Delphi, отдельные модули написаны на С++. Почему именно Delphi? (Варианты вопроса: Он еще не умер? Вы больные? Язык X на порядок лучше, а вы ретрограды, неспособные освоить новое!) Друзья, причин, почему мы используем не самый модный и популярный язык/среду (если верить Tiobe, сегодня Object Pascal 11-ый по популярности язык) много. Это и отличная продуктивность, и да, сила привычки, и быстрый компилятор, но самая главная причина лежит совершенно не в сфере технологий. Нам просто нравится писать на Delphi, мы получаем от этого кайф. А когда продукт написан с удовольствием и любовью, он, как правило, хорошо работает. Так что не будем заниматься религиозной полемикой, а перейдем непосредственно к делу.

Итак, из точки отправления (Windows, Delphi) мы должны кратчайшим путем попасть в точку назначения (macOS, пока неизвестный язык/среда). Были рассмотрены следующие основные варианты:

1. Переделать всё на Xcode, используя Swift или Objective-C.
2. Переделать бОльшую часть на Xcode с использованием части существующего Delphi-кода в виде динамических библиотек.
3. Переделать бОльшую часть на Delphi, используя фреймворк FMX (FireMonkey), а небольшую часть кода написать на Objective-C и использовать в виде динамических библиотек.
4. Переделать всё на RemObjects Elements, используя Oxygene, их разновидность Object Pascal.

У каждого варианта, естественно, нашлось много преимуществ и недостатков. Xcode – это полная нативность GUI, отсутствие каких-либо проблем при взаимодействии с операционной системой, масса sample code и библиотек. Но, и это очень большое «но», со всем этим «в комплекте» идет необходимость переписать очень много кода на другой язык. RemObjects Elements – также полная нативность GUI, при этом очень близкий к Object Pascal язык, что означает, что существующий код, не связанный с GUI, можно было бы использовать с относительно небольшими изменениями. Однако, этот инструмент никто из нас на тот момент еще не опробовал. И, наконец, Delphi FMX. Из плюсов – использование существующего отлаженного кода на полную катушку, знакомая среда, но при этом ненативные контролы (хотя, как оказалось, это не совсем так, подробнее ниже), возможные сложности при взаимодействии с macOS API, и много других сомнений.

Неспешно посовещавшись и проведя кое-какие тесты, мы, как вы догадались по заголовку этой статьи, остановились на варианте (3), т.е. Delphi FMX. Уж очень привлекательной была возможность не переписывать значительную часть кода. И, признаться, уж очень не понравился RemObjects Elements, к которому я изначально склонялся. Итак, выбор сделан, засучили рукава и поехали…

Арт-подготовка

Часть команды уже как минимум имела опыт тесного общения с macOS и хорошо представляла ее устройство. Часть же была совсем новичками, которым потребовалась теоретическая подготовка. Для этих целей неплохо подошла книга Mac OS X and iOS Internals: To the Apple’s Core. Что касается практики, то всем нуждающимся были куплены MacBook’и, а на виртуальных машинах были развернуты разные версии macOS, от 10.9 до самой последней 10.12.

Процесс отладки программы для macOS на Delphi отличается от привычного процесса для Windows, где, как правило, вы запускаете отлаживаемую программу на том же компьютере, где работает среда Delphi. C macOS все несколько сложнее: для начала вы устанавливаете на машине с macOS Platform Assistant, т.е. вспомогательное приложение (часть Delphi), которое обеспечивает deployment и отладку приложения, а со стороны Delphi, уже под Windows, вы указываете IP-адрес машины, на которой запущен Platform Assistant:

Дальше вы просто запускаете свою программу, которая тут же начинает работать на Маке. Естественно, ее можно отлаживать ровно так же, как все мы привыкли отлаживать Windows-программы.

Контролы FMX

Итак, все настроено, можно запустить свой первый «Hello World» на Маке. GUI делается в привычном визуальном редакторе Delphi с помощью визуальных компонентов FMX. Фреймворк FMX появился в Delphi еще в 2011 году, в версии Delphi XE2. Надо сказать, что вначале он был крайне глючен, но за эти шесть лет его основательно переписали, заметно снизив количество проблем. Сейчас это вполне пригодный к использованию набор компонентов, начиная от простейшей TButton и заканчивая grids, listview, и прочими привычными контролами. Поэтому делать на FMX интерфейсы на сегодня вполне реально и комфортно, однако здесь есть некоторые особенности.

Во-первых, FMX-контролы не нативны. Это не обертка вокруг системных контролов, как это сделано в VCL, где, к примеру, TButton – это системный контрол, который рисует Windows, а не Delphi. Тут контролы рисует Delphi, задействовав свой стилевой движок, который использует стиль, соответствующий стилю той версии macOS, на которой запущена программа.
Пример диалога на Yosemite (10.10):

Ниже тот же диалог на Mavericks (10.9). Стили элементов GUI автоматически адаптировались под «родной» стиль Mavericks и выглядят уже иначе:

В принципе это работает неплохо, хотя некоторое вещи в стилях приходится подправлять (или использовать нативные контролы, о чем ниже). Например, «графитовый» стиль macOS, который появился в Yosemite, в Delphi отсутствует, и его пришлось сделать самостоятельно. На это ушло два человеко-дня.

Вторая проблема – «детские болезни». Ребеночку (фреймворку FMX), как я уже говорил, шесть лет, и несмотря на усилия Embarcadero, он еще не до конца переболел всем, чем нужно. Например, в главном меню приложения событие OnClick срабатывает для всех айтемов, кроме айтемов верхнего уровня. Т.е. если у вас меню File → Open, File → Save и так далее, то ивент OnClick случится при клике на Open и Save, но не случится при клике на File, когда произойдет выпадение списка сабайтемов. Или возьмем стандартные диалоги Open и Save. Совершенно неожиданно показ диалога полностью «затыкает» event loop приложения, и у вас перестает что-либо происходить (включая тики таймеров), пока диалог открыт. Все это, на мой взгляд, результат слишком слабого тестирования in-house и слишком медленного реагирования Embarcadero на баг-репорты.

Эти болезни лечатся в run-time, без патчинга системных юнитов. Отсутствие OnClick мы вылечили перехватив вызов ‘menuWillOpen:’ класса TFMXMenuDelegate, показ системных диалогов мы вообще переписали целиком, но чтобы исправить баг, надо сначала на нем подорваться. Будьте бдительны, не пренебрегайте тестированием, и не забывайте сообщать о багах на quality.embarcadero.com.

Наконец, закрывая тему FMX-контролов, советую взглянуть на TMS FMX UI Pack, который включает в себя много очень неплохо написанных визуальных компонентов, в том числе отличный TreeView, умеющий работать в виртуальном режиме. Это как раз то, чего нет в стандартных компонентах FMX.

Run-Time Library

Использование Delphi RTL ожидаемо оказалось наиболее беспроблемной частью при портировании кода на macOS. RTL уже давно «заточена» под мультиплатформенность, поэтому вы совершенно смело можете использовать любые функции и невизуальные классы без изменений. Нужно лишь следить за такими мелочами как, например, использование платформонезависимой IncludeTrailingPathDelimiter вместо hard-coded разделителя «\».

macOS API

Когда вы пишите что-либо чуть более сложное, чем калькулятор, вам рано или поздно придется использовать native API. Обойтись одними только RTL и фреймворком FMX совершенно нереально, равно как под Windows нереально обойтись лишь одними RTL и VCL. Нужно узнать системную локаль? Реализовать interprocess communications? Узнать размер virtual memory процесса? Шифрование? Синтез речи? Все это, естественно, native API. Но это совершенно не должно пугать, как нас не пугает вызов какой-нибудь FindWindow или GetLocaleInfo под Windows. А если что в Delphi не задекларировано, то можно задекларировать, добавить и переделать все что угодно.

Сам по себе API состоит из нескольких компонентов (BSD, Mach, Carbon, Cocoa и т.д.), но для наших целей главный интерес представляет собой Cocoa. Если говорить упрощенно, то Cocoa – это набор классов, что довольно непривычно для тех, кто привык использовать Windows API. Например, если вам нужно узнать смещение временной зоны компьютера относительно UTC, то в Windows это просто функция GetTimeZoneInformation. А вот в macOS это уже класс NSTimeZone. К этому со временем привыкаешь, покуривая на досуге Apple API Reference, ровно так же, как почти все мы когда-то в начале пути покуривали MSDN. Но вот от чего реально поначалу взрывается мозг, так это от синтаксиса «мостика» между Delphi и классами Cocoa. Это очень непривычно.

Class functions вызываются через волшебное слово OCClass:

Возвращают они как правило указатели, но не все не так просто. Эти указатели на объекты нельзя использовать напрямую; указатели представляют из себя то, что называется id в Objective-C, и чтобы преобразовать такой указатель в объект, нужно сделать волшебный Wrap:

И вот теперь уже мы уже можем вызвать функцию экземпляра класса и получить наконец требуемое смещение:

Еще примерчик? Пожалуйста! Проверяем доступность сервера:

Когда функция Objective-C-класса хочет от нас указатель на объект, мы опять же не можем просто взять и передать @MyDelphiObject, мы должны исполнить ритуальный танец по преобразованию этого указателя в id с помощью функции GetObjectID:

В общем, к синтаксису вполне можно привыкнуть, изучив примеры. Советую прочесть статью Using OS X APIs directly from Delphi, в которой эта тема хорошо раскрыта.

Если же говорить непосредственно про API (не ограничиваясь только Cocoa), то он оставляет довольно приятное ощущение. Каких-то вещей, имеющихся в Windows API, в macOS API попросту нет, и наоборот. Какие-то вещи в macOS делаются сложнее, чем в Windows, какие-то проще. Взять, к примеру, AES-шифрование. В Windows, чтобы зашифровать массив байт, нужно использовать пяток функций и пару дюжин строк кода, тогда как в macOS это можно сделать практически в одну строку функцией CCCrypt. И это уже не часть Cocoa.

Милый, милый POSIX

POSIX тоже не является частью Cocoa, но, черт возьми, большое ему спасибо, что он есть на macOS! Это делает жизнь намного проще. Многое, что можно сделать через классы, на высоком уровне, гораздо проще сделать на низком уровне через POSIX. Например, как реализовать interprocess communications? Distributed Objects и класс NSProxy? NSConnection? Забудьте, все решается в пару строк кода через memory-mapped files и функции POSIX. Нам нужны shm_open, shm_unlink и mmap. Первые две, кстати, в Delphi не задекларированы, но это не проблема. Внимательно читаем описание, декларируем:

А дальше все просто, вызываем:

Все, мы создали маппинг, доступный по имени из других процессов.

Зачем нам еще может быть нужен POSIX? Да для многих вещей. Например, вот:

Работа с сокетами, с COM-портами и многое другое – для всего этого годится простой и привычный POSIX, почти с тем же синтаксисом, что и в Windows. Среди прочего, нам нужно было портировать Delphi-класс для работы с COM-портами, который мы использовали под Windows для работы с GPS-приемниками. Кода там примерно 1500 строк. Сложно? Нет, не очень. День работы и примерно 50 IFDEF’ов такого вида:

Портировали, протестировали, к концу рабочего дня получили весело мигающий изображениями спутников модуль для работы с GPS.

Нативные контролы

Если вас не устраивает стандартный набор FMX-контролов, то это не беда. Никто не запрещает использовать нативные визуальные классы и даже смешивать их с FMX-контролами, соблюдая определенные правила. Собственно говоря, никто не запрещает даже совсем не использовать фреймворк FMX в вашем приложении Delphi (хотя это уже слегка экстремально).

Нативные классы стоит использовать ради производительности. Мы, например, столкнулись с тем, что viewport, выполненный на FMX-компонентах заметно тормозил при zoom’е и scroll’е больших битмапов, мы заменили его на нативный NSScrollView c NSImageView внутри. Чтобы получить доступ к событиям нативных классов, их надо сабклассить и/или использовать delegates. Это довольно тривиально кодируется в Delphi, и в результате вы получаете доступ к любым событиям. Нужно событие magnifyWithEvent класса NSImageView? Не проблема. Наследуем интерфейс:

И делаем все что хотим, когда вызывается метод класса-имплементатора:

Чтобы это работало, нужно еще некоторое количество кода при создании класса; примеры можно легко найти в интернете. Сабклассинг – не единственный способ перехвата событий, можно также использовать method swizzling, и я даже приведу пример ниже.

Вот так примерно мы и живем, смешивая нативные и FMX-контролы.

Что (пока) не может Delphi на macOS

С большой бочкой меда зачастую идет некоторое количество не столь прекрасной субстанции. Поговорим для разнообразия о недостатках.

Из нерешаемых проблем пока есть одна, но довольно важная. Это 64-битный компилятор для macOS, который есть в roadmap, но пока не сделан. Это, конечно, позор для Idera/Embarcadero, которые увлечены, на наш взгляд, гораздо менее важными вещами, пренебрегая Mac-веткой продукта. Так что, ждем с нетерпением.

Из решаемых – code blocks, языковая фича С++ и Objective-C, которая не поддерживается в Delphi. Точнее, Delphi имеет свой аналог code blocks, но он несовместим с теми code blocks, которые ожидает от наc macOS API. Дело в том, что многие классы имеют функции, в которых используются code blocks в качестве handler’ов завершения. Самый простой пример — beginWithCompletionHandler классов NSSavePanel и NSOpenPanel. Передаваемый сode block выполняется в момент закрытия диалога:

На Delphi такой «трюк ушами» исполнить, видимо, пока крайне проблематично (по крайней мере, нам это не удалось). Иными словами, нормальным путем мы не можем узнать о закрытии диалога. Но нормальный путь – это даже скучно! Кто нам мешает пойти ненормальным путем? Извращенных подходов к решению таких проблем несколько, но в данном случае, например, хорошо сработает следующий. Для начала мы можем получить список всех, как документированных, так и недокументированных, функций класса NSSavePanel. Делается это примерно так:

Получили список и ищем что-нибудь вкусненькое… Ага, нашли: «_didEndSheet:returnCode:contextInfo:». Очень похоже на то, что нам нужно. Надо проверить теорию, вызывается ли этот селектор при закрытии диалога. Можно сделать сабкласс NSSavePanel, а можно грубо и беспардонно поставить хук на этот селектор, подменив имплементацию метода (method sizzling):

Проверяем – и о чудо, в момент закрытия диалога по Cancel или OK мы попадаем в хукнутую функцию и, соответственно, узнаем, что диалог закрыт, а также и сам результат закрытия.

Источник