Всем привет! Столкнулся с проблемой. Компилятор MinGW работаю разумеется под виндой... 7й (черт ее дери). Проблема заключается в следующем:
1) Составляю код вызова диалога (пусть будет тот же MessageBox)
2) Запускаю прилогу, вызываю диалог
3) Если я догадываюсь что надо нажать ALT то диалог открывается... если я продолжаю тупить, диалога я так и не увижу.

При всем при этом я даже пытался после вызова диалога (в процедуре диалога) послать сообщение hwndOwner окну в виде SendMessage с вызовом VK_MENU... в общем это уже похоже на то как беззубая собака грызет кость... чо делать то? Кто сталкивался с такой фигней? Проблем тока с диалогами и тока на 7й винде. Диалоги из того же wxWidget работают нормально O_o на всякие пожарные напишу пример того как я юзаю (вдруг найдется чудак, который код попросит)

MessageBox(_MainWindowHandle, "Dialog", "Title", MB_OK);

Хэндл окна рабочий, я по нему HDC и HGLRC юзаю и ОпенГЛ рисуется... в общем вот.

З.Ы. - финализация - вызываю диалог и для того что бы его увидеть надо дополнительно нажать ALT (вдруг кто то с тараканами не сможет сразу понять о чем речь)

Это сообщение отредактировал(а) NYX - 26.6.2011, 21:51

если грамотно манипулировать пользовательским временем, то GL можно и с простыми окнами подружить

подсказка: на вкладке "быстродействие" в диспетчере задач, в момент вызова диалога,
уровень загрузки ядер не должен стоять на 100%

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

попробуемс... о результате скоро напишу.

Результат
До запуска программы, загрузка ЦП 10%. После запуска 30%. После запуска диалога 30%. Устройство следующее:
* Из главного окна вызывается дочернее не модальное (WS_EX_TOOLWINDOW)
* Дочернее окно содержит кнопку Browse
* Диалог MessageBox(...) вызывается из дочернего окна и является модальным диалогом

Программа не зависает. Перед вызовом на всякие пожарные задизэйблил ВСЕ два окна и отрубил рендер (то есть WM_PAINT ничего не выполнял)....
все та же байда. После переноса проекта на ХР оказалось что и в ХР такая же фигня, до нажатия на ALT диалог не появляется. Приложение полностью входит в состояние при вызванном диалоге, но... даже на дизебленных коанх, до нажатия на АЛЬТ диалог не вылазит.

Это сообщение отредактировал(а) NYX - 27.6.2011, 16:33

Почти разобрался, переписал класс по новой. Глюк исчез. Завтра поковыряюсь, попытаюсь сравнить в чем разница, напишу ответ.

Это не вызов модального диалога созданного тобой. Нужно вызывать DialogBox()

