Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > C/C++: Системное программирование и WinAPI > Первое приложение на WinAPI

Автор: m9yt 3.9.2010, 20:29

Всем привет. Написал по методичке код программы, даже сверил его с кодом при создании обычного решения. В итоге окно просто не появляется при запуске. Вот код: Код #include <windows.h>   wchar_t szClassName[]=L"MainWindow"; wchar_t szTitle[]=L"Программа 1-1"; LRESULT CALLBACK WndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam); BOOL InitInstance(HINSTANCE hInstance, int nCmdShow);   void MyRegisterClass(HINSTANCE hInstance) {         WNDCLASS w;         memset( &w, 0, sizeof (WNDCLASS) );         w.style                                 = CS_HREDRAW | CS_VREDRAW;         w.lpfnWndProc                   = WndProc;         w.hInstance                             = hInstance;         w.hbrBackground                 = (HBRUSH)GetStockObject(WHITE_BRUSH);         w.lpszClassName                 = L"MyClass";         w.hIcon                 = LoadIcon(NULL, IDI_APPLICATION);         w.hCursor                               = LoadCursor(NULL,IDC_IBEAM);         RegisterClass(&w); }   int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) {         MSG msg;         MyRegisterClass(hInstance);         if (!InitInstance (hInstance, nCmdShow))         {                 return FALSE;         }         while (GetMessage(&msg, NULL, 0, 0))         {                         TranslateMessage(&msg);                         DispatchMessage(&msg);         }         return (int) msg.wParam; }   LRESULT CALLBACK WndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)  {         switch(message) {                 case WM_DESTROY:                         PostQuitMessage(0);                         return 0;                 default:                         return DefWindowProc(hwnd,message,wParam,lParam);                 } }   BOOL InitInstance(HINSTANCE hInstance, int nCmdShow) {    HWND hWnd;      //hInst = hInstance; // Сохранить дескриптор экземпляра в глобальной переменной      hWnd = CreateWindow(szClassName, szTitle, WS_OVERLAPPEDWINDOW,       CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hInstance, NULL);      if (!hWnd)    {       return FALSE;    }      ShowWindow(hWnd, nCmdShow);    UpdateWindow(hWnd);      return TRUE; }

Автор: Cheloveck 3.9.2010, 22:36

ты регистрируешь класс L"MyClass", а окно создаёшь класса L"MainWindow" Добавлено через 3 минуты и 4 секунды PostQuitMessage(0); надо делать на сообщение WM_CLOSE, а WM_DESTROY ты не дождёшься, по моему.

Автор: bsa 3.9.2010, 23:35

m9yt, если тебе изучать WinAPI не требуется по работе/учебе, то рекомендую бросить эту затею и обратить внимание на что-то более достойное, например C++/Qt или C# (если не планируешь писать ПО под платформы отличные от Windows).

Автор: Dem_max 5.9.2010, 07:22

PostQuitMessage нужно делать в  Код       case WM_CLOSE_PLUGIN:       {           DestroyWindow(hWnd);       }break;       case WM_DESTROY:       {          PostQuitMessage(0);       }break;

Автор: ASMatic 6.9.2010, 05:23

Цитата(bsa @  3.9.2010,  21:35 ) что-то более достойное зря ты так!

Автор: xvr 6.9.2010, 11:13

Цитата(ASMatic @ 6.9.2010,  05:23) Цитата(bsa @  3.9.2010,  21:35 ) что-то более достойное зря ты так! bsa абсолютно прав. И не потому, что WinAPI это нечто недостойное и никому не нужное, а потому что оно слишком низкоуровневое. Любое телодвижение на WinAPI выливается в кучу кода, и собственно что бы эту кучу не писать, а заниматься непосредственно функционалом программы, а не борьбой с WinAPI, всякие оконные (и не только) фреймворки и придумали.

Автор: ИванМ 6.9.2010, 11:40

