Один исполняемый файл может быть и консолью и приложением GUI?
В заключение беседы по этому вопросу я пишу, как был решен этот вопрос. Вначале я думал, что эта проблема связана с кодом в YAML (где заголовок был получен из параметров), но в конце концов я обнаружил, что делать это было нечего. Проблема заключалась в том, что я использовал функцию cat() в переменной title, которую я передаю в качестве параметра, и эта функция изменяет значение переменной title на NULL.
Чтобы точно знать все объяснения о том, как писать динамические заголовки в документах rmarkdown, перенаправьте себя к следующему входу: Настройка заголовка документа в Rmarkdown из параметров
4 ответа
ответ Jdigital точки к блог Raymond Chen, который объясняет, почему у Вас не может быть приложения, это - и консольная программа и неконсольная * программа: ОС должна знать , прежде чем программа начнет работать который подсистема использовать. После того как программа начала работать, слишком поздно, чтобы возвратиться и запросить другой режим.
ответ Cade точки к [1 111] статья о запуске приложения.Net WinForms с консолью . Это использует метод вызова AttachConsole после того, как программа начнет работать. Это имеет эффект разрешения программы записать обратно к консоли командной строки, которая запустила программу. Но комментарии в той статье указывают на то, что я считаю фатальным дефектом: дочерний процесс действительно не управляет консолью. консоль продолжает принимать вход от имени родительского процесса, и родительский процесс не знает, что это должно ожидать ребенка, чтобы закончить работать перед использованием консоли за другими вещами.
статья Chen указывает на [1 113] статья Junfeng Zhang, который объясняет несколько других методов .
первое - то, что использует devenv. Это работает путем фактического наличия двух программ. Каждый devenv.exe , который является основной программой GUI, и другой devenv.com , который справляется с задачами консольного режима, но если она используется неподобным консоли способом, это вперед его задачи к [1 120] devenv.exe и выходы. Техника полагается на правило Win32, что com файлы выбраны перед [1 122] exe файлы при вводе команды без расширения файла.
существует более простая вариация на это, которое делает Windows Script Host. Это обеспечивает два абсолютно отдельных двоичных файла, wscript.exe и cscript.exe . Аналогично, Java обеспечивает java.exe для консольных программ и javaw.exe для неконсольных программ.
вторая техника Junfeng - то, что использует ildasm. Он заключает в кавычки процесс, который автор ildasm прошел при создании выполненным в обоих режимах. В конечном счете вот то, что делает это:
- программа отмечена как двоичный файл консольного режима, таким образом, она всегда начинается с консолью. Это позволяет входному и выходному перенаправлению работать нормальным.
- , Если программа не имеет никаких параметров командной строки консольного режима, она повторно запускает себя.
недостаточно просто звонить FreeConsole, чтобы заставить первую инстанцию прекратить быть консольной программой. Поэтому процесс, который запустил программу, cmd.exe , "знает", что это запустило программу консольного режима и ожидает программы, чтобы прекратить работать. Вызов FreeConsole сделал бы остановка ildasm с помощью консоли, но это не сделает родительский процесс , запускаются использование консоли.
, Таким образом, первая инстанция перезапускает себя (с дополнительным параметром командной строки, я предполагаю). Когда Вы звоните CreateProcess, существует два различных флага для попытки, DETACHED_PROCESS и CREATE_NEW_CONSOLE , любой из которых гарантирует, что второй экземпляр не будет присоединен к родительской консоли. После этого первая инстанция может завершить и позволить командной строке продолжать обрабатывать команды.
побочный эффект этой техники состоит в том, что при запуске программы от графического интерфейса все еще будет консоль. Это высветится на экране на мгновение и затем исчезнет.
часть в статье Junfeng об использовании editbin для изменения флага консольного режима программы является отвлекающим маневром, я думаю. Ваш компилятор или среда разработки должны обеспечить установку или опцию управлять, какой вид двоичного файла это создает. Не должно быть никакой потребности изменить что-либо позже.
нижняя строка, затем, то, что у Вас может или быть два двоичных файла, или у Вас может быть мгновенное мерцание консоли . После того как Вы решаете, который является меньшим злом, у Вас есть свой выбор реализаций.
* я говорю неконсоль вместо [1 134] GUI, потому что иначе это - ложная дихотомия. Просто, потому что программа не имеет консоли, не означает, что она имеет GUI. Сервисное приложение является главным примером. Кроме того, программа может иметь консоль и окна.
Проверьте блог Raymond на эту тему:
https://devblogs.microsoft.com/oldnewthing/20090101-00/? p=19643
Его первое предложение: "Вы не можете, но можно попытаться фальсифицировать его".
http://www.csharp411.com/console-output-from-winforms-application/
Просто проверяет параметры командной строки перед материалом WinForms Application..
я должен добавить, что в.NET СМЕХОТВОРНО легко просто сделать консоль и проекты GUI в том же решении, которые совместно используют все их блоки кроме основного. И в этом случае, Вы могли заставить версию командной строки просто запустить версию GUI, если она запускается без параметров. Вы получили бы высвечивающуюся консоль.
Я думаю, что предпочтительнее то, что Роб назвал devenv методом использования двух исполняемых файлов: программы запуска «.com» и исходного «.exe». Это не так сложно использовать, если у вас есть шаблонный код для работы (см. Ссылку ниже).
В методе используются уловки, позволяющие сделать этот «.com» прокси для stdin / stdout / stderr и запустить тот же -именованный файл .exe. Это дает возможность программе преформироваться в режиме командной строки при вызове из консоли (возможно, только при обнаружении определенных аргументов командной строки), в то же время имея возможность запускаться как приложение с графическим интерфейсом без консоли.