Ваще MessageBox я как пример привел... точнее один из примеров. Вот например GetOpenFile работает через раз, в азвисимости от установленных флагов. С некоторыми он открывается сразу, а с некоторыми так же после нажатия на альт. Еще заметил такую закономерность, некоторые флаги с определенным название работают не по назначению. Ставил флаг (точно не помню) кажется об скрытии ридонли файлов, а он мне внешний вид диалога менял... не один из дефайнов я не изменял. Например когда ставлю флаг подтверждения перезаписи, то та же байда, снимаю флаг - диалог норм открывается. Потом диалог списка папок, аналогично, тока не зависимо от установленных флагов - отображается если жму альт. Диалог GetOpenFile ваще напроч отказывается работать с фильтрами. Создаю фильтр строкою вида "All\0*.*\0My\0*.my\0" и отображается только первый (нулевой) фильтр, а заместо остальных ваще абракадабра вылозит! Брал примеры и с MS сайта и с форумов и ваще по всему инету... один фиг! Жуткие бардаки. Напрашивается вывод о оверфлоу... следил за всеми переменными (их свыше двух сотен) не одна не течет. Даже проводил следственный эксперемент с ближайшим расположение буфера и смотрел течет ли в него чтонибудь или нет... ничего никуда не течет. Проверял через вотчесы. Счас скоро доберусь до кода, попробую сделать вывод о том, ПОЧЕМУ такая ерунда происходит. Никогда не было с этим проблем, как на 7ку пересел, появились какие то финты доселе неизвестные :( например - WS_POPUP окно, без стандартной рамки. Вешаю бордеры окна на OpenGL (самописные) и перетаскиваю окно с GL контролов (кстати ничем не хуже стандартных и производительность сильно не страдает, там тысячные секунды у меня выходили) если окно попадает к борту экрана, то оно разворачивается. Искал по нововведениям API в 7ке, так и не нашел как работает этот AERO SNAP. Видать где то очень глубоко зашит, до чего не то лень, не то не по уму просто. И опять же от случая к случаю. Предыдущий вариант ОБЕРНУТОГО В КЛАСС окна, был как заготовка к классу. Там POPUP окно не разворачивается. Разницы минимум, так как сначала код был в виде глобальной структуры переменных + функций обрабатывающих их. Потом в класс зафигачил, переименовал и все! Начался СНЭП :( Ваще ничего не дописывал. Так что вот так...
(Модальность диалога кажется указывается через Owner (владельца). Если таковой отсутствует, то диалог не модальный и не прекращает обработку сообщений вызвавшего окна. Я и так тоже пробовал, один фиг. Стало быть АЛЬТ обрабатывается не тем окном что диалог вызвало... а самим диалогом... в процедуру диалога я ваще не влазил. Точнее не планируется этого, ибо оно нафиг не нужно. Пытался влезть и отловить клавиши... и сэмитировать нажатие.. бесполезно)

Это сообщение отредактировал(а) NYX - 28.6.2011, 12:44

NYX, между делом, хоть абзатцы-то расставляй, пожалей наши больные головушки 

лечение в данном случае очень простое: создай проект с нуля и позови в нем какой-нить MessageBox  или DialogBox, запусти на семерке

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

бум смотреть, в чем дело  по другому - только на кофейной гуще гадать, но это уже на ТНТ, к экстрасенсам

Добавлено через 6 минут и 38 секунд
+ как вариант, посмотреть то же самое на другой семерке,

если сработает, значит есть какие-то проблемы с установленным ПО на тестируемой операционке

GremlinProg, да, спасибо! Я в общем то именно так и поступил.
Проблему нашел, исправил ошибку. Не смотря на обстоятельства, признаки... даже нет, следствие ошибки имеет постоянную основу. Дело было в HINSTANCE который устанавливался для дочернего окна. Этот самый дескриптор экземпляра приложения был объявлен "МИМО". Он был произвольно-пустым (мало того что он не имеет присвоения hInstance из WinMain, я его даже не NULL). Удивляет почему имеенно ALT!? Ну да ладно, будет время, поковыряюсь в подробностях, может не забуду про эту тему 

А еще вот на концовку, вопрос про эстетику. Не хочу нагромождать код всякими TRY CATCH, а решил убить одним выстрелом двух зайцев.
Сделал класс для обработки событий и ошибок  выглядит он до безумия просто:
1) Методы класса: SetEvent, SetEventOutput, CallEvent;
2) Данные класса: вектор Log

Идея:
* Размещение экземпляра класса в различных областях кода. Например ОКНО имеет встроенный экземпляр класса Event который отвечает за ошибки окна. Вздумается например добавить какуюнибудь фиговину к проге, добавлю класс и в нем будет свой экземпляр Event со своим списком ошибок.

Принцип:
1a) SetEvent(UINT Code, LPSTR Caption, BOOL Fatal, void(*Action)(LPVOID Arg));
1b) SetEvent(UINT Code, LPSTR Caption, BOOL Fatal, BOOL &Fatal);
        // &Fatal - флаг устанавливается в TRUE если вызваннай ошибка FATAL (например флаг выхода из цикла окна если ShowWindow вернул 0 