xvr, вы правы, но изучить его же все же имеет смысл. Пусть не на 100%, а хотя бы иметь о нем представление. По жизни может пригодиться. Даже при работе с Qt и C#. Добавлено через 2 минуты и 1 секунду Цитата(bsa @  3.9.2010,  23:35 ) например C++/Qt или C# (если не планируешь писать ПО под платформы отличные от Windows).  И не хочешь страдать фигней, которая называется Mono.

Автор: xvr 6.9.2010, 17:38

Цитата(ИванМ @  6.9.2010,  11:40 ) xvr, вы правы, но изучить его же все же имеет смысл. Изучить - да, а писать на нем реальные программы - нет    Цитата(ИванМ @  6.9.2010,  11:40 ) Пусть не на 100%, а хотя бы иметь о нем представление.  С этим согласен на все 100%

Автор: Router 6.9.2010, 17:54

Цитата Изучить - да, а писать на нем реальные программы - нет  Хотелось бы узнать, а на чем пишут реальные программы ?

Автор: ASMatic 6.9.2010, 18:55

Цитата(xvr @  6.9.2010,  09:13 ) фреймворки и придумали. видал я ваши фреймворки....смешно было что вроде норм кантора а заюзала фреймворк и потом долго падала ихния прога пока не оказалось что фреймвор мелкомягкие лиха написали (толи прого разработчики не учли) - удалить надо было 1.1. а только потом ставить 2.0, по другому - креш! Я к чему - да к тому что когда ты сам пишешь все на "низком" уровне тогда под твоим контролем получаеться больше и сделать так что бы удалить старый и установить новый - ты сделаешь сам и точно так как требует остальная часть кода! Да и если руки не с попы то можно написать норм либы или хотя бы иметь базу прожектов откуда(если норм написано все) можно быстро и не особо напряжно скопипастить часть которая в данный момент интересна! Для новичков - лучше не придумаешь!! Почему? - да потому что когда я писать пытался на билдере (слав те госпади что навел на путь истинный!) ничерта не понимал что и как происходит в той системе под которую я разрабатываю прогу и когда вылазили косяки VCL и самого былдера я в недопонимании метался и незнал что делать дальше, т.к. толковой описухи - нету(по крайней мере небыло)! А вот взявшись за разум и установив студию + начав писать на винапи - за год понял про юзермод многое. И теперь с винапи не слезу никогда!!! VCL и тому подобные фичи считаю оправдаными только если ты разрабатываешь приложения с кучей СТАНДАРТНОЙ графики, т.к. на винапи сильно не удобно это все размещать и настраивать... В остальных случаях - сишка и синапи, вот сам смак Win32 программирования. ИМХО >>Хотелось бы узнать, а на чем пишут реальные программы ? присоединяюсь!

Автор: xvr 6.9.2010, 19:34

Цитата(ASMatic @ 6.9.2010,  18:55) Я к чему - да к тому что когда ты сам пишешь все на "низком" уровне тогда под твоим контролем получаеться больше и сделать так что бы удалить старый и установить новый - ты сделаешь сам и точно так как требует остальная часть кода! Флаг в руки и барабан на шею - когда напишешь несколько сотен тысяч строк кода (на голом WinAPI) тогда и поговорим    Цитата Для новичков - лучше не придумаешь!!  И ASM forever! Я угадал? Цитата Почему? - да потому что когда я писать пытался на билдере (слав те госпади что навел на путь истинный!) ничерта не понимал что и как происходит в той системе под которую я разрабатываю прогу Недостатки образования всегда сильно мешают   Кто мешал посмотреть в сорцы VCL, если было что не понятно? Цитата А вот взявшись за разум и установив студию + начав писать на винапи - за год понял про юзермод многое. И теперь с винапи не слезу никогда!!! Да уж, подсадили на WinAPI. Это похуже кокаина будет    Цитата В остальных случаях - сишка и синапи, вот сам смак Win32 программирования. ИМХО Это клиника, и не IMHO, а абсолютно точно    Цитата >>Хотелось бы узнать, а на чем пишут реальные программы ? присоединяюсь! Qt, .NET

