приложение win32 GUI, которое пишет текст использования в stdout при вызове как “app.exe - справка”
В целом, вы движетесь в правильном направлении. Для извлечения данных вы должны использовать useEffect и передавать [] в качестве второго аргумента, чтобы убедиться, что он срабатывает только при первоначальном монтировании.
Я полагаю, что вы могли бы извлечь выгоду из отделения функции fetchData и сделать ее более общей, как таковой:
const fetchData = async (url) => {
const response = await fetch(url);
const json = await response.json();
return json;
};
const Fetch = () => {
const [data, setData] = useState(null);
useEffect(() => {
const { disclaimer } = fetchData("https://api.coindesk.com/v1/bpi/currentprice.json");
setState(disclaimer)
}, []);
return <div>{data}</div>;
};
2 ответа
Microsoft разработала консоль и приложения для GUI, чтобы быть взаимоисключающей. Этот бит близорукости означает, что нет никакого идеального решения. Самый популярный подход должен иметь два исполняемых файла (например, cscript / wscript, Java / javaw, devenv.com / devenv.exe и т.д.) однако, Вы указали на рассмотрение этого "обмана".
у Вас есть две опции - чтобы сделать "консольный исполняемый файл" или "gui исполняемый файл", и затем использовать код, чтобы попытаться обеспечить другое поведение.
- исполняемый файл GUI:
cmd.exe предположит, что Ваша программа не делает никакой консоли I/O, так не будет ожидать его для завершения перед продолжением, которое в интерактивном режиме (т.е. не пакет) означает отображать следующее (" C:\>") подсказка и читать из клавиатуры. Таким образом, даже при использовании AttachConsole вывод будет смешан с cmd вывод, и ситуация ухудшается, при попытке сделать вход. Это - в основном обреченное на неудачу.
- Консольный исполняемый файл:
Вопреки вере, нет ничего, чтобы мешать консольному исполняемому файлу отобразить GUI, но существует две проблемы.
Прежде всего, если Вы выполняете его из командной строки без аргументов (таким образом, Вы хотите GUI), cmd будет все еще ожидать его для завершения перед продолжением, так, чтобы конкретная консоль была неприменима в течение какого-то времени. Это может быть преодолено путем запуска второго процесса того же исполняемого файла (Вы рассматриваете этот обман?), передавая флаг DETACHED_PROCESS CreateProcess () и сразу выход. Новый процесс может тогда обнаружить, что не имеет никакой консоли, и отобразите GUI.
Вот код C для иллюстрирования этого подхода:
#include <stdio.h>
#include <windows.h>
int main(int argc, char *argv[])
{
if (GetStdHandle(STD_OUTPUT_HANDLE) == 0) // no console, we must be the child process
{
MessageBox(0, "Hello GUI world!", "", 0);
}
else if (argc > 1) // we have command line args
{
printf("Hello console world!\n");
}
else // no command line args but a console - launch child process
{
DWORD dwCreationFlags = CREATE_DEFAULT_ERROR_MODE | DETACHED_PROCESS;
STARTUPINFO startinfo;
PROCESS_INFORMATION procinfo;
ZeroMemory(&startinfo, sizeof(startinfo));
startinfo.cb = sizeof(startinfo);
if (!CreateProcess(NULL, argv[0], NULL, NULL, FALSE, dwCreationFlags, NULL, NULL, &startinfo, &procinfo))
MessageBox(0, "CreateProcess() failed :(", "", 0);
}
exit(0);
}
я скомпилировал его с gcc cygwin - YMMV с MSVC.
вторая проблема состоит в том, что, когда выполнено из Проводника, Ваша программа будет в течение доли секунды отображать консоль. Нет никакого программируемого пути вокруг этого, потому что консоль создается Windows, когда приложение запускается, прежде чем это начнет выполняться. Единственная вещь, которую можно сделать, в установщике, сделайте ярлык на программу с "выставочной командой" SW_HIDE (т.е. 0). Это будет только влиять на консоль, если Вы сознательно не будете соблюдать wShowWindow поле STARTUPINFO в Вашей программе, не делайте этого.
я протестировал это путем взламывания "mkshortcut.exe" cygwin. То, как Вы выполняете его в своей предпочтительной программе установки, ваше дело.
пользователь может все еще, конечно, запустить Вашу программу путем нахождения исполняемого файла в Проводнике и двойного щелчка по нему, обхода скрывающего консоль ярлыка и наблюдения краткой черной флэш-памяти консоли. Нет ничего, что можно делать с этим.
Я знаю, что мой ответ приходит с опозданием, но я думаю, что в данной ситуации предпочтительнее использовать методы «.com» и «.exe».
По вашему определению двух исполняемых файлов это можно считать "мошенничеством", но это требует очень небольших изменений со стороны программистов, и их можно сделать и забыть. Также это решение не имеет недостатков решения Хью, в котором окна консоли отображаются в течение доли секунды.
В окнах из командной строки, если вы запускаете программу и не указываете расширение, порядок приоритета при нахождении исполняемого файла предпочтительнее будет .com, а не .exe.
Затем вы можете использовать уловки, чтобы этот .com был прокси для stdin / stdout / stderr и запускал одноименный файл .exe. Это дает возможность программе преформироваться в режиме командной строки при вызове из консоли (возможно, только при обнаружении определенных аргументов командной строки), в то же время имея возможность запускаться как приложение с графическим интерфейсом без консоли.
Там есть различные статьи, описывающие это как "