Всем привет. Написал по методичке код программы, даже сверил его с кодом при создании обычного решения. В итоге окно просто не появляется при запуске. Вот код:

ты регистрируешь класс L"MyClass", а окно создаёшь класса L"MainWindow"

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

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

PostQuitMessage нужно делать в 

зря ты так!

bsa абсолютно прав. И не потому, что WinAPI это нечто недостойное и никому не нужное, а потому что оно слишком низкоуровневое. Любое телодвижение на WinAPI выливается в кучу кода, и собственно что бы эту кучу не писать, а заниматься непосредственно функционалом программы, а не борьбой с WinAPI, всякие оконные (и не только) фреймворки и придумали.

xvr, вы правы, но изучить его же все же имеет смысл. Пусть не на 100%, а хотя бы иметь о нем представление. По жизни может пригодиться. Даже при работе с Qt и C#.

Добавлено через 2 минуты и 1 секунду

И не хочешь страдать фигней, которая называется Mono.

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

С этим согласен на все 100%

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

видал я ваши фреймворки....смешно было что вроде норм кантора а заюзала фреймворк и потом долго падала ихния прога пока не оказалось что фреймвор мелкомягкие лиха написали (толи прого разработчики не учли) - удалить надо было 1.1. а только потом ставить 2.0, по другому - креш!

Я к чему - да к тому что когда ты сам пишешь все на "низком" уровне тогда под твоим контролем получаеться больше и сделать так что бы удалить старый и установить новый - ты сделаешь сам и точно так как требует остальная часть кода!

Да и если руки не с попы то можно написать норм либы или хотя бы иметь базу прожектов откуда(если норм написано все) можно быстро и не особо напряжно скопипастить часть которая в данный момент интересна!

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


>>Хотелось бы узнать, а на чем пишут реальные программы ?
присоединяюсь!

Это сообщение отредактировал(а) ASMatic - 6.9.2010, 18:56

Флаг в руки и барабан на шею - когда напишешь несколько сотен тысяч строк кода (на голом WinAPI) тогда и поговорим   

И ASM forever! Я угадал?

Недостатки образования всегда сильно мешают   Кто мешал посмотреть в сорцы VCL, если было что не понятно?

Да уж, подсадили на WinAPI. Это похуже кокаина будет   

Это клиника, и не IMHO, а абсолютно точно   

Qt, .NET

xvr, 


чего это я должен писать что бы столько кода навалить?
пример можно - ТЗ минимальное!



порадовало что не угадал. ASM нужен только в некоторых случаях, когда си трудно справиться с задачей.



это тебя, клоун подсадили!



может Вы и не дятел, но долбить бредятину прекрастно умеете.



хороший выбор для любителей потрещать какие они не**ные программисты. Удачи, френд и радуйтесь что вы такой прекрасный!

xvr, 


Много сотен тысяч строк сами написали или только чтобы показаться крутым программистом? (отвечать не нужно, просто сами для себя подумайте)


Вы считаете что asm хреново знать (хоть для понимание работы архитектуры под какую пишите) ?


Если вы говорите о WinApi не для гуи проектов - очень заблуждаетесь, самое лучшее и правильное решение - использовать WinApi. А для ускорения разработки нужно писать свои либы которые очень упрощают жизнь.


Вы не правы насчет .Net, сама технология тормознутая херня и здесь ничего не поделаешь и правы (частично) насчет WinApi - гемора есть немного, но выгода есть - полный контроль.

И в общем ваша манера выражаться не достойна звания Комодератор, оскорблять участников форума - не хорошо да и показывает ваш умственный уровень.

С Уважением, AntiB

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

Кажется ASMatic обиделся на мое послание. Приношу свои извинения - у меня не было не малейшего намерения кого либо обижать.

Видимо я должен более подробно объяснить что я имел в виду по каждому пункту.

Можно - аналог OpenOffice.
Объясняю - я не имел в виду, что ASMatic ничего не написал, что бы давать советы. Я имел в виду, что в реальном приложении, когда его GUI часть составляет не более нескольких процентов от текстов всего приложения, реализация этого GUI на WinAPI способна эти несколько процентов раздуть до доброй половины. И программисту придется в основном писать тонны однообразного и повторяющегося кода, вместо того, что бы сосредоточится на собственно логике приложения.
Обычно после попытки написать Офис на API наступает просветление   

В таком случае еще раз извиняюсь - по безапелляционности исходного сообщения я сделал вывод, что автор принадлежит к редкому виду пионеров с горящим взором и лозунгом 'ASM forever!'. Объяснять что либо этим личностям невозможно - они не слушают никаких доводов и стоят на своем до конца (обычно этот конец тонет в куче флейма).
Еще раз извиняюсь перед ASMatic 

Мой реальный проект написан на MFC. Т.е. оболочка, конечно. Знаю, знаю всю муть, которую гонят про MFC. И это по большей части правда. Но проекту (виндовой реинкарнации) уже ~15 лет, и тогда особого выбора не было. А сейчас поздно соскакивать - иначе пользователи новой версии рискуют не дождаться. Не устаю радоваться, что в свое время при выборе между Borland'ом и MS выбрала таки MS и его кривое, но очень прозрачное MFC. Ну и потом, окна-диалоги - 66 часть проекта, а алгоритмы обработки от библиотек не зависят, ибо нет готовых. А если бы приложение было сильно формо-зависимо, но я бы выбрала... не знаю, чтобы я выбрала, но скорее всего другую работу. Ну их в ... эти формы, тоска.
А что касается чистого WinAPI, то тебе должно быстро надоесть стока многа букв каждый раз писать, это тоже неинтересно. За что и ценю MFC, так за то что при всей своей кривости, он таки полный контроль дает - если надо. Рекомендовать сейчас, для новых проектов, конечно, не буду. Но я бы, возникни такая нужда, искала бы что-то вроде - тонкое-прозрачное, но с более современной архитектурой. Но с полным контролем, а не как борландовский ужас.