Автор: ASMatic 7.9.2010, 01:21

xvr,  Цитата(xvr @  6.9.2010,  17:34 ) Флаг в руки и барабан на шею - когда напишешь несколько сотен тысяч строк кода (на голом WinAPI) тогда и поговорим чего это я должен писать что бы столько кода навалить? пример можно - ТЗ минимальное! Цитата(xvr @  6.9.2010,  17:34 ) И ASM forever! Я угадал? порадовало что не угадал. ASM нужен только в некоторых случаях, когда си трудно справиться с задачей. Цитата(xvr @  6.9.2010,  17:34 ) Да уж, подсадили на WinAPI. Это похуже кокаина будет это тебя, клоун подсадили! Цитата(xvr @  6.9.2010,  17:34 ) Это клиника, и не IMHO, а абсолютно точно может Вы и не дятел, но долбить бредятину прекрастно умеете. Цитата(xvr @  6.9.2010,  17:34 ) Qt, .NET хороший выбор для любителей потрещать какие они не**ные программисты. Удачи, френд и радуйтесь что вы такой прекрасный!

Автор: AntiB 7.9.2010, 01:41

xvr,  Цитата(xvr @  6.9.2010,  17:34 ) Флаг в руки и барабан на шею - когда напишешь несколько сотен тысяч строк кода (на голом WinAPI) тогда и поговорим    Много сотен тысяч строк сами написали или только чтобы показаться крутым программистом? (отвечать не нужно, просто сами для себя подумайте) Цитата(xvr @  6.9.2010,  17:34 ) И ASM forever! Я угадал? Вы считаете что asm хреново знать (хоть для понимание работы архитектуры под какую пишите) ? Цитата(xvr @  6.9.2010,  17:34 ) Да уж, подсадили на WinAPI. Это похуже кокаина будет    Если вы говорите о WinApi не для гуи проектов - очень заблуждаетесь, самое лучшее и правильное решение - использовать WinApi. А для ускорения разработки нужно писать свои либы которые очень упрощают жизнь. Цитата(xvr @  6.9.2010,  17:34 ) Qt, .NET Вы не правы насчет .Net, сама технология тормознутая херня и здесь ничего не поделаешь и правы (частично) насчет WinApi - гемора есть немного, но выгода есть - полный контроль. И в общем ваша манера выражаться не достойна звания Комодератор, оскорблять участников форума - не хорошо да и показывает ваш умственный уровень. С Уважением, AntiB

Автор: Dem_max 7.9.2010, 04:27

Заканчиваем флейм в топике

Автор: xvr 7.9.2010, 10:59

Кажется ASMatic обиделся на мое послание. Приношу свои извинения - у меня не было не малейшего намерения кого либо обижать. Видимо я должен более подробно объяснить что я имел в виду по каждому пункту. Цитата xvr,  Цитата(xvr @  6.9.2010,  17:34 ) Флаг в руки и барабан на шею - когда напишешь несколько сотен тысяч строк кода (на голом WinAPI) тогда и поговорим чего это я должен писать что бы столько кода навалить? пример можно - ТЗ минимальное! Можно - аналог OpenOffice. Объясняю - я не имел в виду, что ASMatic ничего не написал, что бы давать советы. Я имел в виду, что в реальном приложении, когда его GUI часть составляет не более нескольких процентов от текстов всего приложения, реализация этого GUI на WinAPI способна эти несколько процентов раздуть до доброй половины. И программисту придется в основном писать тонны однообразного и повторяющегося кода, вместо того, что бы сосредоточится на собственно логике приложения. Обычно после попытки написать Офис на API наступает просветление    Цитата Цитата(xvr @  6.9.2010,  17:34 ) И ASM forever! Я угадал? порадовало что не угадал. ASM нужен только в некоторых случаях, когда си трудно справиться с задачей. В таком случае еще раз извиняюсь - по безапелляционности исходного сообщения я сделал вывод, что автор принадлежит к редкому виду пионеров с горящим взором и лозунгом 'ASM forever!'. Объяснять что либо этим личностям невозможно - они не слушают никаких доводов и стоят на своем до конца (обычно этот конец тонет в куче флейма). Еще раз извиняюсь перед ASMatic

