message pump variant X64

[mikeburr]

thats correct ..... we know that ...and ????

[mikeburr]

ok maybe i shd point out whats happening ... WM_CHAR isnt going to trap anything ...the messages come through WM_COMMAND ..high part of wParam set to 100 EN_PLEASE_DONT CHANGE ME   what i tried and this did indeed set it for update .. was to intercept and change the param with EN_UPDATE [400] .. which will reset it   .. [its all going throughthe default handler but despite now coming back with wParam high word 0 
BUT i still couldnt update [ ive got traps on various things including mouse tracking and key tracking as sections ..just in case which was very unlikely as i put a comprehensive filter which writes to a list box of all relevant messages .] .. there are several things to remeber here .. the Edit is a sub class of the main window in this case and prob in most cases ...[hence Hutchs reply earier ie the message for an edit box come through with hWnd as per main thread / window  [hence my earlier comment about maybe running into threading problems  ]  there were several things of interest .. when i entered the edit box the system  issued some _IME_ messages .. these are associated with wide char usually which arent set on here ... my includes etc are asci only as its only me thats running the stuff [although i did deliberately load and call messagebox wide as an experiment once and found that i could instantly speak Chinese or similar which was quite funny...].
The Real Point is that its no faster   there were no obvious gains as the program still worked if you pasted stuff into the edit boxes   but   as pointed out previously [hence the request to people that had tried something similar ]   you cant escape a long wait at the station because there arent any trains .....
regards    mike b

[hutch--]

Mike,

tenkey's point is a good one, make you message loop according to Windows specification and everything that should end up being pointed at the WndProc will get there. The message loop for an application is actually a blocking loop and if there are no messages waiting to be processed for that application process, it just sits there waiting for the next message to come.

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

msgloop proc

    LOCAL msg    :MSG
    LOCAL pmsg   :QWORD

    mov pmsg, ptr$(msg)                     ; get the msg structure address
    jmp gmsg                                ; jump directly to GetMessage()

  mloop:
    rcall TranslateMessage,pmsg
    rcall DispatchMessage,pmsg
  gmsg:
    test rax, rvcall(GetMessage,pmsg,0,0,0) ; loop until GetMessage returns zero
    jnz mloop

    ret

msgloop endp

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

You can directly process key strokes in the message loop as you get them when they come in with no 1 character lag.

[daydreamer]

old advice was to replace getmessage with peekmessage and run code if no messages,but if too much processing here,delayed wndproc message handling,thats one reason I want to change to use secondary thread for that code,instead,for modern multicore cpus

but with new knowledge,switch/case of the most important control keys to get fast response ,place call to keyboard handler PROC directly after detecting some keyboard message after translatemessage?
example code

Code Select Expand


;how do I 64bit version?
invoke TranslateMessage, ADDR msg
        mov eax, hWnd
        .if msg.hwnd == eax
          .if msg.message == WM_KEYUP
            .if msg.wParam == VK_F1
              invoke MessageBox,hWnd,
                                chr$(34,"now we change to fullscreen",34),
                                ADDR szDisplayName,MB_OK
                                 invoke ChangeScreenResolution,screenw,screenh,32
            .endif


[jj2007]

old advice was to replace getmessage with peekmessage

With 100% cpu use? Who gave that advice?

[hutch--]

 

You can forget that one Magnus, its a terrible technique from people who did not have a clue. If you really want to do "smarties", process key and mouse directly in the message loop, either before or after TranslateMessage() and/or DispatchMessage() depending on what you need to do.

[mikeburr]

hutch
i have several examples i wrote where i did exactly that .. ie process the key messages in the loop ... what i was trying to do was find out if i got rid of Translate message if this was slowing the process considerably .. but it doesnt seem to be .. so im still none the wiser as to Exactly what it does .. i was hoping that some body would post the Logic i guess ..  as youll see in the original post i contrasted it with exactly the standard loop youve posted   ... it prob doesnt matter now anyway
regards mike b

[jj2007]

so im still none the wiser as to Exactly what it does .. i was hoping that some body would post the Logic

everything works as it should EXCEPT the edit where its as though id set ES_READONLY [which i havent ] and it was annoying me

Your message pump doesn't call TranslateMessage. That's needed to create the WM_CHAR messages needed by EDIT controls for character input.

[tenkey]

why this isnt being effected for the edit boxes ive yet to discover at the time of writing ..

The edit box is a window that has it's own WndProc (called by DispatchMessage) that traps and processes WM_CHAR messages for character keypresses. When the edit box WndProc receives this message, it redraws the edit box to show the new character. You need to call TranslateMessage to make the edit box accept characters from the keyboard.

At https://docs.microsoft.com/en-us/windows/win32/inputdev/keyboard-input there is a description of the WM_CHAR message.

[mikeburr]

yes thanks ... i know this ...what im trying to find out is how translate message does this ...ie ...what is the logic ...and therefore could i obviate it easily .. [as you can do by trapping the char controls in  the message pump ].. i tried  to reset the the EN_change in wParam [and effectively repaint the screen] sending the output via default message as a fix ...  im not sure if im getting what i was trying out very well ....
regards mike b

[hutch--]

Mike,

The main basic functions of getting a working window onto the screen is tied directly to the mechanics of Windows. What you have at this very basic level is boilerplate code, the bare bones of what needs to be done to create a window that will display on the screen. Once you have done this you can add menus, toolbars, any of a whole host of controls to do whatever you like.

Now tenkey has made a point that is important for you to understand, every window has its own message loop, some are easily accessed while others need a subclass to get access at the messages being passed to it by the operating system. Most messages are handled by the DEFAULT windows technique but you have access at these subclasses so you can interact with or alter messages sent to any specific window.

Something I have always done with either a new language OR a new OS version is to create a template that is the bare bones of a working window. This way you know the basics of how the window works and you can then add to it in whatever way you like, as long as you can get it to work. Start from the bottom and you will know why you do certain things.

[tenkey]

what im trying to find out is how translate message does this ...ie ...what is the logic ...and therefore could i obviate it easily

I don't know how much of TranslateMessage you want to replicate. A list of available keyboard information is in

https://docs.microsoft.com/en-us/windows/win32/inputdev/about-keyboard-input

There are links to other info such as the WM_KEYDOWN message and the virtual key codes.

[daydreamer]

what im trying to find out is how translate message does this ...ie ...what is the logic ...and therefore could i obviate it easily

I don't know how much of TranslateMessage you want to replicate. A list of available keyboard information is in

https://docs.microsoft.com/en-us/windows/win32/inputdev/about-keyboard-input

There are links to other info such as the WM_KEYDOWN message and the virtual key codes.

I have a proc that takes care of all vk codes, don't think it's much difference call it in wm_keydown in wndproc switch/case or directly insert invoke keyboard handler after translatemessage
But I take advantage of make alternative mouse control , like
vm_rbuttondown :
Invoke keyb,vk_enter

[tenkey]

Do you use TranslateMessage with your vk handler? The edit boxes won't work properly without the new message generated by TranslateMessage. The equivalent code (to TranslateMessage) will need to track the shift keys and then PostMessage the new message to the window handle retrieved from GetMessage's lpMsg. Other considerations include keyboard layout of non-letters and non-Latin keyboards.

[mikeburr]

yes thanks tenkey et al .. i couls either just declare the Edit boxes as UNEDIT class ..or whatever name i chose ... or superclass the lot which is easier
it happens
i prob havent explained the objectives but i have very limited input data [ onlt numbers in edit boxes ...
and about 6 windows on my skeleton program each of which runs in its own thread and is largely menu driven .. the menus are built from a CSV file
im creating the windows using a CSV file so create file is totaly generic .. each window is held as a template in heap allocated storage and the edit boex for each
[ there are about 30 - 40 functions on some windows so potentialy a lot of "boxes" ]   the boxes are doubly linked to the window definitions in separate heaps
storage
im just working on relocation of the boxes [ and thus restructuring of the windows now i have some spare time so think of a resource definition program except its embedded in the program and redifned by merely changing theheap definitions and reshowing [i dont physically delete just mark btw but the need to deete is fairly rare
its very good for building the windowing side quickly as you can experiment with things like cursors etc quicky so i can tell you for instance that about 10 cursors are missing from your windows includes [32652 - 32661 ?? the last one displays a cd .. etc
the reason i asked the translate message is because i might use the NTDLL & GDI primitives [some GUI functions] as i want  to make one of the screens a sort of graphic implementation  a bit like euclidean geometry resulting from the calculations etc etc .. so while i was at it i thought id look through translate dispatch
what a can of worms .. every bloody syscall changes with virtually every new variant of the OP SYS .. i think MS must have gone nuts thinking that this would stop IDIOTS hacking things like the OEM keyboard functions etc  etc
it involved a long and tedious search through the obscurities of "translate message ... USER32" and ... NTDLL etc etc and im still not sure yet what im going to do
but thanks for your help // i was just hoping for something a little more "in depth" // .. i ought to point out that the system makes considerable use of FS and the 0x18 TEB .. i can understand why as i pointed out in my first post theres threading issues need to be thought through .. but this cant help the system as its a bottleneck for sure .. there are quite a lot of other things going on that considerably slow the raw machine ... there good but sometimes you want to chuck the bodywork of a car away or take the tank and wife off the back of your motor bike to make it go a lot faster #
regards mike b
ps i havent read this through to check it so im afraid its prob a bit scrambled