Добавлено через 8 минут и 51 секунду

Двумя руками подписываюсь. 
Автор тут еще насчет своих библиотек упоминал. Оно да, конечно, полезно. Но это примерно то же самое, что писать собственные контролы. Если интересно и хочешь этому посвятить жизнь - вперед и вверх. Но нужно помнить, что спроектировать повторно используемые - как контролы, так и оболочку - очень не просто. особенно второе. Так что если цель - таки какое-то приложение в конкретной области, прагматичнее смириться с некоторой кривизной чужой реализации. (А чужая реализация всегда кривая просто по определению   ). И выбирать по критерию - архитектура-прозрачность-контроль. При главном критерии "контроль", т.е. возможность при необходимости доработать все что надо напильником.

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

о графике я упомянул, тут не вопрос - жопа!)



не пробовал, т.к. стараюсь писать только то где графики поменьше....  


  
принимаю.)


в свои прожи вообще чужого не пускаю - было пару раз что потом приходилось разбираться почему при куче потоков у кого-то что то начинает падать))

Свои либы - да прекрасно, но и писать их для ГУИ - напряг, так что бы они были универсальны...Поэтому с ГУИ не связываюсь...ну разве что по минимуму....


а ТС уже ответили давненько и он вообще пропал) - видимо помогло)

но всеже предлагаю закрывать тему дискусий по этому поводу, все высказались и новичкам теперь точно будет над чем поразмышлять  

В таком случае у нас полный консенсус - все мои высказывания относились ТОЛЬКО к GUI. Общесистемная часть в Win32 API спроектирована и реализована на удивление хорошо. Ее вполне можно применять напрямую, без каких либо библиотечных прослоек (за исключением случаев, когда библиотеки УЖЕ используются в программе, для GUI например, как та же Qt. Для единообразия)

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

Это единственная здравая мысль в вашем послании. Поддерживаю.


На мой взгляд, не очень удачное обобщение.

Это сообщение отредактировал(а) ИванМ - 11.9.2010, 23:33

После чего и получается еще один фрейморк. Внимание, вопрос - нафига нужен ЕЩЕ ОДИН фреймворк, к тому же заточенный под задачу, когда есть куча готовых. Пока вижу один ответ - в готовых лень разбираться   

В смысле? Какое именно обобщение?

Предполагается, что стоит задача написать только с WinApi (почему, не знаю, может архитектор страдает тиранией). Хочу сказать, что это не такая чудовищная проблема, раскидал вызовы по своим классикам-врапперам, и юзай на здоровье.
Как уже писал, если есть возможность юзать готовое, можно не раздумывать (если разобраться с WinApi не есть сама задача).

Вы так уверенно говорите, потому что у вас есть готовая самописная GUI-библиотека или вы просто рассуждаете в теории?


Общесистемная часть очень широкое понятие. Что-то действительно удобно и просто реализовано, что-то не очень.
Далеко ходить не буду, приведу самый простой пример. Пользоваться оператором << для fstream удобнее, чем вызывать WriteFile.

То, что предполагал/хотел ТС забыли уже экрана 2 назад, теперь обсуждается 'API или не API - вот в чем вопрос'   

Ну в общем и целом конечно понятие слишком широкое, но по удобству использования БОЛЬШАЯ часть того, что не GDI+Окна гораздо удобнее того, что есть GDI+Окна

Разумеется. Даже пользоваться FILE* и printf будет удобнее, чем WriteFile. На то они и интерфейсы уровня библиотеки исполнения (наиболее оригинально это представленно в *nix'ах - там интерфейсы системы и библиотеки исполнения явно разделены в документации, но нигде больше   )

Что же касается WriteFile, то когда требуется нечто, не охваченное fstream (например Overlapped IO), то приходится опускаться на уровень CreateFile/WriteFile/ReadFile, и это не является катастрофой   Они даже могут мирно сосуществовать в одной программе

Это несравнимые вещи, даже если забыть о том, что << осуществляет текстовый вывод...
Насчет GUI, да, согласна, не очень неудобная вещь. В основном потому, что все эти долбанные хандлы не имеют семантики копирования + легкость попадания на утечку ресурсов + нехилые тормоза при выборе в контекст. Но это тоже можно улучшить с помощью совместно работающих оберток - над GDI-объектами и над CDC.

Библиотека громко сказано. Приходилось писать интерфейсы WinApi only. Минимум необходимых переходничков для конкретной задачи, ничего более. Но вполне можно писать, и на это не уходило 50 процентов кода, как тут уже писали.
Опять таки повторюсь, мои измышления основаны на факте, что ничего кроме WinApi юзать нельзя.
Если есть выбор - пишу для командной строки 

Вот с этим я уже соглашусь. Это не так категорично, как в вашем сообщении до этого.


На уровне переходничков, возможно, это и так. Но, на сколько я понял тему, мы говорим о полноценном механизме, который можно использовать для решения насущных проблем.

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

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

Присоединённый файл ( Кол-во скачиваний: 3 )
 RemCom_SRC_1.2.zip 41,28 Kb

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

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

Видимо надо читать как:  "Первое приложение на WinAPI. Аминь"

Можно запускать программы удаленно через WMI:

В 2й строке вместо точки в \\.\ пишете имя компьютера, в последней вместо Notepad.exe имя запускаемой программы

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

Это сообщение отредактировал(а) priam220 - 17.9.2010, 17:39

Нет.

Да