Попытка создать свой MsgBox. Хе-хе

[Space]

Понадобилось сделать свой немодальный MyMsgBox на модальной форме (API MessageBox не устраивает). Сразу столкнулся с 2 проблемаи - не могу показать MyMsgBox поверх модальной формы, и, если расскоментить строку Command2.SetFocus (установка кнопки по умолчанию) - вообще мигание окно с подвисом (модальное окно не отдаёт фокус или что?)...

[Хакер]

О господи, дай мне силы это перенести.

Space, у тебя какие-то проблемы с пониманием? Я не знаю, какая чушь у тебя хранится в голове в качестве расшифровки понятия "модальное окно", но эта чушь полностью противоположена действительности.

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

Это полностью противоречит здравому смыслу и к счастью это ещё и технически невозможно сделать. VB на корню пресекает такие глупые попытки, WinAPI же, как я и говорил, предоставляют тебе возможность создать себе проблемы на одно место.

[Space]

ну спасибо, помог. У меня есть ещё вариантик. По сути мне надо, чтобы после вызова моего MsgBox управление возвращалась.

[Хакер]

Вот в этом и заключается модальность. Пока с окном не закончишь работать, управление не вернётся.

[Space]

я знаю. Сделал уж.

[Денис]

Понадобилось сделать свой немодальный MyMsgBox

Код: Выделить всё

Form2.Show vbModeless, Me

на модальной форме

Нонсенс! Неправильная архитектура программы рождает несуразные требования.

[Space]

а я могу установить своему MsgBox класс такой же, как у реального MsgBox? Как?

[Хакер]

Очередная чушь.

[Денис]

Очередная чушь.

Это не чушь, это так называемый "butthurt" (или, иначе говоря, обида, зависть). Друзья-дельфисты говорят ему: "вот, я могу своему классу-окну любое имя присвоить, для удобства и самодокументируемости. А у вас, в этих ваших бейсиках так не получится! Ха-ха!"
И вот наш герой с трясушимися ручками лезет на форум: "А как своему окну задать имя класса??"
А зачем? Что лично тебе, Space даст имя класса #32770 вместо ThunderRT6Main? Ну ладно, где-то на форуме был код, реализующий CreateWindow. Там ты сможешь создать окно с интересующим тебя именем класса.

[Хакер]

Вопрос именно в смене. Менять класс существующего окна --- чушь.

[Денис]

Вопрос именно в смене. Менять класс существующего окна --- чушь.

А ну это да.
Класс не меняется - он создается
Caption меняется - класс остаётся.

[Space]

чушь в смысле необоснованности смены или чушь в смысле невозможности изменить? Ладно, обосную - я хочу максимально приблизить свой MsgBox к реальным MsgBox'ам, чтобы сторонние программы при переборе окон определяли мой MsgBox как диалоговое окно реального MsgBox. CreateWindow? Мда...
Э... Уси окна косят на "ThunderFormDC"

[Antonariy]

Ладно, обосную - я хочу максимально приблизить свой MsgBox к реальным MsgBox'ам, чтобы сторонние программы при переборе окон определяли мой MsgBox как диалоговое окно реального MsgBox.

Редкой бессмысленности задача это.

Э... Уси окна косят на "ThunderFormDC"

Изменить имя класса не представляет сложности.

[Twister]

Изменить имя класса не представляет сложности.

Или я не выспался, или...

1. Расскажи как это сделать не влезая в ядро.
2. Расскажи как это сделать в ядре с гарантией того, что все будет работать так, как работало.

[Antonariy]

Это я ошибся. Просто есть в одной программке кнопка Class to change, я ей не пользовался, но почему-то считал, что она меняет имя класса как кнопка Window to change — текст заголовка.

[Twister]

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

[Хакер]

Не будет.

[Twister]

Нет-нет, так категорично я бы не заявлял. Имя класса - обычная null-terminated строка в структуре tagCLS. Я бы создал свой класс с нужным мне именем (чтобы он располагался в памяти там где надо и был виден и ядру, и юзермоду) и в подопытном классе просто изменил указатель. Повторю - тут только эксперимент может пролить свет, так как на вскидку ни каких подводных каменй не видно. Просто манипуляция структурами ядра силой своей воли и разума не всегда бывает безопасной, ошибка может вылезти там, где совсем этого не ожидаешь. Я вот, к примеру, так и не смог корректно изменить стили окна правкой байт в структуре tagWND. Но тут немного другое...