Автор: Earnest 7.9.2010, 11:01

Цитата(ASMatic @  6.9.2010,  19:55 ) >>Хотелось бы узнать, а на чем пишут реальные программы ? присоединяюсь! Мой реальный проект написан на MFC. Т.е. оболочка, конечно. Знаю, знаю всю муть, которую гонят про MFC. И это по большей части правда. Но проекту (виндовой реинкарнации) уже ~15 лет, и тогда особого выбора не было. А сейчас поздно соскакивать - иначе пользователи новой версии рискуют не дождаться. Не устаю радоваться, что в свое время при выборе между Borland'ом и MS выбрала таки MS и его кривое, но очень прозрачное MFC. Ну и потом, окна-диалоги - 66 часть проекта, а алгоритмы обработки от библиотек не зависят, ибо нет готовых. А если бы приложение было сильно формо-зависимо, но я бы выбрала... не знаю, чтобы я выбрала, но скорее всего другую работу. Ну их в ... эти формы, тоска. А что касается чистого WinAPI, то тебе должно быстро надоесть стока многа букв каждый раз писать, это тоже неинтересно. За что и ценю MFC, так за то что при всей своей кривости, он таки полный контроль дает - если надо. Рекомендовать сейчас, для новых проектов, конечно, не буду. Но я бы, возникни такая нужда, искала бы что-то вроде - тонкое-прозрачное, но с более современной архитектурой. Но с полным контролем, а не как борландовский ужас. Добавлено через 8 минут и 51 секунду Цитата(xvr @  7.9.2010,  11:59 ) И программисту придется в основном писать тонны однообразного и повторяющегося кода, вместо того, что бы сосредоточится на собственно логике приложения. Обычно после попытки написать Офис на API наступает просветление  Двумя руками подписываюсь.  Автор тут еще насчет своих библиотек упоминал. Оно да, конечно, полезно. Но это примерно то же самое, что писать собственные контролы. Если интересно и хочешь этому посвятить жизнь - вперед и вверх. Но нужно помнить, что спроектировать повторно используемые - как контролы, так и оболочку - очень не просто. особенно второе. Так что если цель - таки какое-то приложение в конкретной области, прагматичнее смириться с некоторой кривизной чужой реализации. (А чужая реализация всегда кривая просто по определению   ). И выбирать по критерию - архитектура-прозрачность-контроль. При главном критерии "контроль", т.е. возможность при необходимости доработать все что надо напильником.

Автор: Cheloveck 7.9.2010, 15:14

Мне одному кажется, что ТС не спрашивал на чём ему писать? Вот вам топик http://forum.vingrad.ru/forum/act-ST/f-69/t-309402/unread-1.html Переезжайте!

Автор: ASMatic 7.9.2010, 18:33

Цитата(xvr @  7.9.2010,  08:59 ) реализация этого GUI на WinAPI способна эти несколько процентов раздуть до доброй половины о графике я упомянул, тут не вопрос - жопа!) Цитата(ASMatic @  6.9.2010,  16:55 ) VCL и тому подобные фичи считаю оправдаными только если ты разрабатываешь приложения с кучей СТАНДАРТНОЙ графики, т.к. на винапи сильно не удобно это все размещать и настраивать... Цитата(xvr @  7.9.2010,  08:59 ) Обычно после попытки написать Офис на API наступает просветление не пробовал, т.к. стараюсь писать только то где графики поменьше....   Цитата(xvr @  7.9.2010,  08:59 ) Еще раз извиняюсь перед ASMatic     принимаю.) Цитата(Earnest @  7.9.2010,  09:01 ) прагматичнее смириться с некоторой кривизной чужой реализации. в свои прожи вообще чужого не пускаю - было пару раз что потом приходилось разбираться почему при куче потоков у кого-то что то начинает падать)) Свои либы - да прекрасно, но и писать их для ГУИ - напряг, так что бы они были универсальны...Поэтому с ГУИ не связываюсь...ну разве что по минимуму.... Цитата(Cheloveck @  7.9.2010,  13:14 ) Мне одному кажется, что ТС не спрашивал на чём ему писать? а ТС уже ответили давненько и он вообще пропал) - видимо помогло) но всеже предлагаю закрывать тему дискусий по этому поводу, все высказались и новичкам теперь точно будет над чем поразмышлять

