Re: AHK: Замена "Window Spy"
Не понял, что конкретно не совпадает.
Объясни пошагово, что надо сделать.
Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.
Страницы Назад 1 … 10 11 12 13 14 … 19 Далее
Чтобы отправить ответ, вы должны войти или зарегистрироваться
Не понял, что конкретно не совпадает.
Объясни пошагово, что надо сделать.
При наведении на Scintilla имеем стили из 0х4003
В моём коде 0
Если навести на Edit в блокноте, то стили будут совпадать.
Там всего то надо.
DllCall("GetClassLong", "Ptr", hWnd, "int", -26)
А тут https://docs.microsoft.com/en-us/window … indowlongw этого почему то нет.
Вроде порядок.
SetFormat, IntegerFast, H
ClassStyles := {"CS_BYTEALIGNCLIENT":"0x1000", "CS_BYTEALIGNWINDOW":"0x2000", "CS_CLASSDC":"0x0040"
, "CS_DBLCLKS":"0x0008", "CS_DROPSHADOW":"0x00020000", "CS_GLOBALCLASS":"0x4000", "CS_HREDRAW":"0x0002"
, "CS_NOCLOSE":"0x0200", "CS_OWNDC":"0x0020", "CS_PARENTDC":"0x0080", "CS_SAVEBITS":"0x0800", "CS_VREDRAW":"0x0001"}
1::
Ret =
MouseGetPos, , , hWin, hWnd, 2
If !hWnd
hWnd := hWin
StyleBits := DllCall("GetClassLong", "Ptr", hWnd, "int", GCL_STYLE := -26)
For K, V In ClassStyles
Ret .= StyleBits & V ? K "`n" : ""
ToolTip % "Style bits: " StyleBits "`n`n" Ret
Return
А тут https://docs.microsoft.com/en-us/window … indowlongw этого почему то нет.
Зато там есть:
Note If you are retrieving a pointer or a handle, this function has been superseded by the GetWindowLongPtr function. (Pointers and handles are 32 bits on 32-bit Windows and 64 bits on 64-bit Windows.) To write code that is compatible with both 32-bit and 64-bit versions of Windows, use GetWindowLongPtr.
Так это же вроде не относится к GCL_STYLE?
Не вдавался в подробности к чему это относится, но используя GetWindowLongPtr стили класса в ноутпад++ показываются.
Не вдавался в подробности к чему это относится
If you are retrieving a pointer or a handle,
Разве не про это? И у меня в ОС64 на анк32 работает.
но используя GetWindowLongPtr
А как ты используешь?
Так же как и ты в 1100 посте.
Ты в нём только заменяешь GetWindowLong на GetWindowLongPtr, и у тебя корректно работает?
DllCall("GetWindowLong" (A_PtrSize=8 ? "Ptr" : ""), Ptr, hWin, "UInt", GWL_HINSTANCE := -6, "ptr")
У меня 0 на Scintilla.
Я перепроверил - у меня тоже 0 - ERROR_CLASS_DOES_NOT_EXIST.
Просто не посмотрел, что в 1100 коде ошибка - VarSetCapacity надо при каждом вызове обнулять.
Как я понял классы делятся на глобальные и локальные.
И локальные классы из чужого процесса через GetClassInfo получить нельзя.
Как я понял классы делятся на глобальные и локальные.
И локальные классы из чужого процесса через GetClassInfo получить нельзя.
Ещё вроде системные классы есть. А судя по тому что надо передавать указатель на приложение, то не сказано что нельзя, а на деле одно и тоже что ноль передавать.
Зато там есть:
Note If you are retrieving a pointer or a handle, this function has been superseded by the GetWindowLongPtr function. (Pointers and handles are 32 bits on 32-bit Windows and 64 bits on 64-bit Windows.) To write code that is compatible with both 32-bit and 64-bit versions of Windows, use GetWindowLongPtr.
Ты наверное перепутал GetWindowLong с GetClassLong который я использую в 1105.
Ты наверное перепутал GetWindowLong с GetClassLong который я использую в 1105.
Не, на ахк 64 бит ноль покажет:
f11::
MouseGetPos, , , hWin, hWnd, 2
If !hWnd
hWnd := hWin
WinGetClass, Class, ahk_id %hWnd%
msgbox % hInstance := DllCall("GetWindowLong", Ptr, hWin, "UInt", GWL_HINSTANCE := -6)
Ты не понял, я про то что GetWindowLong не нужен в этой задаче. Ты написал про битность после 1105, я подумал что ты имеешь ввиду что в 1105 не рабочий код, а в 1100 и так изначально не работало.
У меня стоял ahk 64 бит, я запустил код из 1100 - получил нули, запустил его на 32 бит и из-за того, что varsetcapacity не обнулялся у меня в ноутпад++ вывелся класс.
Из чего я сделал вывод, что не работает на x64.
А GetClassLong можно оставлять как есть, так как хендл с помощью него мы не получаем.
На счёт стилей кнопок, не пойму BS_TEXT это когда нет ни одного из указанных стилей, судя по данным WinId это не так.
STYLE_(BS_TEXT), 0, -1, (BS_ICON|BS_BITMAP|BS_AUTOCHECKBOX|BS_AUTORADIOBUTTON|BS_CHECKBOX|BS_RADIOBUTTON),//0x00000000
Я бы полагался на Microsoft Spy++.
А она не показывает.
Да, он по точнее, но например не показывает TCS_BOTTOM у Таба, ещё другие нестыковки замечал, уже не вспомню.
Вообщем ощущение, что нет какой то однозначности со стилями, надо делать как то по своему.
он по точнее, но например не показывает TCS_BOTTOM у Таба
Сложно что-то сказать без примера.
Microsoft Spy++, версия 15.00.27520 (выпуск x86)
Не показывает TCS_BOTTOM и TCS_EX_REGISTERDROP.
Gui, Add, Tab3, h64 +E0x00000002 +0x0002, General|View|Appearance|Settings
Gui, Show
Да, походу у них баг.
Надо проверять TCS_VERTICAL, если есть, то - TCS_RIGHT, если нет, то TCS_BOTTOM.
На счет TCS_EX_REGISTERDROP, ты этот стиль не так назначаешь:
The tab control now supports extended styles. These styles are manipulated using the TCM_GETEXTENDEDSTYLE and TCM_SETEXTENDEDSTYLE messages and should not be confused with extended window styles that are passed to CreateWindowEx.
Я так понял, что просто нужен TCS_FLATBUTTONS.
TCS_FLATBUTTONS := 0x0008
TCS_EX_FLATSEPARATORS := 0x00000001
Gui, Add, Tab3, +%TCS_FLATBUTTONS% +E%TCS_EX_FLATSEPARATORS%, 1|2|3|4
Gui, Show
Return
Но если не указать TCS_EX_FLATSEPARATORS, то Microsoft Spy всё равно пишет что он есть, хотя биты нулевые, визуально стиля тоже нет.
Получается надо проверять TCS_FLATBUTTONS и TCS_EX_FLATSEPARATORS.
TCS_EX_FLATSEPARATORS ставится автоматом при стиле TCS_BUTTONS + TCS_FLATBUTTONS, так как TCS_FLATBUTTONS не может существовать без TCS_BUTTONS.
TCS_EX_FLATSEPARATORS ставится автоматом при стиле TCS_FLATBUTTONS, но ни тот ни другой не применяются без TCS_BUTTONS.
Я про то что и с TCS_EX_FLATSEPARATORS в Microsoft Spy баг.
Почему баг?
Если ты ставишь только стиль TCS_FLATBUTTONS, то автоматом добавляется TCS_EX_FLATSEPARATORS.
Что и показывает Microsoft Spy.
Так его визуально нет. И правильно ли то что в ExStyle - нули.
Когда добавляешь TCS_BUTTONS и TCS_EX_FLATSEPARATORS, тогда уже появляется рамка вокруг таба. Или тогда что это за рамка, там ведь написано про "разделители между элементами вкладки".
Я добавил Tab, Edit, Button, Static.
И на таком окне правильно что WS_SYSMENU остаётся в неопределённых стилях, битах.
Стили которые определены я просто минусую из изначальных байтов чтобы проверить остаток, или есть более подходящая битовая операция.
Gui, -Caption
Gui, Show, w333 h333
Return
Так его визуально нет. И правильно ли то что в ExStyle - нули.
Почему нули?
TCS_FLATBUTTONS := 0x0008
Gui, Add, Tab3, +%TCS_FLATBUTTONS% Hwndhwnd, 1|2|3|4
Gui, Show
SendMessage, TCM_GETEXTENDEDSTYLE := 0x1335 , 0, 0,, ahk_id %hwnd%
msgbox % errorlevel
Return
Я добавил Tab, Edit, Button, Static.
И на таком окне правильно что WS_SYSMENU остаётся в неопределённых стилях, битах.
Не понимаю вопроса.
Стили которые определены я просто минусую из изначальных байтов чтобы проверить остаток, или есть более подходящая битовая операция.
Не знаю, я тоже минусовал.
Не понимаю вопроса.
0x00080000 остаётся красным шрифтом.
0x00080000 это WS_SYSMENU, он присутствует в битах, но не определён в этом окне из за условий.
В остаток нужно выводить что?
GETEXTENDEDSTYLE
Это так у всех контролов с расширенными стилями, или по разному, и что тогда получает ControlGet, , ExStyle.
0x00080000 это WS_SYSMENU, он присутствует в битах, но не определён в этом окне из за условий.
У меня не остается, а определяется, как WS_SYSMENU.
Из чего можно сделать вывод, что -Caption не убирает этот стиль.
Это так у всех контролов с расширенными стилями, или по разному, и что тогда получает ControlGet, , ExStyle.
ExStyle получает дополнительный стиль дочернего окна, типа ws_ex.
Для дополнительных стилей присущих именно этой группе контролов нужно отправлять сообщения.
Я уже об этом писал:
http://forum.script-coding.com/viewtopi … 79#p130879
В данном типе контрола написано:
The tab control now supports extended styles. These styles are manipulated using the TCM_GETEXTENDEDSTYLE and TCM_SETEXTENDEDSTYLE messages and should not be confused with extended window styles that are passed to CreateWindowEx.
Что означает, что управлять этими стилями можно только отправляя сообщения.
Поэтому при создании этого контрола на его стили ты повлиять не можешь.
У меня не остается, а определяется, как WS_SYSMENU.
Где, в Microsoft Spy?
Да. С кодом из 1,130 поста.
Microsoft Spy 14 версия.
А как в окне без заголовка может быть системное меню.
А почему оно быть не может?
При удалении заголовка удаляются же только биты заголовка.
А почему оно быть не может?
WS_SYSMENU
The window has a window menu on its title bar. The WS_CAPTION style must also be specified.
При удалении заголовка удаляются же только биты заголовка.
Я наблюдаю также удаление самого заголовка.
Цель какая - валидейтить окна?
Gui, +hwndhwnd
Gui, Show, w333 h333
WinGet, a, Style, ahk_id %hwnd%
Gui, -Caption
WinGet, a1, Style, ahk_id %hwnd%
SetFormat, IntegerFast, hex
msgbox % a-a1
WS_SYSMENU
The window has a window menu on its title bar. The WS_CAPTION style must also be specified.
Здесь нигде не сказано, что если WS_CAPTION не будет указан, то стиль WS_SYSMENU не будет добавлен.
Не понял, к чему пример, и что значит - валидейтить окна.
Пример к тому, что стиль WS_SYSMENU никуда не девается и остается у окна.
Валидейтить - проверять правильность создания окон.
А как оно может быть создано неправильно.
WS_SYSMENU никуда не девается
Так там же написано - Стиль WS_CAPTION также должен быть указан.
Ну типа проверять и предупреждать о подобных возможных несоответствиях - WS_SYSMENU есть, а WS_CAPTION нету.
Так там же написано - Стиль WS_CAPTION также должен быть указан.
Ну это логично, так как меню распологается на заголовке.
Но там же не написано, что если заголовка не будет, то стиль "меню" добавляться не будет.
А зачем его выводить, если его нет.
Если мы его не видим, то это не значит, что его нет.
Или ты считаешь, что биты 0x00080000 при удалении заголовка должны трансформироваться в неопределенный стиль?
А при повторном его добавлении заново превращаться в WS_SYSMENU?
Или ты считаешь, что биты 0x00080000 при удалении заголовка должны трансформироваться в неопределенный стиль?
А при повторном его добавлении заново превращаться в WS_SYSMENU?
Да, более того кажется правильным чтобы окно само удаляло 0x00080000 при удалении WS_CAPTION. Но, я тебя понял, делаем как везде.
STYLE_(LVS_ICON), LVS_TYPEMASK, -1, LVS_REPORT|LVS_SMALLICON|LVS_LIST, //0x0000
STYLE_(LVS_REPORT), LVS_TYPEMASK, -1, 0, //0x0001
STYLE_(LVS_SMALLICON), LVS_TYPEMASK, -1, 0, //0x0002
STYLE_(LVS_LIST), LVS_TYPEMASK, -1, 0, //0x0003
Не соображу, LVS_TYPEMASK = 0x0003 это сумма LVS_REPORT и LVS_SMALLICON, в первом параметре встречал только 0xf для эксклюзивных стилей, а в 3 указывались те которых не должно быть, не понимаю тут логики. И LVS_TYPEMASK это не стиль, а флаг определяющий другие стили?
LVS_TYPEMASK - это битовая маска с помощью которой определяешь нужные биты.
style := 6
msgbox % style & 0x3
STYLE_(LVS_ALIGNTOP), 0, -1, 0, //0x0000
А чему равен LVS_ALIGNTOP, он же должен зависеть от LVS_ALIGNMASK.
Так написано же нулю.
Кто равен нулю, нулевой бит?
Если стили например - 0x0140, то LVS_ALIGNTOP.
LVS_ALIGNMASK := 0x0C00
SetFormat, IntegerFast, H
Gui, Add, ListView, hWndhListView Grid, Index|Name
Gui, Show
WinGet, WinStyle, Style, ahk_id %hListView%
MsgBox % WinStyle & LVS_ALIGNMASK "`n" WinStyle
Здесь по твоему должно быть LVS_ALIGNTOP?
Здесь нет, так как LVS_ALIGNTOP может быть только у icon и small icon.
Но если заменить это:
Gui, Add, ListView, hWndhListView Grid, Index|Name
на это:
Gui, Add, ListView, hWndhListView Grid +0x800, Index|Name
то тогда я считаю указывать надо LVS_ALIGNLEFT, невзирая на то, что не icon и не small icon, так как биты присутствуют.
LVS_ALIGNTOP может быть только у icon и small icon
А где такое прочитать?
Как всегда на мсдн:
https://docs.microsoft.com/en-us/window … dow-styles
Как всегда на мсдн
Читал конечно, только в переводе и невнимательно, как всегда.
Добавил ListView.
Как-то, имхо, запутанно получилось.
Мне нравится как у WinSpy++ это реализовано - название стиля и его значение.
http://www.manhunter.ru/download/24724/ … %201.7.zip
При таком стиле решил "0x800" - делать неопределенным?
Gui, Add, ListView, hWndhListView Grid +0x800, Index|Name
Как-то, имхо, запутанно получилось.
Мне нравится как у WinSpy++ это реализовано - название стиля и его значение.
Значение не всегда о чём то говорит, как получать стиль если он 0x0000. Так хоть что то понятно что от чего зависит.
По ссылке ошибка.
При таком стиле решил "0x800" - делать неопределенным?
Так должно быть LVS_SMALLICON или LVS_ICON. Иначе получается для LVS_ALIGNTOP проверяем LVS_SMALLICON или LVS_ICON, ведь так как он 0x0000 то будет тогда везде вылазить, а для LVS_ALIGNLEFT не надо, хотя по факту он не включен.
Так хоть что то понятно что от чего зависит
А разве нужно для анализатора окон давать информацию для понимания?
Кому надо может в исходник залезть и посмотреть.
По ссылке ошибка.
Зайди на сайт и загрузи ее еще раз - там куки должны быть прописаны.
Так должно быть LVS_SMALLICON или LVS_ICON. Иначе получается для LVS_ALIGNTOP проверяем LVS_SMALLICON или LVS_ICON, ведь так как он 0x0000 то будет тогда везде вылазить, а для LVS_ALIGNLEFT не надо, хотя по факту он не включен.
Я бы по такому алгоритму и делал (winId так же делает).
Не включен, так не включен - главное, что он известен.
1) У тебя ошибка - не может быть окно и WS_OVERLAPPED и WS_POPUP.
2) Зачем разделять стили контролов на 4 окна - неудобно же.
Опять же за пример можно взять WinSpy++ или Microsoft Spy.
3) Хорошо было бы также вставить во вкладку контрола стили родительского окна в раздел Window.
4) Ну и не мешало бы потестировать всё это на различных окнах на возможные баги, сверяясь с winspy++, winId, Microsoft Spy.
Зайди на сайт и загрузи ее еще раз - там куки должны быть прописаны.
Всё также не получается, хотя я и ничего не понял про куки.
А разве нужно для анализатора окон давать информацию для понимания?
Это как раз главное для чего я добавляю стили, зачем мне из за каждого стиля ходить в справку, так я хотя бы могу предположить простой стиль или составной.
Опять же за пример можно взять WinSpy++ или Microsoft Spy.
WinSpy++ у меня нет, Microsoft Spy ни в коем случае, нужны хотя бы значения стилей для использования в АНК.
Зачем разделять стили контролов на 4 окна - неудобно же.
Наоборот удобно, всё по категориям, не надо всматриваться в префиксы стилей, в стилях контрола биты отделены от общих, в расширенных указаны биты которых нет в ControlGet. А чем тебе неудобно.
У тебя ошибка - не может быть окно и WS_OVERLAPPED и WS_POPUP.
В справке вижу только - WS_OVERLAPPED = WS_BORDER && WS_CAPTION, а WS_POPUP = 0x80000000 && !WS_CHILD.
Хорошо было бы также вставить во вкладку контрола стили родительского окна в раздел Window.
А вкладка Window на что, Control и так перегружен данными.
Не включен, так не включен - главное, что он известен.
Надо подумать, а то получается одни не пишутся по тому что их нет по условию, хотя по битам есть, а тут есть биты, но условие не подходит.
Ну и не мешало бы потестировать всё это на различных окнах на возможные баги, сверяясь с winspy++, winId, Microsoft Spy
Не мешало бы конечно, но на это нет времени, на скорую руку смотрю в winId и Microsoft Spy.
Всё также не получается, хотя я и ничего не понял про куки.
При открытии ссылки там же написано:
Вы пытаетесь скачать файл по прямой ссылке, размещенной на стороннем сайте.
Доступ к файлам разрешен только с этого сайта. Недобросовестные люди ("личеры") могут публиковать прямые ссылки на закачку на других сайтах, не указывая ссылок на
основной сайт и тексты статей, а это неуважение к труду автора. Пожалуйста, вернитесь к статье Программы для работы с окнами приложений и повторите загрузку.
Это как раз главное для чего я добавляю стили, зачем мне из за каждого стиля ходить в справку, так я хотя бы могу предположить простой стиль или составной.
Ну раз для только для себя, тогда другое дело, потому как меня, например, данный код поставил бы в ступор (подумал бы что баг):
LVS_ICON := LVS_TYPEMASK = LVS_ICON && !(LVS_REPORT | LVS_SMALLICON | LVS_LIST)
LVS_ALIGNLEFT := LVS_ALIGNMASK = 0x0800 && (LVS_SMALLICON || LVS_ICON)
WinSpy++ у меня нет, Microsoft Spy ни в коем случае, нужны хотя бы значения стилей для использования в АНК.
Скачай таки winspy++. Но за пример я имел в виду разбивку по окнам.
Наоборот удобно, всё по категориям, не надо всматриваться в префиксы стилей, в стилях контрола биты отделены от общих, в расширенных указаны биты которых нет в ControlGet. А чем тебе неудобно.
У дочернего окна сумма стилей равна стили дочернего окна+конкретные стили контрола, а у тебя сейчас этой суммы нет и стили идут вразнобой.
Разделить дополнительные стили еще логично, так как они по разному присваиваются.
В справке вижу только - WS_OVERLAPPED = WS_BORDER && WS_CAPTION, а WS_POPUP = 0x80000000 && !WS_CHILD.
http://www.frolov-lib.ru/books/bsp/v11/ch3_2.htm
А вкладка Window на что, Control и так перегружен данными.
Можно всегда спрятать стили и при необходимости открыть.
одни не пишутся по тому что их нет по условию
Не пишутся только нулевые, либо те, которые при данном условии переназначаются на другие.
При открытии ссылки там же написано:
Скачал.
Ну раз для только для себя, тогда другое дело, потому как меня, например, данный код поставил бы в ступор (подумал бы что баг):
Согласен что непривычный вид, но LVS_ALIGNLEFT = 0x0800 и LVS_ICON = 0x0000 вообще ни о чём не говорят, и заставят применить сначала Style & LVS_ALIGNLEFT в своём коде, и если заметишь что это не работает, то прочитать кроме как про сам стиль, ещё и примечания. А так оно как бы сразу указывает направление поиска.
http://www.frolov-lib.ru/books/bsp/v11/ch3_2.htm
Получается однозначно полагаться на справку не следует. Я поправил WS_OVERLAPPED.
Можно всегда спрятать стили и при необходимости открыть.
Всё таки не понимаю зачем там нужны стили окна, если они уже логично располагаются в другой вкладке.
Не пишутся только нулевые, либо те, которые при данном условии переназначаются на другие.
На досуге надо будет ещё раз всё перелопатить.
Добавил "Common control styles", так понял они определяются из остатка от стилей контрола.
У дочернего окна сумма стилей равна стили дочернего окна+конкретные стили контрола, а у тебя сейчас этой суммы нет и стили идут вразнобой.
Скачай таки winspy++. Но за пример я имел в виду разбивку по окнам.
Это не понял.
У дочернего окна сумма стилей равна стили дочернего окна+конкретные стили контрола, а у тебя сейчас этой суммы нет и стили идут вразнобой.
Рядом с кнопкой show styles разве не то.
Например в ToolbarWindow32 стили контрола могут отличатся, так как получаются из SendMessage, эти стили другие утилиты не пишут. На рабочем столе SysListView32 WinSpy++ и WinID расширенные стили выводят как нулевые, и только WinID выводит остаток, но получается что неизвестно чего, плюс они не определяют большинство из них, WinSpy++ определяет - 5 стилей, WinID - 7. Microsoft Spy++ определяет все 11, но тоже выводит биты расширенных стилей как нули, что же тут правильного. У меня же всегда видно из каких бит получены стили.
Согласен что непривычный вид, но LVS_ALIGNLEFT = 0x0800 и LVS_ICON = 0x0000 вообще ни о чём не говорят
Можно сделать так:
LVS_ICON := 0x0000 (LVS_TYPEMASK = LVS_ICON && !(LVS_REPORT | LVS_SMALLICON | LVS_LIST))
LVS_ALIGNLEFT := 0x0800 ([LVS_ALIGNMASK = 0x0800 && (LVS_SMALLICON || LVS_ICON))
Получается однозначно полагаться на справку не следует
Стоит полагаться на справку+на другие утилиты+на логику, чтобы исправить баги и неудобства в других утилитах.
Всё таки не понимаю зачем там нужны стили окна, если они уже логично располагаются в другой вкладке.
Можно и не вставлять, а можно вставить и посмотреть как удобней будет.
У дочернего окна сумма стилей равна стили дочернего окна+конкретные стили контрола, а у тебя сейчас этой суммы нет и стили идут вразнобой.
Берем контрол блокнота:
f11::
ControlGet, Style, Style ,, Edit1, A
msgbox % clipboard := Style
Получаем 0x50300104.
У тебя же:
Styles - Edit: 0x0104 )
ES_MULTILINE := 0x0004
ES_NOHIDESEL := 0x0100
ES_LEFT := !(ES_CENTER | ES_RIGHT)
( Styles )
WS_HSCROLL := 0x00100000
WS_VISIBLE := 0x10000000
WS_VSCROLL := 0x00200000
WS_CHILD := WS_CHILDWINDOW := 0x40000000
Cуммы стилей контролов нету, что вносит путанницу.
Почему нельзя сделать, например как в WinSpy++ вначале показать стили WS_, потом ES_ в одной вкладке с общей суммой.
Типа:
Styles - 0x50300104 )
WS_HSCROLL := 0x00100000
WS_VISIBLE := 0x10000000
WS_VSCROLL := 0x00200000
WS_CHILD := WS_CHILDWINDOW := 0x40000000[
ES_MULTILINE := 0x0004
ES_NOHIDESEL := 0x0100
ES_LEFT := !(ES_CENTER | ES_RIGHT)
На счет дополнительных стилей разделение логично, так как они определяются по-разному.
И еще надо как-то логично их сортировать, в алфавитном порядке либо по значениям стилей.
В ExStyles тоже стоило бы указывать значения.
Вместо:
ExStyles )
WS_EX_LEFT := !(WS_EX_RIGHT)
WS_EX_RIGHTSCROLLBAR := !(WS_EX_LEFTSCROLLBAR)
WS_EX_LTRREADING := !(WS_EX_RTLREADING)
так:
ExStyles 0x0000)
WS_EX_LEFT := 0x0000 !(WS_EX_RIGHT)
WS_EX_RIGHTSCROLLBAR := 0x0000 !(WS_EX_LEFTSCROLLBAR)
WS_EX_LTRREADING := 0x0000 !(WS_EX_RTLREADING)
Баг с ToolbarWindow32.
ExStyles - ToolbarWindow32: 0x2A0 )
TBSTYLE_EX_DOUBLEBUFFER := 0x80
0x2A0
Можно и не вставлять, а можно вставить и посмотреть как удобней будет.
Всё таки я не понимаю зачем это вообще может быть нужно.
Можно сделать так:
Согласен.
И еще надо как-то логично их сортировать, в алфавитном порядке либо по значениям стилей.
Гемморойно будет в той логике которую я уже наваял, подумаю.
Cуммы стилей контролов нету, что вносит путанницу.
Я за отделение оконных стилей от специфичных. В Styles и ExStyles биты добавлю.
Сейчас уже кое как работает, время появится - переделаю.
Баг с ToolbarWindow32.
Поправил.
Странно что в TB_GETEXTENDEDSTYLE 2 байта, хотя в его стилях максимум 1.
Я ещё хотел добавить
; Button styles ========================================================================================================
Global BTNS_BUTTON := 0x00 ; TBSTYLE_BUTTON
Global BTNS_SEP := 0x01 ; TBSTYLE_SEP
Global BTNS_CHECK := 0x02 ; TBSTYLE_CHECK
Global BTNS_GROUP := 0x04 ; TBSTYLE_GROUP
Global BTNS_CHECKGROUP := 0x06 ; TBSTYLE_CHECKGROUP // (TBSTYLE_GROUP | TBSTYLE_CHECK)
Global BTNS_DROPDOWN := 0x08 ; TBSTYLE_DROPDOWN
Global BTNS_AUTOSIZE := 0x10 ; TBSTYLE_AUTOSIZE // automatically calculate the cx of the button
Global BTNS_NOPREFIX := 0x20 ; TBSTYLE_NOPREFIX // this button should not have accel prefix
Global BTNS_SHOWTEXT := 0x40 ; // ignored unless TBSTYLE_EX_MIXEDBUTTONS is set
Global BTNS_WHOLEDROPDOWN := 0x80 ; // draw drop-down arrow, but without split arrow section
Но не одолел их получение, наработки в комментарии GetStyle_ToolbarWindow.
/*
oBTNS := {"BTNS_BUTTON":"0x00","BTNS_SEP":"0x01","BTNS_CHECK":"0x02","BTNS_GROUP":"0x04","BTNS_CHECKGROUP":"0x06","BTNS_DROPDOWN":"0x08"
,"BTNS_AUTOSIZE":"0x10","BTNS_NOPREFIX":"0x20","BTNS_SHOWTEXT":"0x40","BTNS_WHOLEDROPDOWN":"0x80"}
VarSetCapacity(TBBUTTON, A_PtrSize == 8 ? 32 : 20, 0)
iBitmap := NumGet(TBBUTTON, 0, "Int")
idCommand := NumGet(TBBUTTON, 4, "Int")
fsState := NumGet(TBBUTTON, 8, "UChar")
fsStyle := NumGet(TBBUTTON, 9, "UChar")
bReserved := NumGet(TBBUTTON, 10, "UChar")
;bReserved := NumGet(TBBUTTON, 10, "UChar")
dwData := NumGet(TBBUTTON, A_PtrSize == 8 ? 16 : 12, "UPtr")
iString := NumGet(TBBUTTON, A_PtrSize == 8 ? 24 : 16, "Ptr")
*/
А через TB_GETBUTTON пробовал?
Неудобно то, что комментарии к стилю копируются вместе со значением стиля.
Вот в такой конструкции отдельно скопировать 0x00C00000 получится только если обвести это значение.
WS_CAPTION := 0x00C00000 = (WS_BORDER | WS_DLGFRAME)
А через TB_GETBUTTON пробовал?
C OpenProcess?
отдельно скопировать 0x00C00000 получится только если
Да, мне это тоже не нравится.
C OpenProcess?
Ну, да.
teadrinker, помню, выкладывал нечто подобное.
Да это есть, давно использую его DeleteDummyIcons.
Я поверхностно смотрел, думал это общие стили для всех кнопок, или это стили для каждой кнопки отдельно, не знаю стоит ли тогда с ними вообще заморачиваться.
Судя по информации об этом сообщении, то по каждой кнопке отдельно.
Ни к чему оно значит.
Поменял местами "show styles" и "hide styles".
Для примера, как буду потом выводить примечания, сделал для WS_EX_LEFT, WS_EX_RIGHTSCROLLBAR, WS_EX_LTRREADING.
Я за отделение оконных стилей от специфичных
Ну мы их и отделяем, то что WS - оконные.
А сейчас чехарда из стилей получается - непонятно, что к чему относится.
Кстати на ахк уже есть подобный функционал, правда не без ошибок.
Вот там точь-в-точь как я предлагал сделать:
https://sourceforge.net/projects/winspy … t/download
Сейчас по двойному клику по названию заголовка он отображается сверху.
Неудобно, что по двойному клику нету привязки заголовка к верху окна - в зависимости от наполнености заголовок прыгает.
Согласен, тоже сразу не понравилось, но простого решения не нашёл, подумаю ещё раз.
На стили пока времени нет, и до конца не решил как нагляднее. Оконные в 2 старших байтах, специфичные в младших, почему бы их не разделить, а "так у всех" так себе аргумент. И у тулбара обычные стили получаются из сообщения, соответственно в его случае младшие байты вообще отбрасываются.
а "так у всех" так себе аргумент
Не согласен.
У пользователей, пользующихся такого рода утилитами сформировывается привычка, в каком порядке, что показывается.
Для меня сейчас путаница в том, что:
На рабочем столе получаю такую информацию:
Style: 0x56003A40 ▪ ExStyle: 0x00000000
Styles - SysListView32: 0x3A40 )
LVS_EDITLABELS := 0x0200
LVS_NOSCROLL := 0x2000
LVS_OWNERDATA := 0x1000
LVS_SHAREIMAGELISTS := 0x0040
LVS_ICON := 0x0000 ▪ !(LVS_REPORT | LVS_SMALLICON | LVS_LIST)
LVS_ALIGNLEFT := 0x0800 ▪ (LVS_ALIGNMASK = 0x0800)
( ExStyles - SysListView32: 0x15894C30 )
LVS_EX_AUTOAUTOARRANGE := 0x01000000
LVS_EX_AUTOSIZECOLUMNS := 0x10000000
LVS_EX_DOUBLEBUFFER := 0x00010000
LVS_EX_FULLROWSELECT := 0x00000020
LVS_EX_HEADERDRAGDROP := 0x00000010
LVS_EX_INFOTIP := 0x00000400
LVS_EX_LABELTIP := 0x00004000
LVS_EX_SNAPTOGRID := 0x00080000
LVS_EX_TRANSPARENTSHADOWTEXT := 0x00800000
LVS_EX_UNDERLINEHOT := 0x00000800
0x04000000
( Styles )
WS_CLIPCHILDREN := 0x02000000
WS_CLIPSIBLINGS := 0x04000000
WS_VISIBLE := 0x10000000
WS_CHILD := WS_CHILDWINDOW := 0x40000000
( ExStyles )
WS_EX_LEFT := 0x00000000 ▪ !(WS_EX_RIGHT)
WS_EX_RIGHTSCROLLBAR := 0x00000000 ▪ !(WS_EX_LEFTSCROLLBAR)
WS_EX_LTRREADING := 0x00000000 ▪ !(WS_EX_RTLREADING)
( Class Styles: 0x00004008 )
CS_DBLCLKS := 0x0008
CS_GLOBALCLASS := 0x4000
Из этого непонятно, что такое Style: 0x56003A40 и из чего он состоит.
сформировывается привычка
Ну мне например не нравится всматриватся в префиксы.
Или к примеру остаток наблюдал типа - 0x00010000, и мне надо разглядывать сколько нулей до или после единицы, чтобы понять - это оконные стили неопределенны, или специфичные.
Для меня сейчас путаница
Сейчас, да, я и не спорю, оно же брошено недоделанное. Думаю что в таком виде будет:
Style: 0x56003A40 ▪ ExStyle: 0x00000000
( Styles: 0x56000000 )
( Styles - SysListView32: 0x3A40 )
( ExStyles: 0x00000000 )
( ExStyles - SysListView32: 0x15894C30 )
( Class Styles: 0x00004008 )
Во вкладке Button если вставить Vk code, то результат будет отличаться от:
https://docs.microsoft.com/en-us/window … -key-codes
Не понял...
vk20 = Space
Не переводятся Undefined, Reserved, IME Kana mode и т.д.
Так их нет в GetKeyName. И зачем они нужны?
Например, если встретится такой виртуальный код в чужом коде, чтобы понимать, что он означает.
Подумаю, можешь кстати помочь составить массив 15:"VK_KANA",.
А зачем такие коды могут использоваться?
Именно эти, как я понимаю, для переключения режимов посылки иероглифов с европейской клавиатуры.
Дальше, наверное, лучше тебе самому подправить.
SetFormat, IntegerFast, dec
WebRequest := ComObjCreate("WinHttp.WinHttpRequest.5.1")
WebRequest.Open("get", "https://docs.microsoft.com/en-us/windows/desktop/inputdev/virtual-key-codes")
WebRequest.Send()
ResponseText := RegexReplace(WebRequest.ResponseText, "s)^.+?<tbody>(.+?)</tbody>.+$", "$1")
match := "", Pos := 1
While Pos := regexmatch(ResponseText, "s)</dt> <dt>(.+?)</dt>.+?<td style="""">(.+?)<br>", match, pos+StrLen(match))
{
arr := StrSplit(match1, "-")
if (arr[2] = "")
arr[2] := arr[1]
else
arr[2] := "0x" arr[2]
match1 := arr[1]+0
loop
{
fin .= match1 ":""" match2 """`r`n"
if (match1 = arr[2])
break
match1++
}
}
msgbox % clipboard := fin
для переключения режимов посылки иероглифов с европейской клавиатуры.
То есть не для переключения раскладки?
Дальше, наверное, лучше тебе самому подправить.
Я взял из Constantine.ahk, попроще в массив перевести, и OEM specific расписаны.
Например "0x9E is Unassigned" - Почему не WheelDown?
То есть не для переключения раскладки?
https://habr.com/ru/post/183858/
Кстати тут еще дополненные кнопки:
http://www.kbdedit.com/manual/low_level_vk_list.html
VK_ABNT_C1 0xC1 Abnt C1
VK_ABNT_C2 0xC2 Abnt C2
Может еще какие есть.
Добавил до кучи обратную конвертацию, "symbolic names" в значение.
Странно работает.
При вписывании "Q" либо "q" получаем "vk51sc10" - OK.
При вписывании "1" - "vk31sc2" - OK, а при вписывании "!" почему-то "1".
И при вписывании пробела почему-то "Space".
Так и работает GetKeyName в AutoHotkey.
Сейчас по двойному клику по названию заголовка он отображается сверху.
Неудобно, что по двойному клику нету привязки заголовка к верху окна - в зависимости от наполнености заголовок прыгает.
Согласен, тоже сразу не понравилось, но простого решения не нашёл, подумаю ещё раз.
Удалось что-то придумать?
И лично меня розовый фон UIA Interface отвлекает - может это сделать опционально?
И иногда AhkSpy вылетает с ошибкой 0x80070578 - INVALID_WINDOW_HANDLE в Uia ElementFromPoint.
Розовый фон только когда HWND или PID отличаются от MouseGetPos. Опционально сделано отключение UIA Interface, из за не понятных ошибок в том числе.
На счёт заголовков больше не думал, не вижу простых решений, усложнять из за этого не хочется, нагрузка и так высокая.
Розовый фон только когда HWND или PID отличаются от MouseGetPos.
Предлагаю цвет сделать опционально, так как когда работаешь с IE, то постоянно прыгающий розовый прямоугольник отвлекает.
Чтобы не выводить ошибки UIA Interface можно закомментировать эту строку:
throw Exception(UIA_Hex(hr) " - " err[hr], -2, i2 " (" i1 ")")
Сделал.
В Win10 при перемещении окна когда открыто окно лупы, ужасные тормоза.
Проблема в DeferWindowPos. Если оставить oOther.hZoom (слоёное окно), то есть закомментить oOther.hZoom
; hDWP := DllCall("DeferWindowPos"
; , "Ptr", hDWP, "Ptr", oOther.hZoom, "UInt", 0
; , "Int", x + w, "Int", y, "Int", 0, "Int", 0
; , "UInt", 0x0011) ; 0x0010 := SWP_NOACTIVATE | 0x0001 := SWP_NOSIZE
то тормоза намного меньше, в семёрке таких проблем никогда не было.
If oOther.ZoomShow
{
x := NumGet(Lp + 0, 8 + PtrAdd, "UInt")
y := NumGet(Lp + 0, 12 + PtrAdd, "UInt")
w := NumGet(Lp + 0, 16 + PtrAdd, "UInt")
hDWP := DllCall("BeginDeferWindowPos", "Int", 3)
hDWP := DllCall("DeferWindowPos"
, "Ptr", hDWP, "Ptr", hGui, "UInt", -1 ; for +AlwaysOnTop
, "Int", 0, "Int", 0, "Int", 0, "Int", 0
, "UInt", 0x0003) ; SWP_NOMOVE := 0x0002 | SWP_NOSIZE := 0x0001
hDWP := DllCall("DeferWindowPos"
, "Ptr", hDWP, "Ptr", oOther.hZoom, "UInt", 0
, "Int", x + w, "Int", y, "Int", 0, "Int", 0
, "UInt", 0x0011) ; 0x0010 := SWP_NOACTIVATE | 0x0001 := SWP_NOSIZE
hDWP := DllCall("DeferWindowPos"
, "Ptr", hDWP, "Ptr", oOther.hZoomLW, "UInt", 0
, "Int", x + w + 1, "Int", y + 46, "Int", 0, "Int", 0
, "UInt", 0x0211) ; 0x0010 := SWP_NOACTIVATE | 0x0001 := SWP_NOSIZE | SWP_NOOWNERZORDER := 0x0200
DllCall("EndDeferWindowPos", "Ptr", hDWP)
}