Универсальная схема цинк-приложения.
 

вырисовывается интересная схема построения цинк-приложения:

1. Основной swf, который ЕДИНОЖДЫ компилируется в цинк-IDE - это очень простой универсальный загрузчик, конфигурируемый файлом настроек (что и от куда грузить).

2. Весь основной код, включая mdm-скрипты, хранится во внешних swf-модулях, которые в свою очередь так же могут выступать в роли загрузчиков других модулей.

3. Все вышесказанное в полной мере относится к дочерним формам, которых по-сути нужна всего одна, даже если вам нужно их несколько разновидностей. просто в качестве основного swf для дочерней формы указывается все тот же простой загрузчик. (Конечно, если вы планируете ОДНОВРЕМЕННО показывать несколько дочерних форм, их количество придется увеличить)
Одна тонкость.
Чтобы дочерняя форма нормально инициализировалась при старте приложения и не мелькала при этом на экране - в IDE при компиляции задать ей отрицательную x- или y-координату и свойство visible=true.
Дело в том, что обращаться к функциям дочерней формы из основной формы можно только после первого появления дочерней формы на экране. до этого момента ее "как бы" нет.
При задании отрицательных координат при visible=true формально при старте форма будет "показана" (но не буквально), что и устраняет указанное препятствие. Далее, можно оперировать с ее координатами или с ее свойством visible из основной формы, показывая ее когда необходимо, предварительно подгрузив в нее нужный swf.

4. Приложение легко переносится, масштабируется, достраивается, дебажится.
...
простите, если "изобретаю велосипед" :)

В эпоху SWFkit я так и поступал, но когда 2,5 года назад перешел на зинк, такой подход почему то не прокатил, с тех пор я и не пытался повторить. :)
Однако с выходом 3-го зинка, у которого можно компилить из командной строки (во времена 2.5, за это драли отдельный деньги), такая возможность не столь актуальна, ведь можно для проекта сделать батник и потом просто запускать его. Не громоздя кучу swf вокруг базового exe

ну вот. так и знал, что "велосипед". :)
..

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

ну раз так.. позволю себе разместить данную тему в факе, с разрешения модераторов.
Плюсом я бы еще назвал возможности коллективной работы над проектом. Правда, придется вырабатывать некий "фреймворк". Например, я в своем проекте в подгружаемых swf по-умолчанию ставлю некоторый набор свойств и методов, которые могут вызываться из майн. Скажем, обработчик dnd или кликов мыши и т.п.
ну и собрать из кучи swf один большой ехе - тоже не проблема, если что.

Кстати, прямо сейчас этим способом пользуюсь.
Создал exe оболочку, а в настройках проекта FlashDevelop для Post-Build Command Line написал: В результате, жму на F8, компилится swf и сразу жу запускается exe. Красота!

а я ехе не перезапускаю даже. забил в лоадер хоткей перезагрузки и все.
а модули у меня свои конфиги могут иметь...
вот это - красота!

Я тоже сначала так хотел, но для этого надо сделать:
1. Нажать на клавишу для компиляции swf
2. Переключиться на exe
3. Нажать кнопку перегрузки

Когда как у меня, только:
1. Нажать F8, копиляция и запуск exe пройдут автоматически.

Обнаружил баг в 2.5.
Используя способ выше, свойства
mdm.Application.path
mdm.Application.pathUnicode
дают разный результат, первый показывает верный путь до exe, а второй на две папки выше - я так понимаю папку нахождения проекта, который вызвал exe. Если же запускать exe вручную, то оба пути верные.

Я unicode не использовал никогда практически.
А вот в тройке (3.0.0 триал) описанная схема у меня вообще почему-то не ездит. Тормоза и загрузка не происходит. Гружу MovieClipLoader'ом. Впрочем, тестил мало - времени не было. Может из-за путей как раз..
А у вас как?
Опять подробности.
Я компилю в цинке "стандартный" лоадер, который берет ини-пути из текстового конфига (*.txt). Конфиг лежит рядом с ехе и к нему путь я вообще не указываю, только имя файла. Он грузит основной лоадер, который по замыслу полностью самостоятельный модуль. У него более расширенные настройки, подгружаемые из xml. Пути храню в конфигах, пути полные. Проблем с их восприятием у 2.5 не было.
...
сейчас еще раз на тройке попробовал: просто прдгрузка swf, вообще без mdm-скриптов. не работает.
хотя в предпросмотре загрузка происходит как надо.
тут же скомпилил в 2.5 - все ок.
стоп! а вот оно.
стоило вместо mcl.loadClip('main.swf', holder); написать mcl.loadClip(<полный путь до main.swf'>, holder); все заработало. надо на работе попробовать проект в тройке. а то я этот пример помучил и бросил. сейчас думаю заработать все должно и в тройке.
Видимо плеер в третьем цинке не понимает относительные пути совсем.