Автор: xvr 7.9.2010, 21:07

Цитата(ASMatic @  7.9.2010,  18:33 ) о графике я упомянул, тут не вопрос - жопа!) Цитата(ASMatic @  7.9.2010,  18:33 ) Свои либы - да прекрасно, но и писать их для ГУИ - напряг, так что бы они были универсальны...Поэтому с ГУИ не связываюсь...ну разве что по минимуму.... В таком случае у нас полный консенсус - все мои высказывания относились ТОЛЬКО к GUI. Общесистемная часть в Win32 API спроектирована и реализована на удивление хорошо. Ее вполне можно применять напрямую, без каких либо библиотечных прослоек (за исключением случаев, когда библиотеки УЖЕ используются в программе, для GUI например, как та же Qt. Для единообразия)

Автор: semibug 11.9.2010, 20:03

Выскажу мнение. Писать на WinApi гуй не такая уж большая проблема. Да, есть писанина, да, есть метание по MSDN, но если грамотно спланировать, то дальше можно пользоваться своей прослойкой. Поэтому не соглашусь, что большая программа с гуем из WinApi на 50 процентов состоит из WinApi функций. На следующий день после go to бог придумал sub routine. Как правило сообразив какойто контрол раз, потом пользуешь без ограничений. В принципе можно пойти и дальше стандартных контролов, и написать полностью обработку самостоятельно, в этом плане мне очень сильно импонирует GuiChan, разобраться можно с пол оборота, и потом использовать стиль для своих поделок. Очень хорошо выполнен Qt, кучу идей можно брать и от туда. А в целом, как всегда, вопрос выбора обусловлен задачей (включая сроки, заказчика и тд и тп). Если можно использовать готовое, и проект не для самообразования - вопрос выбора обычно не возникает. P.S. В последние годы как ни странно стараюсь выполнять все приложения в консоли (по мере сил убеждая заказчика).

Автор: ИванМ 11.9.2010, 22:51

Цитата(semibug @  11.9.2010,  20:03 ) А в целом, как всегда, вопрос выбора обусловлен задачей (включая сроки, заказчика и тд и тп). Если можно использовать готовое, и проект не для самообразования - вопрос выбора обычно не возникает. Это единственная здравая мысль в вашем послании. Поддерживаю. Цитата(xvr @  7.9.2010,  21:07 ) Общесистемная часть в Win32 API спроектирована и реализована на удивление хорошо. Ее вполне можно применять напрямую, без каких либо библиотечных прослоек На мой взгляд, не очень удачное обобщение.

Автор: xvr 12.9.2010, 09:20

Цитата(semibug @  11.9.2010,  20:03 ) На следующий день после go to бог придумал sub routine. Как правило сообразив какойто контрол раз, потом пользуешь без ограничений. В принципе можно пойти и дальше стандартных контролов, и написать полностью обработку самостоятельно, После чего и получается еще один фрейморк. Внимание, вопрос - нафига нужен ЕЩЕ ОДИН фреймворк, к тому же заточенный под задачу, когда есть куча готовых. Пока вижу один ответ - в готовых лень разбираться    Цитата(ИванМ @  11.9.2010,  22:51 ) На мой взгляд, не очень удачное обобщение. В смысле? Какое именно обобщение?

