Comments 13
Боярин знает толк. На IT Happens такое скорее всего никто не поймет. IIRC прямого способа без ObjC не существует — тяжелое наследие сказывается.
У нас с :: и / на маке тоже был интересный случай. Фреймворки собирались с неправильными Install Path (rpath), поэтому после линковки приложение не запускалось, если предварительно не сделать export DYLD_FRAMEWORK_PATH=<path_to_frameworks> (при запуске отладки из Xcode это делается автомагически, а вот QA запустить приложение в один клик не могли). Был написан шелл-скрипт, который делал export DYLD_FRAMEWORK_PATH=$(pwd) и запускал с этим окружением приложение.
В один прекрасный день один из QA жалуется, что не может запустить приложение. При этом у другого эта же сборка отлично работает.
Выяснилось следущее:
1. QA создал в Finder папку с именем «текущая дата» в виде например 2010/04/01. Finder молча это скушал и папку создал.
2. Для POSIX API эта папка выглядела 2010:04:01.
3. Шелл-скрипт в итоге выполнял нечто вроде export DYLD_FRAMEWORK_PATH=/Users/QA/builds/App/2010:04:01 и запускал приложение.
Подвох заключался в том, что двоеточие является разделителем путей в DYLD_FRAMEWORK_PATH (и в других PATH тоже), поэтому фреймворки внезапно перестали находиться.
Такая вот история.
В один прекрасный день один из QA жалуется, что не может запустить приложение. При этом у другого эта же сборка отлично работает.
Выяснилось следущее:
1. QA создал в Finder папку с именем «текущая дата» в виде например 2010/04/01. Finder молча это скушал и папку создал.
2. Для POSIX API эта папка выглядела 2010:04:01.
3. Шелл-скрипт в итоге выполнял нечто вроде export DYLD_FRAMEWORK_PATH=/Users/QA/builds/App/2010:04:01 и запускал приложение.
Подвох заключался в том, что двоеточие является разделителем путей в DYLD_FRAMEWORK_PATH (и в других PATH тоже), поэтому фреймворки внезапно перестали находиться.
Такая вот история.
Ээээ мне казалось, что пути через :: это жесточайший deprecated и он был выпилен ещё в самой первой десятке. Ни разу на них не натыкался!
Клиент прислал лог чтобы не соврать — со Snow Leopard.
А вообще насчет «выпилен» это сильно — эвон photoshop SDK откроешь — чего только в примерах не увидишь, и это все еще и компилируется под 32 бита (под 64 — уже нет, хотя FSIO к примеру — в полный рост есть и тут).
Так что — еще встречается.
А вообще насчет «выпилен» это сильно — эвон photoshop SDK откроешь — чего только в примерах не увидишь, и это все еще и компилируется под 32 бита (под 64 — уже нет, хотя FSIO к примеру — в полный рост есть и тут).
Так что — еще встречается.
Вот так Carbon использовать…
Из CFURL в POSIX path на чистом C можно сконвертировать так:
CFStringRef fullpath = CFURLCopyFileSystemPath(fullurl, kCFURLPOSIXPathStyle);
Я был в полушаге. Логично — если у меня уже есть URL… ;-) Подвела косность мышления — я пытался путь в путь преобразовать, а получив URL — решил что и так сойдет, URL то везде conform.
Так что в итоге вот что должно было получиться:
Так что в итоге вот что должно было получиться:
void FooExpFilter::ExportToStream(
IPMStream* stream, IDocument* doc, IPMUnknown* targetboss,
const PMString& formatName, UIFlags uiFlags)
{
IDFile outputFile;
InterfacePtr<IFileStreamData> fileData(stream, IID_IFILESTREAMDATA);
outputFile = fileData->GetSysFile();
#ifdef WINDOWS
SDKFileHelper fh(outputFile);
PMString pathID = fh.GetPath();
#endif
#ifdef MACINTOSH
FSSpec fsSpec;
PMString pathID;
OSErr err = FileUtils::IDFileToFSSpec(outputFile, fsSpec);
if (err == noErr) {
FSRef fsRef;
err = MacFileUtils::FSSpecToFSRef(fsSpec, fsRef);
if (err == noErr) {
CFURLRef appURL = ::CFURLCreateFromFSRef(NULL, &fsRef);
CFStringRef app_str = ::CFURLCopyFileSystemPath(appURL, kCFURLPOSIXPathStyle);
if (app_str) {
pathID.SetCFString(app_str);
::CFRelease(app_str);
}
if (appURL) ::CFRelease(appURL);
}
}
#endif
WideString pathWID(pathID);
std::string xID;
StringUtils::ConvertWideStringToUTF8 (pathWID, xID);
Хабраюзер strizh также обратил мое внимание на mac-only FileUtils::FileURLToPosixPath, так что код превращается в
что несколько короче.
IDFile outputFile;
InterfacePtr<IFileStreamData> fileData(stream, IID_IFILESTREAMDATA);
outputFile = fileData->GetSysFile();
#ifdef WINDOWS
SDKFileHelper fh(outputFile);
PMString pathID = fh.GetPath();
WideString pathWID(pathID);
std::string xfinal;
StringUtils::ConvertWideStringToUTF8 (pathWID, xfinal);
#endif
#ifdef MACINTOSH
PMString pathJ = FileUtils::SysFileToFileURL(outputFile);
WideString pathWJ(pathJ);
std::string xj;
StringUtils::ConvertWideStringToUTF8 (pathWJ, xj);
std::string xfinal = FileUtils::FileURLToPosixPath(xj);
#endif
что несколько короче.
Вопрос к автору: А как сейчас с Java API у Indesign Server, больше его не развивают?
Что такого страшного в Obj-C? Отдельный файлик с интерфейсом в виде обычной C-функции и все.
Sign up to leave a comment.
О том как я имя файла из С++ в Java передавал