Уникалоность hwnd?
Вопрос: в каких ос (NT/2000/2003/9x/me) мелкосовт гарантирует уникальность дескриптора окна (hwnd) в рамках одной сессии?
Не могу нигде найти про уникальность hwnd.
Вопрос: в каких ос (NT/2000/2003/9x/me) мелкосовт гарантирует уникальность дескриптора окна (hwnd) в рамках одной сессии?
Не совсем понятно, какую сессию ты имеешь в виду.
В каждый конкретный момент времени hwnd уникален в люой из перечисленных ОС. Это следует из определения:
window handle
A value, assigned by the system, that uniquely identifies a window.
Не совсем понятно, какую сессию ты имеешь в виду.
В каждый конкретный момент времени hwnd уникален в люой из перечисленных ОС. Это следует из определения:
Пример для понимания проблемы:
Два потока (или даже процесса) работают с одним и тем же окном. Обращаются к нему (идентифицируют его) через hWnd
В одном из них (пусть в ПЕРВОМ, для определенности) ставим бряк и держим.
В это время во втором потоке дестроим окно. И создаем кучу новых. Огромную кучу: наприер 10 тысяч.
После отпускаем бряк в первом потоке.
Впрос: высока ли вероятность того, что первый поток обращаясь по запомненому hWnd к тому окну с которым работал, нарвется на новое окно?
P/S Так как hwnd это 4 байта, то очевидно, допустимых значений порядка 4 млрд.
Есть ли хоть какие-нибуть правила выдачи очередного window handler?
Пример для понимания проблемы:
Два потока (или даже процесса) работают с одним и тем же окном. Обращаются к нему (идентифицируют его) через hWnd
В одном из них (пусть в ПЕРВОМ, для определенности) ставим бряк и держим.
В это время во втором потоке дестроим окно. И создаем кучу новых. Огромную кучу: наприер 10 тысяч.
После отпускаем бряк в первом потоке.
Впрос: высока ли вероятность того, что первый поток обращаясь по запомненому hWnd к тому окну с которым работал, нарвется на новое окно?
P/S Так как hwnd это 4 байта, то очевидно, допустимых значений порядка 4 млрд.
Есть ли хоть какие-нибуть правила выдачи очередного window handler?
Ситуацию понял.
На самом деле значений hwnd значительно меньше 4 млрд.
В книге М.Питрека (правда про W95) их ~32тыс., думаю для обратной совместимости оно так и оставлено, хотя не уверен.
Твой вопрос теоритический или имеет практическое значение?
Если практическое, то может, есть смысл предотвращать такую возможность какими-то доп. мерами, зависящими от конкретной задачи.
На самом деле значений hwnd значительно меньше 4 млрд.
В книге М.Питрека (правда про W95) их ~32тыс., думаю для обратной совместимости оно так и оставлено, хотя не уверен.
В 95-й общее число hwnd действительно не могло превышать 32k. Поэтому и существовала проблема недостаточности ресуров в перегруженных контролами приложениях.
В NT GDI намного мощнее, в том числе и hwnd может быть намного больше, особенно в XP, с ее поддержкой тем.
А уникальны hwnd, не уникальны hwnd - науке это неизвестно. ;)
Пример для понимания проблемы:
Два потока (или даже процесса) работают с одним и тем же окном. Обращаются к нему (идентифицируют его) через hWnd
В одном из них (пусть в ПЕРВОМ, для определенности) ставим бряк и держим.
В это время во втором потоке дестроим окно. И создаем кучу новых. Огромную кучу: наприер 10 тысяч.
После отпускаем бряк в первом потоке.
Впрос: высока ли вероятность того, что первый поток обращаясь по запомненому hWnd к тому окну с которым работал, нарвется на новое окно?
P/S Так как hwnd это 4 байта, то очевидно, допустимых значений порядка 4 млрд.
Есть ли хоть какие-нибуть правила выдачи очередного window handler?
Немного смешная проблема. Возникла она в следствии неправильно спроектированной программы. На самом деле когда ты дестроишь окно, ты должен прекращать всякое использование его handle, и явным образом снимать так сказать этот handle с "боевого дежурства", например уведомляя об этом первый поток. Господа, изучайте паттерны программирования и лучше всего без крайней нужды от них не отклоняйтесь.
Немного смешная проблема. Возникла она в следствии неправильно спроектированной программы.
Согласен, ноги растут из неправильной архитектуры.
Господа, изучайте паттерны программирования и лучше всего без крайней нужды от них не отклоняйтесь.
Забавная и нелепая фраза :D
1) видимо ты имел в виду паттерны проектирования или может какие-нибудь другие, например паттерны ошибок?
2) паттерны имеют смысл там, где они имеют смысл, излишнее дробление ни к чему;
3) отклоняться от чего? паттерны проектирования - не свод правил или законов, это всего-лишь обобщенные блоки для построения архитектуры проекта.
P.S. Когда-то сразу после знакомства с паттернами я тоже пытался применять их по всем правилам науки где ни попадя. :)
Потом был Александреску, и коллеги взвыли от обилия шаблонов.
Теперь есть XP и оно многое отсеяло.
В 95-й общее число hwnd действительно не могло превышать 32k. Поэтому и существовала проблема недостаточности ресуров в перегруженных контролами приложениях.
В NT GDI намного мощнее, в том числе и hwnd может быть намного больше, особенно в XP, с ее поддержкой тем.
Спасибо. Про 32k для w95 для меня новость. Кстати, а на что резирвируются оставшиеся 2 байта + бит? , вообще хотелось бы по подробней узнать о "путях господнях" по генерации hwnd.
По поводу, неправильно спроектированной программы. Дело в том, что это две программы. К тому же одна из них написана на VB (без доступа к сорцам) и, к тому же, норовит у своих ключевых окон подменять WndProc. Причем очень часто и по поводу и без повода (наверно новый писк по защите кода).
Согласен, ноги растут из неправильной архитектуры.
Забавная и нелепая фраза :D
1) видимо ты имел в виду паттерны проектирования или может какие-нибудь другие, например паттерны ошибок?
2) паттерны имеют смысл там, где они имеют смысл, излишнее дробление ни к чему;
3) отклоняться от чего? паттерны проектирования - не свод правил или законов, это всего-лишь обобщенные блоки для построения архитектуры проекта.
P.S. Когда-то сразу после знакомства с паттернами я тоже пытался применять их по всем правилам науки где ни попадя. :)
Потом был Александреску, и коллеги взвыли от обилия шаблонов.
Теперь есть XP и оно многое отсеяло.
1. Я имед ввиду паттерны в самом широком смысле слова. Не только паттерны OOP. По моему глубокому убеждению весь мир - это набор паттернов. Matrix have you :D.
2. Если проект развивается то это как правило означает что его внутренняя архитектура именно начинает дробиться(читай: начинается специализация и развитие отдельных элементов). Мой опыт говорит мне о том что лучше наооборот очень тщательно и подробно расписать программу на классы и объекты как можно подробнее. Если это сделано грамотно то как правило развивать такую систему легко и приятно, и даже становится просто скучно. При любом другом подходе просто получаются одноразовые программы, так как при возникновнии новых требований (говорящих о каком либо серьезном развитии), проект просто сыпется, и в лучшем случае приходится все переписывать с нуля, но теперь уже по паттернам. Все бы ничего, но большинство тупоголовых менеджеров поставленных руководить процессом разработки воспримают заявления о переработке с нуля крайне неадекватно.
Если же новых требований не возникает то эта программа просто нахрен не кому не нужна.
:)
3. При желании можно провести очень глубокую аналогию между правилами и законами и обощенными блоками для построения архитектуры.
1. Я имед ввиду паттерны в самом широком смысле слова. Не только паттерны OOP. По моему глубокому убеждению весь мир - это набор паттернов. Matrix have you :D.
Параноя? ;)
2. Если проект развивается то это как правило означает что его внутренняя архитектура именно начинает дробиться(читай: начинается специализация и развитие отдельных элементов). Мой опыт говорит мне о том что лучше наооборот очень тщательно и подробно расписать программу на классы и объекты как можно подробнее. Если это сделано грамотно то как правило развивать такую систему легко и приятно, и даже становится просто скучно. При любом другом подходе просто получаются одноразовые программы, так как при возникновнии новых требований (говорящих о каком либо серьезном развитии), проект просто сыпется, и в лучшем случае приходится все переписывать с нуля, но теперь уже по паттернам. Все бы ничего, но большинство тупоголовых менеджеров поставленных руководить процессом разработки воспримают заявления о переработке с нуля крайне неадекватно.
Если же новых требований не возникает то эта программа просто нахрен не кому не нужна.
:)
Господа, изучайте XP и лучше всего без крайней нужды не плодите классы, не расписывайте что-либо подробно и почаще переписывайте все с нуля (рефакторинг). :)
Надеюсь, про тупоголовых менеджеров - камень не в мой огород... :D
3. При желании можно провести очень глубокую аналогию между правилами и законами и обощенными блоками для построения архитектуры.
А зачем? Зачем делать ненужные вещи?
Лучше создать метафору для общения внутри команды и с заказчиком.
Параноя? ;)
Как было кем то сказано : если у тебя паранойя это не значит что тебя действительно не преследуют. На самом деле у этого утверждения ( о вселенной как наборе паттернов) есть серьезное научное обоснование, что вы знаете об общей теории паттернов ?
Господа, изучайте XP и лучше всего без крайней нужды не плодите классы, не расписывайте что-либо подробно и почаще переписывайте все с нуля (рефакторинг). :)
по моему скромному мнению XP - это изобретение какого-то шутника. Видно придумали аналитики из Мелкософта для всякого рода романтиков от программирования, с целью обезопасить себя на рынке ПО, сейчас ведь в моде все extrem, ну так давай еще extrem programming изобретем. Просто смешно смотреть как люди на это ведутся. Хотелось бы узнать о каких-либо действительно успешных проектах написанных на этой так называемой методолгии. Мне почему то кажется что лучшие системы написаны основываясь совсем на других идеях. Крому того рефакторинг - это не переписывание с нуля, а просто иная организация одно и того же кода, что фактически означает приведение его в соответвии с тем или иным паттерном.
Надеюсь, про тупоголовых менеджеров - камень не в мой огород... :D
Этот камень - в огород всех тупоголовых менеджеров. :D
А зачем? Зачем делать ненужные вещи?
Лучше создать метафору для общения внутри команды и с заказчиком.
Зачем изобретать всякие метафоры? Изложенные в литературе паттерны OOP это наиболее оптимальные решения на данный момент времени. А зачем использовать менее оптимальные решения? Как было сказано у Гради Буча : в мире очень мало гениев и не надо думать что среди программистов их процент выше.
Надеюсь, про тупоголовых менеджеров - камень не в мой огород...
Этот камень - в огород всех тупоголовых менеджеров.
Паттерны обычной жизни:
- Не пойман - не вор.
- На воре шапка горит.
И ни слова про матрицу. ;)
На самом деле у этого утверждения ( о вселенной как наборе паттернов) есть серьезное научное обоснование, что вы знаете об общей теории паттернов ?
Ой ля, куда ты замахнулся. Ага и в библии сказано "по образу и подобию своему"... :D
Не следует обожествлять инструмент или методику.
Методика лишь там хороша, для чего она создана и где ей место.
На досуге переведи слово "паттерн" и прикинь есть ли в этом понятии что-нибудь новое, что нигде и никогда ранее не применялось.
по моему скромному мнению XP - это изобретение какого-то шутника. Видно придумали аналитики из Мелкософта для всякого рода романтиков от программирования, с целью обезопасить себя на рынке ПО, сейчас ведь в моде все extrem, ну так давай еще extrem programming изобретем.
Майкософт придумал MSF, но не XP.
Ты хоть немного знаком с принципами XP или только то, что на слуху?
Сколькими проектами ты руководил? Какую методику использовал?
Просто смешно смотреть как люди на это ведутся. Хотелось бы узнать о каких-либо действительно успешных проектах написанных на этой так называемой методолгии.
Дык, пожалуйста: r-tt.com
А мне лично смешно смотреть, как люди морщат лица рисуя диаграммы, печатая ворох документации, пытаются предусмотреть все до реализации, дробят, разделяют, а потом латают разъезжающийся по швам проект.
Крому того рефакторинг - это не переписывание с нуля, а просто иная организация одно и того же кода, что фактически означает приведение его в соответвии с тем или иным паттерном.
Ну чтож ты так заточился на паттерны.
Патерны - инструмент, а не идеология. Говорю тебе об этом, как человек каждодневно имеющий с ними дело. Паттерны не противоречат XP (как и обратно), т.к. они находятся в разных плоскостях. XP - методика управления процессом разработки, паттерны - элементы архитектуры.
Цель рефакторинга не "приведение в соответствие с тем или иным паттерном", т.к. не к чему приводить, нет строгих критериев паттерна, а модернизация кода с целью его упрошения.
Паттерн может быть реализован так и в той мере, как это нужно для поддержания целостности архитектуры и обеспечения функциональности. Ты все равно не сможешь обеспечить все возможные варианты, написать ИДЕАЛЬНУУЮ РЕАЛИЗАЦИЮ ПАТТЕРНА.
Как и любую сложную геометрическую фигуру, архитектуру ПО, можно разбить на множество вариантов множеств простейших фигур (паттернов), при чем каждый из вариантов будет вполне жизнеспособным и отличаться чем-то от других в лучшую сторону. Проектирование - не поиск единственоправильного решения, а выбор наиболее подходящего.
Изложенные в литературе паттерны OOP это наиболее оптимальные решения на данный момент времени. А зачем использовать менее оптимальные решения?
Патерны - это не решения, это всего лишь формализованная методика описания архитектуры.
Паттерны - это нежесткие завершенные и не подлежащие изменению атомы.
К примеру "паттерн" рисования "дом". У него есть отличительные черты: стены крыша, двери окна. Но никакой строгости и завершенности: это может быть избушка, а может быть небоскреб, с трубой или вертолетной площадкой. В конце концов у него может и не быть окон или крыши, или он может быть совмещен с паттерном "гараж".
Ой ля, куда ты замахнулся. Ага и в библии сказано "по образу и подобию своему"... :D
Не следует обожествлять инструмент или методику.
Методика лишь там хороша, для чего она создана и где ей место.
На досуге переведи слово "паттерн" и прикинь есть ли в этом понятии что-нибудь новое, что нигде и никогда ранее не применялось.
1. То что сказано в библии - на совести того кто ее написал. :D
2. Я не слова ни говорил об обожествлении.
3. Судя по всему об общей теории паттернов ты ничего не знаешь.
4. Слово паттерн переводится - образец решения задачи. (переводчик Lingo 8.0)
Теперь обратимся к Гради Бучу:
Цитата 1:
Звезда в предверии коллапса; ребенок который учится читать; клетки крови атакующие вирус, - это только некоторые из потрясающе сложных объектов физического мира. ... "Эйнштейн утверждал, что должны существовать простые объяснения природных процессов , так как бог не действует из каприза или по произволу..."(прим.от меня чего не скажешь о программистах :D)
Цитата 2:
Большинство ПК состоит из одних и тех же основных элементов: системной платы, монитора, клавиатуры... (прим.от меня тебе не кажется что это паттерн ?)... Мы можем взять любую из этих частей и разложить ее в свою очередь на оставляющие. Системная плата, например, содержит оперативную память, центральный процессор(ЦП) и шину... (прим.от меня тебе не кажется что это паттерн ?).... Каждую из этих частей можно также разложить на составляющие: ЦП состоит из регистров и схем управления, которые в свою очередь состояи из еще более простых деталей: диодов, транзисторов и т.д. (прим.от меня тебе не кажется что это паттерн ?)
....
Растение состоит из трех основных частей: корни, стебли и листья (прим.от меня тебе не кажется что это паттерн ?). Каждая из них имеет свою особую структуру..... Внутри каждой клетки можно выделить следующий уровень, который включает в себя хлоропласт, ядро и т.д.(прим.от меня тебе не кажется что это паттерн ?)....
вообщем там дохрена еще таких примеров с атомами, галактиками социальными институтами и т.п.
Майкософт придумал MSF, но не XP.
Ты хоть немного знаком с принципами XP или только то, что на слуху?
Сколькими проектами ты руководил? Какую методику использовал?
Гмс... я хотел сказать (в виде шутки) что MS придумала ее тайно....технология непрямого воздействия.... :D Я работал lead developerom последние два года... проектов было 3 или 4. Методика та же что и у древних мыслителей : divide et impera. Другими словами я рисовал общую архитектуру в виде раздельных подсистем, над каждой подсистемой работали разные люди, и так далее рекурсивно...
Дык, пожалуйста: r-tt.com
А мне лично смешно смотреть, как люди морщат лица рисуя диаграммы, печатая ворох документации, пытаются предусмотреть все до реализации, дробят, разделяют, а потом латают разъезжающийся по швам проект.
гмс.... помнится в одном проекте нарисовав одну стрелочку на диаграмме я сэкономил себе 3-4 месяка работы...весь вопрос в умении это делать :). я разрабатывал граф.станцию контроля воздушного пространства... через некоторое время после сдачи проекта мне сказали что если бы моя система стояла в Германии то той катастрофы военного грузового самолета с российским пасажирским самолетом с детьми не было бы...
Ну чтож ты так заточился на паттерны.
Патерны - инструмент, а не идеология. Говорю тебе об этом, как человек каждодневно имеющий с ними дело. Паттерны не противоречат XP (как и обратно), т.к. они находятся в разных плоскостях. XP - методика управления процессом разработки, паттерны - элементы архитектуры.
Цель рефакторинга не "приведение в соответствие с тем или иным паттерном", т.к. не к чему приводить, нет строгих критериев паттерна, а модернизация кода с целью его упрошения.
я не говорил что цель рефакторинга - приведение в соответсвии с тем или иным паттернм.... просто по смыслу это эквивалентно этому. Как правило код написанный в соответвии по паттерну как раз есть простой и понятный... а возникло это вследствии модернизации кода необходимость в которой была вызвана несовершенством кода.. как правило после таких модернизаций код начинает соответсвовать некоторому паттерну..
Паттерн может быть реализован так и в той мере, как это нужно для поддержания целостности архитектуры и обеспечения функциональности. Ты все равно не сможешь обеспечить все возможные варианты, написать ИДЕАЛЬНУУЮ РЕАЛИЗАЦИЮ ПАТТЕРНА.
Как и любую сложную геометрическую фигуру, архитектуру ПО, можно разбить на множество вариантов множеств простейших фигур (паттернов), при чем каждый из вариантов будет вполне жизнеспособным и отличаться чем-то от других в лучшую сторону. Проектирование - не поиск единственоправильного решения, а выбор наиболее подходящего.
Патерны - это не решения, это всего лишь формализованная методика описания архитектуры.
Паттерны - это нежесткие завершенные и не подлежащие изменению атомы.
К примеру "паттерн" рисования "дом". У него есть отличительные черты: стены крыша, двери окна. Но никакой строгости и завершенности: это может быть избушка, а может быть небоскреб, с трубой или вертолетной площадкой. В конце концов у него может и не быть окон или крыши, или он может быть совмещен с паттерном "гараж".
Дело в том что понятие "паттерн" можно применять весьма широко и в совершенно различных плоскостях..
3. Судя по всему об общей теории паттернов ты ничего не знаешь.
Я знаю довольно много о паттернах проектирования ПО. И мне этого достаточно.
4. Слово паттерн переводится - образец решения задачи. (переводчик Lingo 8.0)
Правильнее использовать как перевод слово "шаблон" или "модель".
< Красноречивые цитаты поскипаны, т.к. не несут в себе ничего нового и конкретного. >
Гмс... я хотел сказать (в виде шутки) что MS придумала ее тайно....технология непрямого воздействия.... :D Я работал lead developerom последние два года... проектов было 3 или 4. Методика та же что и у древних мыслителей : divide et impera. Другими словами я рисовал общую архитектуру в виде раздельных подсистем, над каждой подсистемой работали разные люди, и так далее рекурсивно...
И как часто происходила интеграция? Сколько времени уходило на составление документации и как быстро она устаревала?
гмс.... помнится в одном проекте нарисовав одну стрелочку на диаграмме я сэкономил себе 3-4 месяка работы...весь вопрос в умении это делать :).
Ты сам то в это веришь?
Очень похоже на рекламный бред.
я разрабатывал граф.станцию контроля воздушного пространства... через некоторое время после сдачи проекта мне сказали что если бы моя система стояла в Германии то той катастрофы военного грузового самолета с российским пасажирским самолетом с детьми не было бы...
А также трагедии с "Курском", 11-го сентября, ВОВ и т.п. :D
я не говорил что цель рефакторинга - приведение в соответсвии с тем или иным паттернм....
Ну значит меня зрение подводит:
"Крому того рефакторинг - это не переписывание с нуля, а просто иная организация одно и того же кода, что фактически означает приведение его в соответвии с тем или иным паттерном."
просто по смыслу это эквивалентно этому.
Опять промашка. Рефакторинг в большинстве случаев начинается с переработки реализации паттернов.
Как правило код написанный в соответвии по паттерну как раз есть простой и понятный...
Опять же бредовая фраза. Как что-то может соответствовать паттерну, если сам паттерн - это не что-то жесткое?
Кроме того, код не надо пререрабатывать в соответствие. Код должен быть с самого начала написан согласно спроектированной архитектуре. Простота и понятность кода не связана с паттернами, т.к. код - это всего лишь реализация паттерна.
а возникло это вследствии модернизации кода необходимость в которой была вызвана несовершенством кода.. как правило после таких модернизаций код начинает соответсвовать некоторому паттерну..
Я, кажется, понял о чем ты говоришь.
Твоя проблема в том, что ты пытаешься идти от обратного: есть код, пытаемся подогнать его под теорию паттернов. На самом же деле все пляшется от обратного: есть архитектура, описанная системой паттернов, далее реализуем эти паттерны (в случае XP не по одиночке, а постепенно все одновременно, в пределах итерации), достигнув результата, перерабатываем реализацию для упрощения кода (рефакторинг).
При этом заметь нет смысла реализовфывать паттерн на все 100% (хотя бы потому, что это невозможно), достаточно реализовать его на столько, на сколько это необходимо. В этом и заключается отсутствие какой-то жесткости и четкой завершенности того или иного паттерна.
Дело в том что понятие "паттерн" можно применять весьма широко и в совершенно различных плоскостях..
... аналогично как и другие его синонимы: шаблон, модель, образец, класс. Ну и что?
Честно говоря, я не могу понять суть твоего монолога, как и предмет спора.
Ты хочешь открыть нам глаза на существование паттернов проектирования?
Спасибо, мы знаем о них и пользуемся не первый год этой методикой.
Ты хочешь показать, что в мире наблюдается подобие и возможность деления сложных систем на более простые?
Мы и это знаем. И в этом нет ничего нового, это называется аддитивность или экстенсивность, этим и занимается архитектурное проектирование. В принципе этим занимается любое проектирование ещё с незапамятныз времен.
Ты открыл для себя новое понятие и пытаешься рассказать нам об этом?
Поздравляю, но особого взлета я здесь не вижу.
Так что донести то хотел?
Я знаю довольно много о паттернах проектирования ПО. И мне этого достаточно.
вопрос был об общей теории паттернов а не об ее частном случае - паттернах ПО.
Правильнее использовать как перевод слово "шаблон" или "модель".
Я думаю составитель перевоода Lingvo гораздо более компентнее тебя в этом вопросе :D
И как часто происходила интеграция? Сколько времени уходило на составление документации и как быстро она устаревала?
Интеграция происходила так часто как это было необходимо... Документации было миниум... Кроме того ты не ответил какие известные проекты были созданы с помощъю XP? Может потому что их просто нет :D Как говорит один мой знакомый - лох - это судьба.
Ты сам то в это веришь?
Очень похоже на рекламный бред.
Мда... похоже твоим основным достижением в разработке софта является прога 20 раз выводящая на экран предложение "Hello, world". :D
А также трагедии с "Курском", 11-го сентября, ВОВ и т.п. :D
Это уже оскорбление... пошевели мозгами(если они у тебя есть, в чем я сильно сомневаюсь) попробуй написать прогу которая 25 раз выведет на экран предложение "Hello, world" и при это не посыпется. Я думаю с твоим отрицательным уровнем IQ лет через 20 у тебя получится. :D
Ну значит меня зрение подводит:
"Крому того рефакторинг - это не переписывание с нуля, а просто иная организация одно и того же кода, что фактически означает приведение его в соответвии с тем или иным паттерном."
К сожалению ввиду низкого уровня развития твоего мышления тебе никогда не понять истинного смысла этого утвержедния. Грустно....
Опять промашка. Рефакторинг в большинстве случаев начинается с переработки реализации паттернов.
Вероятно тот камень был и в твой огород... :D
Опять же бредовая фраза. Как что-то может соответствовать паттерну, если сам паттерн - это не что-то жесткое?
Кроме того, код не надо пререрабатывать в соответствие. Код должен быть с самого начала написан согласно спроектированной архитектуре. Простота и понятность кода не связана с паттернами, т.к. код - это всего лишь реализация паттерна.
Я, кажется, понял о чем ты говоришь.
Твоя проблема в том, что ты пытаешься идти от обратного: есть код, пытаемся подогнать его под теорию паттернов. На самом же деле все пляшется от обратного: есть архитектура, описанная системой паттернов, далее реализуем эти паттерны (в случае XP не по одиночке, а постепенно все одновременно, в пределах итерации), достигнув результата, перерабатываем реализацию для упрощения кода (рефакторинг).
При этом заметь нет смысла реализовфывать паттерн на все 100% (хотя бы потому, что это невозможно), достаточно реализовать его на столько, на сколько это необходимо. В этом и заключается отсутствие какой-то жесткости и четкой завершенности того или иного паттерна.
... аналогично как и другие его синонимы: шаблон, модель, образец, класс. Ну и что?
Честно говоря, я не могу понять суть твоего монолога, как и предмет спора.
Ты хочешь открыть нам глаза на существование паттернов проектирования?
Спасибо, мы знаем о них и пользуемся не первый год этой методикой.
Ты хочешь показать, что в мире наблюдается подобие и возможность деления сложных систем на более простые?
Мы и это знаем. И в этом нет ничего нового, об этом говорит в частности та же теория относительности.
Ты открыл для себя новое понятие и пытаешься рассказать нам об этом?
Поздравляю, но особого взлета я здесь не вижу.
Так что донести то хотел?
то бишь.. комментировать каждую строчку этого предложения заеб... можна. А ты помнишь с чего началась эта дисскусия? Ты пользуясь своей логикой начал размышлять скоко у window handle значений.
На самом деле значений hwnd значительно меньше 4 млрд.
В книге М.Питрека (правда про W95) их ~32тыс., думаю для обратной совместимости оно так и оставлено, хотя не уверен.
Просто смешно. Элементарная логика и здравый смысл говорят о том что после того как объект который представляет handle уничтожен то данный handle использовать нельзя... а ты : скоко ж у handle значений? я смеялся аж до истерики... вот она квинтэссенция всемирной тупости. А потом самолеты в небоскребы врезаются.... вот так то товарищи...
Я думаю составитель перевоода Lingvo гораздо более компентнее тебя в этом вопросе :D
Представляешь, у одного слова может быть несколько значений. Загляни в словарь.
Интеграция происходила так часто как это было необходимо... Документации было миниум...
Как часто это было необходимо и чем определялась необходимость?
Минимум - это сколько? Можешь привести перечень?
Кроме того ты не ответил какие известные проекты были созданы с помощъю XP?
Честно говоря, об известных проектах не знаю, впрочем не знаю какие методы применялись при разрабюотке большинства известных проектов. Не метод разработки делает проект известным.
Мне достаточно того, что XP (точнее, применение некоторых её практик) помогает в нашей работе.
Что же касается моих достижений, то они не для кого не секрет, но членами я меряться не собираюсь.
По поводу твоих абстрактных рассуждений: абстрактность - штука хорошая, но когда она служит какой-либо цели, а пустое сотрясание воздуха делает абстракцию бесполезной.
"Слова без смысла объясняют любую аномалию", твои же рассуждения не несут ничего креативного, да и они слишком примитивны, чтоб понимать их "истинный смысл".
Далее идут оскорбления, которые я не собираюсь комментрировать. Ты всегда переводишь обсуждение на личности?
Твоя позиция мне ясна: "кто думает и считает не так, как я, вообще не может думать." Ну чтож этот юношеский максимализм со временем проходит.
"Юпитер, ты злишься, значит ты не прав."
Просто смешно. Элементарная логика и здравый смысл говорят о том что после того как объект который представляет handle уничтожен то данный handle использовать нельзя... а ты : скоко ж у handle значений? я смеялся аж до истерики...
Надо было не смеятся, а перечитать и постараться вникнуть в суть вопроса. Разжевываю: человека интересовал алгоритм выделения хендлов, какова теоретическая вероятность перекрытия значений.
"Кстати, а на что резирвируются оставшиеся 2 байта + бит? , вообще хотелось бы по подробней узнать о "путях господнях" по генерации hwnd."
Вполне интересный вопрос. Ты не потрудился так же почитать ответы, где говорилось про меры по предотвращению использования невалидный хендл.
Вместо этого, не зная ответа и даже не понимая вопроса, ты все же влез в обсуждение, нахамил и развил теорию о своей крутости.
Чтож удачи!
Дальнейшее обсуждение считаю бесполезным.
Представляешь, у одного слова может быть несколько значений. Загляни в словарь.
Как часто это было необходимо и чем определялась необходимость?
Минимум - это сколько? Можешь привести перечень?
Честно говоря, об известных проектах не знаю, впрочем не знаю какие методы применялись при разрабюотке большинства известных проектов. Не метод разработки делает проект известным.
Мне достаточно того, что XP (точнее, применение некоторых её практик) помогает в нашей работе.
Что же касается моих достижений, то они не для кого не секрет, но членами я меряться не собираюсь.
По поводу твоих абстрактных рассуждений: абстрактность - штука хорошая, но когда она служит какой-либо цели, а пустое сотрясание воздуха делает абстракцию бесполезной.
"Слова без смысла объясняют любую аномалию", твои же рассуждения не несут ничего креативного, да и они слишком примитивны, чтоб понимать их "истинный смысл".
Далее идут оскорбления, которые я не собираюсь комментрировать. Ты всегда переводишь обсуждение на личности?
Твоя позиция мне ясна: "кто думает и считает не так, как я, вообще не может думать." Ну чтож этот юношеский максимализм со временем проходит.
"Юпитер, ты злишься, значит ты не прав."
Надо было не смеятся, а перечитать и постараться вникнуть в суть вопроса. Разжевываю: человека интересовал алгоритм выделения хендлов, какова теоретическая вероятность перекрытия значений.
"Кстати, а на что резирвируются оставшиеся 2 байта + бит? , вообще хотелось бы по подробней узнать о "путях господнях" по генерации hwnd."
Вполне интересный вопрос. Ты не потрудился так же почитать ответы, где говорилось про меры по предотвращению использования невалидный хендл.
Вместо этого, не зная ответа и даже не понимая вопроса, ты все же влез в обсуждение, нахамил и развил теорию о своей крутости.
Чтож удачи!
Дальнейшее обсуждение считаю бесполезным.
Вот тока не надо задним числом доказывать свою правоту. Если внимательно проследить все твои высказывания последовательно то они не один раз противоречат друг другу. И на личности первый перешел ты. А что касательно хендлов то я всего лишь хотел сказать что человек решает задачу решение которой бессмысленно. И кстати сотрясаю я воздух вполне с определенной целью:). Как сказал один кандидат в президенты другому : будь мужчиной - признай свое поражение.
Удачи. И я тоже считаю дальнейшее обсуждение бесполезным.
Как сказал один кандидат в президенты другому : будь мужчиной - признай свое поражение.
Методы спора у того кандидата в президенты такие же как у тебя. Про 25 раз Hello world это сильно. Вечно эти проектировщики оторваны от народа.
Ну а Green забил еще одного аргументами до истерики.
Методы спора у того кандидата в президенты такие же как у тебя. Про 25 раз Hello world это сильно. Вечно эти проектировщики оторваны от народа.
Ну а Green забил еще одного аргументами до истерики.
Я здесь не видел ни одного здравого аргумента а одни вызубренные наизусть шаблонные фразы из известной литературы. Когда человек понял что он не прав он просто сделал вид что всегда так считал. Желаю прихлебателям вроде тебя всю жизнь посылать месааги по хандлам объектов которых уже не существует. Стыдно господа...
Методы спора у того кандидата в президенты такие же как у тебя. Про 25 раз Hello world это сильно. Вечно эти проектировщики оторваны от народа.
Ну а Green забил еще одного аргументами до истерики.
Не хотелось бы переходить на политику, но все таки... когда голос разума бессилен перед лицом воинствуещей толпы людей с iq ниже среднего - начинают говорить пушки....как было написано у одного серба на плакате - "продаю запчасти от F117 Stels" - га га га
Не хотелось бы переходить на политику, но все таки... когда голос разума бессилен перед лицом воинствуещей толпы людей с iq ниже среднего - начинают говорить пушки....как было написано у одного серба на плакате - "продаю запчасти от F117 Stels" - га га га
Осталось только IQ помериться. :).
Надеюсь, ничем другим мерится Вы не предложите.
Да кстати, насчет "неправильно спроектированной программы", на случай если Вы нечайно пропустили моё сообщение повторюсь:
Это не "программа", а две программы. Одна из которых реализована не мной, и доступа к исходникам у меня нет!
To ALL
Извините, господа, что не по теме, но все же: Поставленный мною вопрос, для меня до сих пор актуален. Может кто из Вас чё добавит?
После отпускаем бряк в первом потоке.
Впрос: высока ли вероятность того, что первый поток обращаясь по запомненому hWnd к тому окну с которым работал, нарвется на новое окно?
Дополнительный байт окна обычно равен 0.
Можно попробовать при первом обращении присвоить ему какое-то значение, через ::SetWindowLong(m_hWnd,GWL_USERDATA, значение). А перед последующими обращениями сперва проверить это значение через ::GetWindowLong(m_hWnd,GWL_USERDATA). Если ноль, значит новое окно.
Осталось только IQ помериться. :).
Надеюсь, ничем другим мерится Вы не предложите.
Да кстати, насчет "неправильно спроектированной программы", на случай если Вы нечайно пропустили моё сообщение повторюсь:
Это не "программа", а две программы. Одна из которых реализована не мной, и доступа к исходникам у меня нет!
To ALL
Извините, господа, что не по теме, но все же: Поставленный мною вопрос, для меня до сих пор актуален. Может кто из Вас чё добавит?
Ты опиши задачу поподробнее. Поскольку мое утверждение о том что после уничтожения окна его хандл утрачивает свое значение пока еще ни кем не опровергнуто, я уверен твою задачу можно решить другим способом , не привлекая сюда вопрос об методах генерации хандлов.
Поскольку мое утверждение о том что после уничтожения окна его хандл утрачивает свое значение пока еще ни кем не опровергнуто, я уверен твою задачу можно решить другим способом , не привлекая сюда вопрос об методах генерации хандлов.
Кстати, мы наблюдаем случай, когда закрытость исходников способствует поиску правильного решения задачи. ;)
Дополнительный байт окна обычно равен 0.
Можно попробовать при первом обращении присвоить ему какое-то значение, через ::SetWindowLong(m_hWnd,GWL_USERDATA, значение). А перед последующими обращениями сперва проверить это значение через ::GetWindowLong(m_hWnd,GWL_USERDATA). Если ноль, значит новое окно.
Ну да же если надо просто оценить вероятность. Даю оценку : при 32 000 возможных значений и 10 000 попытках вероятность примерно равна 1 к 3.
Можно попробовать при первом обращении присвоить ему какое-то значение, через ::SetWindowLong(m_hWnd,GWL_USERDATA, значение). А перед последующими обращениями сперва проверить это значение через ::GetWindowLong(m_hWnd,GWL_USERDATA). Если ноль, значит новое окно.
Думаю, можно неприятно удивиться сколько программ пытаются что-то назначить GWL_USERDATA.
Можно предложить другой менее рискованный вариант, но тоже не фонтан: проверять существование окна (IsWindow), а потом уникальные параметры окна (некоторые): GetWindowInfo, etWindowModuleFileName, GetWindowThreadProcessId.
Но наверное самым правильным будет установка хука на закрытие окна (SetWindowsHookEx), по которому объявлять хендл невалидным.
Думаю, можно неприятно удивиться сколько программ пытаются что-то назначить GWL_USERDATA.
Можно предложить другой менее рискованный вариант, но тоже не фонтан: проверять существование окна (IsWindow), а потом уникальные параметры окна (некоторые): GetWindowInfo, etWindowModuleFileName, GetWindowThreadProcessId.
Но наверное самым правильным будет установка хука на закрытие окна (SetWindowsHookEx), по которому объявлять хендл невалидным.
Вот интересно.... для кого надо объявлять этот хандл невалидным ? первая программа без исходников, а потому ей объявить ничего нельзя, а в другой программе ? если она его сама закрыла то зачем делать hook? если только часть инфы об этой задачи не прошла мимо этого форума то все эти рассуждния по меньшей мере несколько странноваты...
Думаю, можно неприятно удивиться сколько программ пытаются что-то назначить GWL_USERDATA.
Не могу сказать, что был неприятно удивлен, но удалось найти пару активных спец. окон у которых было установлено GWL_USERDATA.
Мне кажется, что 2 последние функции, если идет речь об окнах одного приложения, то чаще всего возвращают одни и те же значения для разных окон.
Но наверное самым правильным будет установка хука на закрытие окна (SetWindowsHookEx), по которому объявлять хендл невалидным.
А не лучше использовать SetProp/GetProp?
Пример для понимания проблемы:
Два потока (или даже процесса) работают с одним и тем же окном. Обращаются к нему (идентифицируют его) через hWnd
В одном из них (пусть в ПЕРВОМ, для определенности) ставим бряк и держим.
В это время во втором потоке дестроим окно. И создаем кучу новых. Огромную кучу: наприер 10 тысяч.
После отпускаем бряк в первом потоке.
Впрос: высока ли вероятность того, что первый поток обращаясь по запомненому hWnd к тому окну с которым работал, нарвется на новое окно?
P/S Так как hwnd это 4 байта, то очевидно, допустимых значений порядка 4 млрд.
Есть ли хоть какие-нибуть правила выдачи очередного window handler?
Есть очень простое предложения. Во второй задаче (которя своя) проверяем допустимость дестроя окна. Если первая задача присутствует, то недестроим.
Пример для понимания проблемы:
Два потока (или даже процесса) работают с одним и тем же окном. Обращаются к нему (идентифицируют его) через hWnd
В одном из них (пусть в ПЕРВОМ, для определенности) ставим бряк и держим.
В это время во втором потоке дестроим окно. И создаем кучу новых. Огромную кучу: наприер 10 тысяч.
После отпускаем бряк в первом потоке.
Впрос: высока ли вероятность того, что первый поток обращаясь по запомненому hWnd к тому окну с которым работал, нарвется на новое окно?
P/S Так как hwnd это 4 байта, то очевидно, допустимых значений порядка 4 млрд.
Есть ли хоть какие-нибуть правила выдачи очередного window handler?
Все таки мне кажется эти размышления бессмыслены без понимания основной цели этой задачи.
А цели мне кажется могут быть например следующими:
1. Заставить рухнуть первое приложение.
2. Получить из первого приложения в свое окно некоторую закрытую информацию....
Мне кажется, что 2 последние функции, если идет речь об окнах одного приложения, то чаще всего возвращают одни и те же значения для разных окон.
Угумс. Поэтому и применять их надо в купе.
А не лучше использовать SetProp/GetProp?
Поясни, я что-то не понял твоей мысли.
Какой именно параметр использовать для SetProp|GetProp?
Не вижу никакой связи или тождества между SetProp и SetWindowsHookEx.
IMHO самый правильный способ это именно SetWindowsHookEx, т.к. мы не завязываемся на какие-либо свойства окна, ничего в нем не меняем, т.е. остаемся нейтральными наблюдателями. Но при этом четко сможем отследить, когда окно уничтожится.
Есть очень простое предложения. Во второй задаче (которя своя) проверяем допустимость дестроя окна. Если первая задача присутствует, то недестроим.
Что-то твой метод совсем не понятен. Я так понял уничтожать вообще ничего не надо, вопрос в другом.
Хотя вопрос скорее теоретический, т.к. не думаю, что хендлы перекроются за время существования процесса. Это же сколько окон надо попереоткрывать. ;)
Какой именно параметр использовать для SetProp|GetProp?
Не вижу никакой связи или тождества между SetProp и SetWindowsHookEx.
При первой работе с конкретным диалоговым окном, можно дать команду
::SetProp(hWnd, "MYPROP", (void *)1000);
Перед последующими обращениями
if((int)::GetProp(hWnd,"MYPROP)==1000)...то окно
или
if((int)::GetProp(hWnd,"MYPROP)==0)...другое окно
Можно и с Hook-ом. Хотя это уже вмешательство в работу ОС.
Если это касается диалоговых окон, то 2.
Если я правильно заметил через Spy, Windows сохраняет hWnd уничтоженного ДИАЛОГОВОГО окна и присваеивает его новому окну.
Поясни, я что-то не понял твоей мысли.
Какой именно параметр использовать для SetProp|GetProp?
Не вижу никакой связи или тождества между SetProp и SetWindowsHookEx.
А никто и не говорил о том что между SetProp/GetProp и SetWindowsHookEx есть какое то тождество... просто по с помощью этих методов окну можно присвоить некоторое уникальное значение по которому его можно однозначно идентифицировать и не вступая при этом в конфликт с другими приложениями... вот только вопрос зачем? ;)
Если я правильно заметил через Spy, Windows сохраняет hWnd уничтоженного ДИАЛОГОВОГО окна и присваеивает его новому окну.
Ну да... иначе бы Windows мог бы работать без перезагрузки только определенное время, пока бы не кончились все возможные значения handle ;)
При первой работе с конкретным диалоговым окном, можно дать команду
::SetProp(hWnd, "MYPROP", (void *)1000);
Есть минус:
Before a window is destroyed (that is, before it returns from processing the WM_NCDESTROY message), an application must remove all entries it has added to the property list. The application must use the RemoveProp function to remove the entries.
Он, к сожалению, сводит все на нет.
Можно и с Hook-ом. Хотя это уже вмешательство в работу ОС.
Ну почему же вмешательство? Вполне легальный способ, а не какой-нибудь хак. :)
Если это касается диалоговых окон, то 2.
Если я правильно заметил через Spy, Windows сохраняет hWnd уничтоженного ДИАЛОГОВОГО окна и присваеивает его новому окну.
Честно говоря, думал, что винды инкрементируют, до победного, а потом уже идут по второму кругу.
IMHO, так было бы правильнее, хотя бы с точки зрения подобного случия.
Интересно, чем руководствовались разработчики?
Интересно, чем руководствовались разработчики?
У них есть исходники...
Before a window is destroyed (that is, before it returns from processing the WM_NCDESTROY message), an application must remove all entries it has added to the property list. The application must use the RemoveProp function to remove the entries.
Есть минус:
Он, к сожалению, сводит все на нет.
Проблема легко и непринужденно решается через сабклассинг...
У них есть исходники...
Исходники есть и у меня, суть дела это не меняет. :)
Почему бы не выделять hwnd в инкрементальном порядке, для уменьшения вероятностей такого перекрытия значений.
P.S. Я имел в виду разработчиков Windows.
Интересно, чем руководствовались разработчики?
По всей видимости соображениями экономии значений handle.. например с целью удержать их в определенном валидном диапазоне... тоже ресурс все таки, а ресурсы как известно надо экономить...
Он, к сожалению, сводит все на нет.
На нет наверно не сводит. Я проверил на двух приложениях. BSOD не получил(пока еще :))
Хотя, наверно SetWindowsHookEx, как раз, то что надо.
Интересно, чем руководствовались разработчики?
Наверно думали: "а может никто не заметит?". Есть такой анекдот как раз о разработчиках(типа как они убирают баги). Прокололось колесо и программист предложил в качестве выхода из положения: "едем дальше, может никто незаметит".