Автор: semibug 12.9.2010, 13:33

Цитата(xvr @  12.9.2010,  09:20 ) После чего и получается еще один фрейморк. Внимание, вопрос - нафига нужен ЕЩЕ ОДИН фреймворк, к тому же заточенный под задачу Предполагается, что стоит задача написать только с WinApi (почему, не знаю, может архитектор страдает тиранией). Хочу сказать, что это не такая чудовищная проблема, раскидал вызовы по своим классикам-врапперам, и юзай на здоровье. Как уже писал, если есть возможность юзать готовое, можно не раздумывать (если разобраться с WinApi не есть сама задача).

Автор: ИванМ 12.9.2010, 19:48

Цитата(semibug @  12.9.2010,  13:33 ) Хочу сказать, что это не такая чудовищная проблема, раскидал вызовы по своим классикам-врапперам, и юзай на здоровье. Вы так уверенно говорите, потому что у вас есть готовая самописная GUI-библиотека или вы просто рассуждаете в теории? Цитата(xvr @  12.9.2010,  09:20 ) В смысле? Какое именно обобщение? Общесистемная часть очень широкое понятие. Что-то действительно удобно и просто реализовано, что-то не очень. Далеко ходить не буду, приведу самый простой пример. Пользоваться оператором << для fstream удобнее, чем вызывать WriteFile.

Автор: xvr 12.9.2010, 22:59