1с) SetEvent(UINT Code, LPSTR Caption, BOOL Fatal); // Action в варианте B и С ставится как NULL и не выполняется. Action хранится в векторе
2a) SetEventOutput(LPSTR FileName, BOOL File, BOOL Console, BOOL Beep); // метод оповещения. 
2b) SetEventOutput(BOOL File, BOOL Console, BOOL Beep); // метод оповещения. Если активирован хотя бы один флаг то история событий стирается. Если не активирован не один из флагов, то история событий хранится в векторе Log и доступна функция SaveLogToFile(LPSTR FileName);
3) CallEvent(666, "Comment %i", IntegerValue); // Тут в строку коммента можно выводить данные, например имена классов окна, которые уже были зарегестрированны... и прочее.

Далее уже при создании окна из моего класса, указываются некоторые установки СОБЫТИЙ, например файл лога, действия при ошибках (ну что то вроде аналога событий приложения уже...).

Как по вашему, этот метод эстетичен? Или это стрельба по мухам из водяного пистолета?

Это сообщение отредактировал(а) NYX - 4.7.2011, 12:24

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

я это делаю ( как мне кажется ) проще:

есть у меня один макрос

IOutput реализует метод printf, от него более ничего и не нужно

указатель на объект, его реализующий, передается в любой класс или функцию, где имеется не несколько проблемных ветвей кода,
и в этих ветвях пишется что-то вроде этого:

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

ну а реализовать IOutput можно уже как душе угодно: от банальной записи строки в файл,
до записи ее в сокет с отправкой лога на удаленный сервер диагностики ( хоть на почту отправляй  )

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

SetUnhandledExceptionFilter () ????
http://msdn.microsoft.com/en-us/library/ms...4(v=vs.85).aspx

GremlinProg, справедливо замечено  однако попробую оправдаться. Отловить такую ошибку - гоняться за приведениями. Я в смысле записи в лог. Ошибочная область кода писалась оооочень давно и как то видать с переносом кода я имена то и не заметил, понадеялся на авось может, а может просто пьяный был (стараюсь не исправлять в пьяном состоянии, ошибок еще больше получается). Там разница в именах в одну букву M и С как сокращенка от Main и Child  Ну зато слава богу в остальном ошибок заметых вроди бы нет. А поведение этой ошибки ваще загадочное.
Про отчет об ошибках, я в комментах своей функции так же проставляю __FILE_, __LINE__ и __FUNCTION__ но это на дорелизной версии, всеж потом лучше избавиться от лишних ссылок на код, хоть он и будет открытым. Но это уже другая тема. Мой класс он в общем то мизерный, самая большая функция это формирование строки отчета и то из-за времени (timeюр). Может когда нибудь и буду вылизовать код до минимального числа строк + мегаоптимизация, пока что не требуется  я один с кодом работаю  но метод с дефайном отправлю в записки  Ваще дефайны редко использую для функционала, в основном для констант, меня как то одна человека напугала сложностями, так я туда без лишнего стимула и не суюсь 
Dem_max, опять же TRY CATCH и какие то структуры проверок. Наверно просто напросто не требуется настолько высокий уровень отчетности. А проект у мя ваще не сложный, даже не смотря на суммарное число строк свыше 4к. Не люблю сильно-сложные примудрости в код вписывать, лучше несколько примитивов чем сильно запутанный клубок всяких зависимостей.
Спасибо всем еще раз!

Добавлено через 4 минуты и 13 секунд
Кстати в планах было сделать две версии DLL с отчетами об ошибках. В первой версии там будет отправка по сокету + вывод минимума данных на экран / файл. Вторая версия студийная, с расжатым выводом и без сетевых отчетов или наоборот с сетевым отчетом в реестр (если вдруг коллектив появится).

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

2. чтобы автоматически подставлять в printf макросы __FILE__ и __LINE__:


Это сообщение отредактировал(а) GremlinProg - 5.7.2011, 07:47

Макрос __VA_ARGS__ заставил истерично радоваться! Сколько строк сэкономить можно, без всяких там stdarg.h + va_* вызовов 

Это сообщение отредактировал(а) NYX - 5.7.2011, 13:55