Как открыть / создать файл с помощью glib / gtkmm в Windows
Я уже попробовал:
GError *pError = NULL;
string uri = g_filename_to_uri(file.c_str(), NULL, &pError);
if (!g_app_info_launch_default_for_uri(uri.c_str(), NULL, &pError)) {
cout << "Failed to open uri: " << pError->message;
}
Здесь я получаю сообщение об ошибке «URI не поддерживаются». URI, который я создаю здесь, не так?
Мой второй подход состоял в том, чтобы порождать файл с помощью асинхронной командной строки:
file = quoteStr(file);
try {
Glib::spawn_command_line_async(file);
} catch (Glib::SpawnError error) {
cout << error.what();
} catch (Glib::ShellError error) {
cout << error.what();
}
Здесь возникает исключение Glib :: SpawnError с ошибкой: «Не удалось выполнить вспомогательную программу (неверный аргумент)». Я имею в виду, когда я выполняю указанный абсолютный путь к файлу в Windows cmd, он открывает файл (в данном случае файл PDF). Эта функция работает по-другому?
Решение
У меня была похожая проблема, и я должен был отказаться от использования glib, и в итоге реализовал простой кроссплатформенный (win, mac и linux) совместимый способ сделать это:
// open an URI, different for each operating system
void
openuri(const char *url)
{
#ifdef WIN32
ShellExecute(GetActiveWindow(),
"open", url, NULL, NULL, SW_SHOWNORMAL);
#elif defined(__APPLE__)
char buffer[512];
::snprintf(buffer, sizeof(buffer), "open %s", url);
::system(buffer);
#else
char buffer[512];
::snprintf(buffer, sizeof(buffer), "xdg-open %s", url);
::system(buffer);
#endif
}
… это не очень красиво, но оно маленькое и работает 🙂
Другие решения
Надеемся, что это связано и может дать реальный ответ, а не просто (умный!) Обходной путь.
Я столкнулся со странной ситуацией: запуск файла (в частности, HTML-документа) g_app_info_launch_default_for_uri() или же gtk_show_uri_on_window() работал, когда исполняемый файл запускался из моего каталога сборки. Однако, это не сработало, если я скопировал exe-файл в другой каталог (для распространения) и запустил его оттуда.
В последнем случае я получил ту же ошибку, что и ваша вторая цитата:
Не удалось выполнить вспомогательную программу (неверный аргумент)
Каталог сборки не находится в моем пути, и при этом он не является особенным по какой-либо другой причине (он находится во временной памяти RAM). Так что я был совершенно сбит с толку.
Затем я подумал об этой ошибке … О какой вспомогательной программе она могла говорить?
И почему эта программа может быть найдена при запуске из каталога сборки? Ну, моя сборка использует libtool обертка, и это помещает кучу вещей в путь, так что нам не нужно копировать все библиотеки DLL и т. д. только для тестирования сборок.
Итак, я решил выяснить, есть ли что-нибудь релевантное в путях, которые можно искать с помощью оболочки MSYS2 и ее libtool обертка. Главный подозреваемый, конечно же, C:\msys64\mingw64\bin, И посмотри, что я там нашел:
gspawn-win64-helper-console.exe
После копирования этого исполняемого файла в каталог, из которого запускается мое приложение, моя программа теперь успешно запускает URI, независимо от того, в какой папке находится его исполняемый файл.
После обновления моих пакетов в MSYS2 снова возникла та же ошибка — как кажется сейчас этот тот помощник, который требуется:
gspawn-win64-helper.exe
Это на самом деле имеет больше смысла, так как мое приложение графическое, а не консольное. Я думаю, может быть, что-то изменилось здесь недавно. Вы можете распространять оба, чтобы быть более безопасным.