Цитата(semibug @  12.9.2010,  13:33 ) Предполагается, что стоит задача написать только с WinApi То, что предполагал/хотел ТС забыли уже экрана 2 назад, теперь обсуждается 'API или не API - вот в чем вопрос'    Цитата(ИванМ @  12.9.2010,  19:48 ) Общесистемная часть очень широкое понятие. Что-то действительно удобно и просто реализовано, что-то не очень. Ну в общем и целом конечно понятие слишком широкое, но по удобству использования БОЛЬШАЯ часть того, что не GDI+Окна гораздо удобнее того, что есть GDI+Окна Цитата(ИванМ @  12.9.2010,  19:48 ) Пользоваться оператором << для fstream удобнее, чем вызывать WriteFile. Разумеется. Даже пользоваться FILE* и printf будет удобнее, чем WriteFile. На то они и интерфейсы уровня библиотеки исполнения (наиболее оригинально это представленно в *nix'ах - там интерфейсы системы и библиотеки исполнения явно разделены в документации, но нигде больше   ) Что же касается WriteFile, то когда требуется нечто, не охваченное fstream (например Overlapped IO), то приходится опускаться на уровень CreateFile/WriteFile/ReadFile, и это не является катастрофой   Они даже могут мирно сосуществовать в одной программе

Автор: Earnest 13.9.2010, 06:28

Цитата(ИванМ @  12.9.2010,  20:48 ) Пользоваться оператором << для fstream удобнее, чем вызывать WriteFile.  Это несравнимые вещи, даже если забыть о том, что << осуществляет текстовый вывод... Насчет GUI, да, согласна, не очень неудобная вещь. В основном потому, что все эти долбанные хандлы не имеют семантики копирования + легкость попадания на утечку ресурсов + нехилые тормоза при выборе в контекст. Но это тоже можно улучшить с помощью совместно работающих оберток - над GDI-объектами и над CDC.

Автор: semibug 13.9.2010, 09:42

Цитата(ИванМ @  12.9.2010,  19:48 ) Вы так уверенно говорите, потому что у вас есть готовая самописная GUI-библиотека или вы просто рассуждаете в теории? Библиотека громко сказано. Приходилось писать интерфейсы WinApi only. Минимум необходимых переходничков для конкретной задачи, ничего более. Но вполне можно писать, и на это не уходило 50 процентов кода, как тут уже писали. Опять таки повторюсь, мои измышления основаны на факте, что ничего кроме WinApi юзать нельзя. Если есть выбор - пишу для командной строки

Автор: ИванМ 13.9.2010, 21:01

Цитата(xvr @  12.9.2010,  22:59 ) Разумеется. Даже пользоваться FILE* и printf будет удобнее, чем WriteFile. На то они и интерфейсы уровня библиотеки исполнения (наиболее оригинально это представленно в *nix'ах - там интерфейсы системы и библиотеки исполнения явно разделены в документации, но нигде больше  smile ) Что же касается WriteFile, то когда требуется нечто, не охваченное fstream (например Overlapped IO), то приходится опускаться на уровень CreateFile/WriteFile/ReadFile, и это не является катастрофой  smile Они даже могут мирно сосуществовать в одной программе Вот с этим я уже соглашусь. Это не так категорично, как в вашем сообщении до этого. Цитата(semibug @  13.9.2010,  09:42 ) Библиотека громко сказано. Приходилось писать интерфейсы WinApi only. Минимум необходимых переходничков для конкретной задачи, ничего более. Но вполне можно писать, и на это не уходило 50 процентов кода, как тут уже писали. Опять таки повторюсь, мои измышления основаны на факте, что ничего кроме WinApi юзать нельзя. На уровне переходничков, возможно, это и так. Но, на сколько я понял тему, мы говорим о полноценном механизме, который можно использовать для решения насущных проблем.

Автор: priam220 16.9.2010, 22:00

возможно ли запускать Апи функции удаленно. Т.е. запуская программу на одном компъютере ждать выполнения Апи на другом?

Автор: Dem_max 17.9.2010, 04:40

используй http://technet.microsoft.com/ru-ru/sysinternals/bb897553.aspx или вот исходники аналогичной команды

Автор: ksili 17.9.2010, 08:05

Что интересно, темы с названием "Первое приложение на WinAPI" появляются регулярно. А вот тем с названиями "Второе приложение на WinAPI" нет!

Автор: Dem_max 17.9.2010, 08:58

второго не бывает, так как не доделано еще первое.

Автор: mrbrooks 17.9.2010, 09:54

Цитата(ksili @  17.9.2010,  09:05 ) Что интересно, темы с названием "Первое приложение на WinAPI" появляются регулярно. А вот тем с названиями "Второе приложение на WinAPI" нет! Видимо надо читать как:  "Первое приложение на WinAPI. Аминь"

Автор: xvr 17.9.2010, 11:29

Цитата(priam220 @ 16.9.2010,  22:00) возможно ли запускать Апи функции удаленно. Т.е. запуская программу на одном компъютере ждать выполнения Апи на другом? Можно запускать программы удаленно через WMI: Код 'Const HIDDEN_WINDOW = 0 Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2") Set objStartup = objWMIService.Get("Win32_ProcessStartup") Set objConfig = objStartup.SpawnInstance_ 'objConfig.ShowWindow = HIDDEN_WINDOW Set objProcess = GetObject("winmgmts:root\cimv2:Win32_Process") errReturn = objProcess.Create( "Notepad.exe", null, objConfig, intProcessID) В 2й строке вместо точки в \\.\ пишете имя компьютера, в последней вместо Notepad.exe имя запускаемой программы

Автор: priam220 17.9.2010, 17:39

xvr, близко, спасибо. Это пригодится тоже... А можно сделать тоже самое только без копирования на удаленный хост "блокнота" (т.е. проги), копирования в ручную. Из вышеуказанного кода выходит что прогу надо сначала поместить на удаленный хост, а потом запусить ее.

Автор: xvr 17.9.2010, 20:56

Цитата(priam220 @  17.9.2010,  17:39 ) А можно сделать тоже самое только без копирования на удаленный хост "блокнота" (т.е. проги), копирования в ручную. Нет. Цитата(priam220 @  17.9.2010,  17:39 ) Из вышеуказанного кода выходит что прогу надо сначала поместить на удаленный хост, а потом запусить ее.  Да

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)