[Хакер]

Я имел в виду не только работу системы (ядра), но и стабильную работу всех прикладных программ.

Стабильность от такого трюка не может не нарушиться.

[Twister]

Я имел в виду не только работу системы (ядра), но и стабильную работу всех прикладных программ.

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

Стабильность от такого трюка не может не нарушиться.

А вот если мы не увидим синего экрана, тогда, я уверен, будет все окей, ибо я не вижу причин, по которым прикладные программы начали бы глючить. Ну получит прога с помощью GetClassName (да хоть прямым чтением ядерных структур!) fake-имя класса, ну и что?

[Хакер]

FindWindow-вызовы будут обламываться.

[Twister]

FindWindow-вызовы будут обламываться.

Ну конечно. Класс-то возвратится другой Но это уже, так сказать, не наши заботы.

[Денис]

Но это уже, так сказать, не наши заботы.

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

[Twister]

Денис, еще раз.

Если наша система вызывает падение ОС, то в топку такую систему, ни кто ее на рынок выпускать не будет. А если наша система, писанная на VB, создает свое окошко и корректно меняет ему класс, то что в этом страшного? Вопрос в другом: а надо ли это вообще? (С) Соседний топик

[Денис]

Денис, еще раз.

Если наша система вызывает падение ОС, то в топку такую систему, ни кто ее на рынок выпускать не будет. А если наша система, писанная на VB, создает свое окошко и корректно меняет ему класс, то что в этом страшного? Вопрос в другом: а надо ли это вообще? (С) Соседний топик

Тут надобно у Хакера уточнить, что он имел ввиду. Похоже что мы его поняли по-разному. Я понял так, что при замене имени класса для одного из загруженных образов процессов, начнут обламываться вызовы API-функции типа FindWindow, какое приложение бы ее не вызвало(!), понимаешь? Это натуральная нестабильность системы, когда начинают обламываться вызовы API. Вот как мне кажется что имел ввиду Хакер, сказав:

FindWindow-вызовы будут обламываться.

[Twister]

Я понял так, что при замене имени класса для одного из загруженных образов процессов, начнут обламываться вызовы API-функции типа FindWindow, какое приложение бы ее не вызвало(!), понимаешь?

Я тебя удивлю: область памяти, в которой располагаются гуёвые структуры общая для всех процессов, только спроецирована по разным адресам. Но не в этом дело. Дело в том, что мы меням класс НАШЕМУ ОКНУ. Какого же черта кто-то там вдуг обломится на FindWindow? Какая сторонняя утилита будет искать НАШИ окна и опираться в своей работе на их класс? Понимаешь о чем я говорю?

[Денис]

Какая сторонняя утилита будет искать НАШИ окна и опираться в своей работе на их класс?

Какая? Ну, например, мой qSelector. Он по таймеру перебирает все зарегистрированные окна, читает их параметры. Допустим вылетит вместе с нашим приложением только он, это еще ничего. А если следом повылетают какие-нибудь удаленно-управлялки или еще что-то специфичное? Сам видел в соседнем топике — чего только на местах не придумают: чтобы нужный софт работал, надо системное время на машине переводить (полагаю на 10 лет назад в девяностые).
Так что все это очень неоднозначно.

[Хакер]

Я имел в виду общий случай, в котором смена класса приведёт к тому, что кто-то перестанет находить фикснутое окно. Но в конкретном данном случае, хоть это и маловероятно, нельзя исключать, что msvbvm не ищет свои окно по классу.

[Twister]

нельзя исключать, что msvbvm не ищет свои окно по классу

Вооот... Наконец первая здравая мысль по поводу возможных конфликтов. Остальное, написанное выше, ни как не повлияет на работоспособность каких-либо утилит (еще раз: не найдет кто-то наше окно и ладно, ни одна здравая программа не вылетит с ошибкой из-за ненайденного окна). Короче, как я уже говорил, ясность внесет только эксперимент. Еще пару месяцев назад я бы с легкостью, только ради спортивного интереса, сам бы его провел. Но после кражи старого ноутбука я не ставил на новую машину ни WDK, ни WinDBG, ни, тем более, VB. И в ближайшее время не намерен. Так что...