Когда окно запускается ему(то есть hwnd) присваиваеться некое число. Вопрос: что происходит с этим после того как окно прекращает свою работу? Кокретнее это число может быть присвоенным при открытии нового окна новому окну, или оно так и останеться за тем окном, которое я закрыл?
В VB не может, а вто в VB.NET - изменится за здорово живешь)))
Там, например, можно изменить стиль листбокса. Это на VB сделать
нельзя, более того, стиль окна задается при создании окна и изменить
его потом нельзя - это зашито еще на уровне виндов!!!
Но VB.NET это делает - он просто создает новое окно с точно такими же
свойствами, но с другим стилем. И хендл у него уже другой. Точно
нельзя сказать, когда этот хендл может поменяться((
--------------
Чисто теоритически - после разрушения окна его хендл может зянять
другое, но такие случаи, по-моему, очень редки, тк, по-моему, при
создании окна ему дается произвольно сгенерированный хендл, но я а
этом не уверен.
Artyom_kr, боюсь, ты систему не понял. Дело тут не в том, что за среда- VB или VB.NET- один пес (извиняюсь) хэндлы присваивает окнам (и процессам) винды, а не VB (как, в общем, и не Delphi и не C, если уж на то пошло). VB (или VB.NET) лишь запрашивает handle "своего" окна и "сует" его в .hwnd, откуда ты его и берешь. Теперь о изменении стиля. Виндам по барабану, что за фичи у VB, поэтому при изменении стиля "старое" окно уничтожается (ну, типа DestroyWindow(hwnd as Long) as Long), его хэндл, естессно, теряется, затем создается НОВОЕ окно, кот. присваивается НОВЫЙ хэндл. Кстати, насчет хэндлов вообще: Мелкософт говорит, что они, родимые, есть у всего, т.е., даже у элементов управления, как они их называют. Т.о., если можно узнать хэндл "чужого" окна (его, кстати, можно получить по тому, что у этого окна в Caption лежит) и, например, закрыть его несмотря на все его вопли (я однажды себе так Word испоганил: окно закрыл, а процесс в памяти остался (ну, первые опыты - первая кровь). Однако, меня занесло, черта красноречивого! Так вот, если можно узнать хэндл "чужого" окна и потом мочить его в сортире (извиняюсь), почему нельзя то же сделать, например, с любой кнопкой в "чужом" же окне, а? Вот только эти собаки из "Билли и Ко" не говорят, как эти хэндлы выковыривать! А вообще, я так посмотрел, во что превратился "общий вопрос по hwnd...", и подумал, что пора уже и отдельный форум по этоому вопросу открывать
Не, Дима, я все понимаю прекрасно. На уровне виндов все реализовано
одинаково и для Delphi, и для Си, и для того же VB. То есть, есть
окно, оно представляет собой объект ну и и.д. - см. МСДН.
Но ставить эти языки на одну полку с VB.NET - это неправильно! Во всех
НЕТовских языках все это инкапсулировано на уровне .NET Framework. В
.NET Framework свое представление окна - как класса. И разработчика
должно интерисовать только тот факт, что оно работает, а не то, как
оно работает.
VB хендл окна _не мог_ изменить. Точно также, как и Delphi, C. Это
привело бы к очень большим проблемам при использовании АПИ.
.NET Framework представляет просто обертку для АПИ-функций - это его
дело, что он делает, когда он разрушет и создает окна. Он не обязан
отчитываться о том, как и когда он это делает - АПИ мы уже
использовать не должны. Практически все АПИ имеют аналоги в .NET
Framework. А .handle там оставили, наверное, только для извращенцев,
которые не расстанутся с АПИ любимой, ну и на некоторые другие случаи,
например, пришивка Регоина к окну.
В общем, я лишь хотел сказать, что .NET Framework - это как бы новая
реализация тех самых окон. Возможно, в новых версиях виндов АПИ
отпадет и работать все низкоуровневые операции будут прошити на уровне
.NET Framework.
========================
Вот, написано много, а, наверное, не по делу.
Теперь про твой вопрос.
Прежде всего, ты можешь получить хендл _любого_ окна, контрола. И
делать с ним практически все, что захочешь. Проще всего для этого
сначало поюзать Spy++, а потом - соответствующие АПИшки. Типа
FindWindow, GetWindow и им подобные.
Artyom_kr, ты напомнил мне одного чудака, который утверждал, что новые модели процессоров будут исполнять код написанный на С. Наверно, NET придумали для извращенцев, которым лень что-либо понимать. Это всего лишь лишний тормоз для системы в целом и никогда он ничего не заменит.
Gets or sets the window region associated with the control.
Public Property Region As Region
Property Value
The window Region associated with the control.
Remarks
The window region is a collection of pixels within the window where the operating system permits drawing. The operating system does not display any portion of a window that lies outside of the window region. The coordinates of a control's region are relative to the upper-left corner of the control, not the client area of the control.
Note The collection of pixels contained with the region can be noncontiguous.
Requirements
Platforms: Windows 98, Windows NT 4.0, Windows Millennium Edition, Windows 2000, Windows XP Home Edition, Windows XP Professional, Windows .NET Server family
.NET Framework Security:
UIPermission for all windows to set this property value. Associated enumeration: UIPermissionWindow.AllWindows
See Also
Control Class | Control Members | System.Windows.Forms Namespace | ClientRectangle | Bounds | Control Members (Visual J# Syntax) | Managed Extensions for C++ Programming
Syntax based on .NET Framework version 1.1.4322.
November 15, 2002.
Короче, создаёшь System.Drawing.Region, а потом присваивашь свойству
Region формы.