1. Если вы только начинаете программировать на ассемблере и не знаете с чего начать, тогда попробуйте среду разработки ASM Visual IDE
    (c) на правах рекламы
    Скрыть объявление

Обработка удержания клавиши.

Тема в разделе "WASM.WIN32", создана пользователем Полный 30h, 1 сен 2020.

  1. Полный 30h

    Полный 30h Member

    Публикаций:
    0
    Регистрация:
    7 дек 2016
    Сообщения:
    36
    Адрес:
    Институт Мичурина
    Доброго дня.

    Вопрос следующий. В программе для обработки нажатия клавиши использовал следующее
    Код (ASM):
    1.       cmp     [wparam],BN_CLICKED shl 16 + ID_PLS  ; нажатие кнопки PLUS
    2.         je      .push_plus
    Всем оно хорошо, кроме того, что для создания очередного события нужно кликать. А вот как выявлять удержание клавиши, найти в интернете так и не смог.

    Соорудил что то типа этого
    Код (ASM):
    1.         invoke SendMessage,[hPLS],BM_GETSTATE,0,0  ;
    2.                cmp eax,108      ; значение найденное методом тыка. возвращает при удержании
    3.                 jnz @F    
    4.                 nop; событие
    5.        @@:
    Но не совсем уверен что сделал правильно. Кто нибудь может ткнуть в кусок кода или статью по обработке удержания клавиши?

    З.Ы. не нашел в редакторе как правильно выделять код.
     
  2. Mikl___

    Mikl___ Супермодератор Команда форума

    Публикаций:
    14
    Регистрация:
    25 июн 2008
    Сообщения:
    3.179
    [соdе=asm]код[/соdе]

    возможно
    Код (ASM):
    1. cmp msg,WM_KEYDOWN
    2. jne    @f
    3. mov key_press_flag,TRUE
    4.  . . . .
    5. cmp msg,WM_KEYUP
    6. jne    @f
    7. mov key_press_flag,FALSE
     
    Полный 30h нравится это.
  3. Полный 30h

    Полный 30h Member

    Публикаций:
    0
    Регистрация:
    7 дек 2016
    Сообщения:
    36
    Адрес:
    Институт Мичурина
    Эээ... не совсем понял.
    Я так понимаю msg,WM_KEYDOWN будет отрабатывать по любой кнопке? Каким образом разрулить это сообщение для персонализации нажатия конкретной клавиши?
     
  4. Mikl___

    Mikl___ Супермодератор Команда форума

    Публикаций:
    14
    Регистрация:
    25 июн 2008
    Сообщения:
    3.179
    Полный 30h,
    после нажатия на клавишу в wParam будет код клавиши, например после нажатия на W/w/Ц/ц в wParam будет код VK_W
     
    Полный 30h нравится это.
  5. Полный 30h

    Полный 30h Member

    Публикаций:
    0
    Регистрация:
    7 дек 2016
    Сообщения:
    36
    Адрес:
    Институт Мичурина
    Mikl___, всё понял.
    Большое спасибо!
     
  6. Indy_

    Indy_ Well-Known Member

    Публикаций:
    4
    Регистрация:
    29 апр 2011
    Сообщения:
    4.481
    Поток будет спать в теневом ядре ожидая эвент; как только кнопка будет нажата он выйдет из ожидания, пройдёт обратный ядерный вызов, далее отработает толстый слой гуя и будет паблик вызов оконной процедуры. Какое место в данном механизме интересно ?
     
  7. Полный 30h

    Полный 30h Member

    Публикаций:
    0
    Регистрация:
    7 дек 2016
    Сообщения:
    36
    Адрес:
    Институт Мичурина
    Любопытно о чем речь вообще.
     
    Последнее редактирование модератором: 2 сен 2020
  8. A_L_E_X

    A_L_E_X New Member

    Публикаций:
    0
    Регистрация:
    10 июл 2020
    Сообщения:
    13
    А может мухи отдельно, а котлеты отдельно надо? Из образца, как я понял, речь идет о нажатии кнопки в смысле объекта, а WM_KEYDOWN --вообще клавиатурные события.
    Так все же кнопка или клава надо? Для клавы EN_MSGFILTER надо, а не BN_CLICKED. Также BN_CLICKED не несет в себе информации о состоянии, это законченое событие и прилетает только когда кнопка отпущена.
    По нажатым кнопкам (не клавы), решение зависит от используемого стиля. Если это Ownerdraw, то одно, если Pushbutton, то другое.
     
    Полный 30h нравится это.
  9. Полный 30h

    Полный 30h Member

    Публикаций:
    0
    Регистрация:
    7 дек 2016
    Сообщения:
    36
    Адрес:
    Институт Мичурина
    По таким кнопкам (нарисованным) можно поподробнее?
     
  10. A_L_E_X

    A_L_E_X New Member

    Публикаций:
    0
    Регистрация:
    10 июл 2020
    Сообщения:
    13
    Универсального решения нет, всё зависит от стиля кнопки. Не спрашивайте почему так и что курили в Майкрософте ))
    Вы так и не сказали с каким стилем ваши кнопки, так что ответ тоже навскидку -- BN_PUSHED и BN_UNPUSHED
     
    Полный 30h нравится это.
  11. Полный 30h

    Полный 30h Member

    Публикаций:
    0
    Регистрация:
    7 дек 2016
    Сообщения:
    36
    Адрес:
    Институт Мичурина
    Спасибо. Буду вникать.
    На счет стиля не обессудьте. Изучение ассемблера у меня бессистемное, для души-) Поэтому о "стилях кнопок" имею весьма смутное представление. Попробую разобраться с этим сам.
     
  12. Mikl___

    Mikl___ Супермодератор Команда форума

    Публикаций:
    14
    Регистрация:
    25 июн 2008
    Сообщения:
    3.179
    Полный 30h,
    кнопку можно создать
    1. через ресурсы (так делают 99,8%)
    2. через CreateWindows окно класса BUTTON
    3. через Template-структуру
    4. вывести рисунок отжатой кнопки, а когда по этому рисунку жмут, рисунок меняется на рисунок нажатой кнопки
    5. и т.д. всего 20 с лишним способов
    Button StyleDescription
    Control Buttons
    B1No BitMaps. This button was drawn internally with colored text and background and does not have the BS_OWNERDRAWN style. It was created using SetTextColor, SetBkMode, FillRect and TextOut functions in the ButtColor procedure. In the procedure you have an option of filling the whole rectangle or creating a border and or frame. You can give it the appearance of a flat or raised button and you could get creative by using a CreatePatternBrush or CreateHatchBrush. I created a HiLite border around the rectangle on the Mouse over stage that looks like the default Windows HiLite border.
    B2Three BitMaps. This button is a standard Windows control button with a BS_BITMAP style. The images are created by using the SendMessage BM_SETIMAGE. The button has the default Windows HiLite border around the rectangle.
    B3Three BitMaps. This button has the BS_OWNERDRAWN style and the images are created with the BitBlt function. Note the images fill the complete button rectangle, No unwanted Windows default border
    B4Three BitMaps. This button has the WS_CLIPCHILDREN and BS_OWNERDRAWN style. The WS_CLIPCHILDREN style must be specified if you create a non-rectangle region. A region was created using the CreateEllipticRgn and the images are created with the BitBlt function.
    B5No BitMaps. This button has the WS_CLIPCHILDREN and BS_OWNERDRAWN style. A region was created using the CreateRoundRectRgn and the button was created using the same procedures as Style B1.
    B6No BitMaps. This button has the WS_CLIPCHILDREN and BS_OWNERDRAWN style. Two CreateRoundRectRgn regions were created, one for the button and one for its parent Window. The button was created using FillRgn, FillRect, and FrameRgn functions.
    PLAYTwo BitMaps. This button has the BS_OWNERDRAWN style and the images are created with the BitBlt function. Note the images fill the complete button rectangle, No unwanted Windows default border
    EXITTwo BitMaps. This button has the WS_CLIPCHILDREN and BS_OWNERDRAWN style. A region was created using the CreateEllipticRgn and the images are created with the BitBlt function.
    B7No BitMaps. This is Windows default button.
    B12No BitMaps. This is almost a transparent control button. It uses WS_EX_TRANSPARENT for the extended style and the BS_OWNERDRAWN style and the parent window must have the WS_CLIPCHILDERN style. But if you drag another window over the button or have any activity with the button it reverts back to the default button face color. To sort of fix the proplem I intercepted the WM_ERASEBKGND message and filled the button rectangle with the parent windows background brush, which would work ok if you didn't have a parent window background like the one that is used in this demo, you can see the mismatch in the pattern, but can restore the button to transparent by resizing the main window. In Windows 2000 you can use WS_EX_LAYERED extended style and the SetLayeredWindowAttributes function to have a true transparent control button. This button has the same appearance and function as the Toolbar button Style B13 and the HotSpot button Style B14.
    B15One BitMap. This button has the BS_OWNERDRAWN style and the images are created with the BitBlt function. Note the image fills the complete button rectangle, This is a flat control button that has three stages.
    1. Mouse off Creates the image and draws text on the bitmap.
    2. Mouse over Creates the image and draws a raised border and text on the bitmap.
    3. Mouse down Creates the image and draws a sunken border and text on the bitmap
    ToolBar Buttons
    B8, B10are not subclassed and have the standard toolbar button behavior.
    B9, B11, B13, B19are subclassed in a common procedure and have have three stages, Mouse off, Mouse over, and Mouse down. All of the ToolBar buttons have the CCS_NOPARENTALIGN, CCS_NORESIZE, TBSTYLE_LIST, TBSTYLE_FLAT, and CCS_NODIVIDER style.
    B8No BitMaps. This is a standard toolbar button that has Text only. Note the TBSTYLE_LIST Style must be specified for Text. The Text is created on the button with the TB_ADDSTRING SendMessage. Notice the Windows default rectangle around the button on Mouse over and Mouse down.
    B9Three BitMaps. This is a standard toolbar button that has Images only. The Images are created by using the TB_SETIMAGELIST and TB_CHANGEBITMAP SendMessages. Notice the Windows default rectangle around the button on Mouse over and Mouse down.
    B10One BitMap. This is a standard toolbar button that has Image and Text. Note the TBSTYLE_LIST Style must be specified for Text.
    The Image was created by using the TB_SETIMAGELIST and the Text with the TB_ADDSTRING SendMessage. Notice the Windows default rectangle around the button on Mouse over and Mouse down.
    B11Three BitMaps. This is a custom toolbar button and the images are created with the BitBlt function. Note the images fill the complete button rectangle, No unwanted Windows default border
    B13No BitMaps. This is a custom transparent toolbar button and the text and border are created with the ButtonType4 procedure. This button has the same appearance and function as the Control button Style B12 and the HotSpot button Style B14.
    B19No BitMaps. This is a custom colored toolbar button the color, text, and border are created with the ButtonType4 procedure. This button has the same appearance and function as the Control button Style B18 and the HotSpot button Style B20.
    HotSpot Buttons
    B14, B16, B17, B20No BitMaps. The HotSpots has a three stage appearence, MouseOff, MouseOver, and MouseDown. These HotSpots are basically the same each has an array of X – Y coordinates and when the WM_MOUSEMOVE intersects one of these coordinates it calls a procedure to draw the design of the button. The same is true for WM_MOUSEDOWN and WM_MOUSEUP.
    B16, B17are created with calls to the CreateHotButt procedure, which calls CreateRect and ButtColor.
    B14, B20are created with calls to ButtonType4 procedure
    B14has the same appearance and function as the Control button
    B12and the Toolbar button Style B13.
    B20has the same appearance and function as the Control button
    B18and the Toolbar button Style B19
     
    rk2019, GRAFik и Полный 30h нравится это.
  13. Полный 30h

    Полный 30h Member

    Публикаций:
    0
    Регистрация:
    7 дек 2016
    Сообщения:
    36
    Адрес:
    Институт Мичурина
    Mikl___, диалоговые окна я создавать умею. Ну как умею, сдираю первый попавшийся пример и готово. И с обработкой кликов кнопок (нарисованных) в обработчике событий, проблем не возникало. Они всё в тех же примерах имеются. А вот с обработкой удержания сколько не искал так и не нашел. Пока SendMessage вставил. Но как бы понимаю, что способ не единственный.
     
  14. Indy_

    Indy_ Well-Known Member

    Публикаций:
    4
    Регистрация:
    29 апр 2011
    Сообщения:
    4.481
    Полный 30h,

    > Из образца, как я понял, речь идет о нажатии кнопки в смысле объекта, а WM_KEYDOWN

    Как это работает - поток ввода принимает сообщения, ставит их в синхронную очередь. Затем запрашивающий событие ввода поток выходит из ядра с параметрами для формирования сообщений далее. Это обратный ядерный вызов. Далее идёт очень толстый юзер гуй, который даже я не знаю. Смысл в том, что в этом гуе нельзя разобраться, даже разрабы его не понимают он создан частями и собран. Поэтому следует использовать штатную документацию по интерфейсам, а не пытаться копать куда то глубже. Реши что тебе нужно, просто юзер гуй собрать или ядерные события фильтровать.
     
  15. GRAFik

    GRAFik Member

    Публикаций:
    0
    Регистрация:
    14 мар 2020
    Сообщения:
    193
    Что неужели и правда так все сложно и запутано? По-моему, Mikl___ разобрался в этом вопросе или это обманчивое впечатление?

    Всегда было интересно как некоторые разработчики программируют для своих программ собственный GUI, независящий ни от WinAPI, ни от других сторонних GUI-библиотек, чтобы, как они говорят, не было лишних проблем, ну и чтобы не зависить от конкретной OS? Насколько это сложно и что это за проблемы, если не брать во внимание зависимость от конкретной OS?
     
  16. Indy_

    Indy_ Well-Known Member

    Публикаций:
    4
    Регистрация:
    29 апр 2011
    Сообщения:
    4.481
    GRAFik,

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

    > программируют для своих программ собственный GUI

    Это пишется на базовых апи, глубже никто не лезет тк там всё плывёт в версиях.
     
  17. GRAFik

    GRAFik Member

    Публикаций:
    0
    Регистрация:
    14 мар 2020
    Сообщения:
    193
    Если опираться на базовые API, то программа ведь будет зависеть от конкретной OS, а разработчики собственных GUI, для своих программ, как раз и уходят от этой зависимости (в том числе). Я же выше написал про это.
     
  18. murder

    murder Member

    Публикаций:
    0
    Регистрация:
    3 июн 2007
    Сообщения:
    628
    Можно создать свою систему событий и для каждой ОС написать свой цикл генерации этих событий. При этом основная часть кода будет кросплатформенной.

    Инди имеет в виду полное понимание процесса, начиная с ядра. Для того, чтобы клепать гуйню на API такие глубокие познания не нужны.
     
  19. A_L_E_X

    A_L_E_X New Member

    Публикаций:
    0
    Регистрация:
    10 июл 2020
    Сообщения:
    13
    Базовые -- это средства отрисовки и перехвата событий, а это уже по уши в ВинАпи, других средств взаимодействия с ядром не предусмотрено. Интерфейсами разве что ещё можно, но опять же не всё и в такой же мере интеграции. Кроссплатформенными из гуи можно считать разве что файлы изображений ))
    Свой гуи нужен не для кроссплатформенности, а это лишь ещё один способ избавиться от рутины прописания майкрософтовских элементов, на пути создания приемлемого внешнего вида своей программы, но базовыми апи, так или иначе, пользоваться придется.
     
    Indy_ нравится это.
  20. GRAFik

    GRAFik Member

    Публикаций:
    0
    Регистрация:
    14 мар 2020
    Сообщения:
    193
    Всем спасибо за ответы. Достаточно интересная тема.

    Кто-нибудь может объяснить, насколько полное понимание процесса может помочь лучше понять работу GUI, чтобы например четко понимать в каких случаях лучше писать свой GUI, а в каких можно пойти по более легкому пути? Или же полное понимание процесса, может быть полезно только лишь если цель - написать свою OS, а в остальных случаях это лишняя трата времени?