flat assembler
Message board for the users of flat assembler.
Index
> Windows > [solved]WM_LBUTTONDOWN >> table of childs Goto page 1, 2 Next |
Author |
|
macomics 23 Aug 2021, 17:03
You can list all the child windows, calculate their rects and check if a click hits this area. This way you will get rid of the array, but it is even less elegant. In any case, you can't do without processing all rects. The maximum that can be simplified is to process the list of windows in depth. If the click hit one of the windows, and it has children, then continue checking at the new nesting level. But you can put this in the mouse movement handler, save the window that the cursor hits when moving and use it for addressing when clicking.
|
|||
23 Aug 2021, 17:03 |
|
Overclick 23 Aug 2021, 17:09
I was thinking to check all "Y" then rest of "X" or something like that.
Quote:
I don't want any. Otherwise I check child's ID and that's it |
|||
23 Aug 2021, 17:09 |
|
macomics 23 Aug 2021, 17:19
Overclick wrote:
You have this happening in any case when checking the area. So you can still arrange the array in ascending order of the X axis, and the windows with equal X by Y. Use the dictionary search option. If the X value of the current window is greater than the X of the click, then all subsequent ones have more too. add: When using a sorted array, you can also split the window in half, analyze the X position of the click (less than the middle or more) and start searching in the array from the beginning or from the end. Code: if (click.x < width / 2) for (int i=0; i<countl; i++) { if (rect[rect_asc[i]].top > click.x) break; if (rect[rect_asc[i]].botom < click.x) continue; if (rect[rect_asc[i]].left > click.y) continue; if (rect[rect_asc[i]].right < click.y) continue; if (check_z_order(i)) /*if needed*/ call_window_proc(i, WM_CLICK); } else for (int i=count-1; i>=0; i--) { if (rect[rect_dsc[i]].bottom < click.x) break; if (rect[rect_dsc[i]].top >click.x ) continue; if (rect[rect_dsc[i]].left > click.y ) continue; if (rect[rect_dsc[i]].right < click.y ) continue; if (check_z_order(i)) /*if needed*/ call_window_proc(i, WM_CLICK); } |
|||
23 Aug 2021, 17:19 |
|
Overclick 24 Aug 2021, 18:16
It is too complicated for me
I prefer to check it one by one. Thanks anyway. Code: .wm_lbuttondown: cmp [lbuttondown],0 je @F jmp [lbuttoncontinue] @@: mov r15,Clicks mov r14,32 mov r13,24 mov r10,r9 shr r10,16 sub r15,r14 @@: mov r12,16 add r15,r14 cmp r15,ClicksEndStruct je .dragwindow cmp byte[r15+r13],1 jne @B cmp r9w,[r15+r12] jl @B add r12,4 cmp r10w,[r15+r12] jl @B add r12,4 cmp r9w,[r15+r12] jg @B add r12,4 cmp r10w,[r15+r12] jg @B sub r15,14 jmp qword[r15] .dragwindow: invoke ReleaseCapture invoke SendMessage,[hWnd],WM_SYSCOMMAND,0xF010,0 mov rax,1 ret
|
||||||||||
24 Aug 2021, 18:16 |
|
macomics 24 Aug 2021, 19:36
Overclick wrote:
Either I didn't understand something, or add r12, 2 But if we at least order the records by the X coordinate, then after the first check Quote:
if the numbers are placed in an 8-byte register, then by changing their sequence, you can try to compare two numbers at once in one register Quote:
Quote:
|
|||
24 Aug 2021, 19:36 |
|
Overclick 24 Aug 2021, 20:33
Quote:
I forgot to change that sizes. All for tomorrow... The rest is correct. There is no temp as you said. It is resized rectangles for different windows sizes and converting code I did not precent as it is different part of the code but there will be actual rectangles. |
|||
24 Aug 2021, 20:33 |
|
macomics 25 Aug 2021, 11:25
Overclick wrote: There is no temp as you said. In my example, the name is not important. I wanted to show the order of the sequence. Given that the data completely fills into one 8-byte register, it is possible to emulate the operation of MMX/SSE on 2-byte signed numbers. For example Code: mov rax, [r15+r12] or rax, r10 ; r10 = 0x8000800080008000 sub rax, r9 ; (Y shl 48 ) or (X shl 32 ) or (( Y - 1 ) shl 16 ) or ( X - 1 ) and rax, r10 ; r10 = 0x8000800080008000 cmp r9w, [r15+r12] ; only for arranged . . . jg .dragwindow ; . . . records cmp rax, rdx ; rdx = 0x8000800000000000 ; L < X - 1, T < Y - 1, L + W >= X, T + H >= Y jnz @b add r15, 8 jmp qword [r15] add: correct. it's just sample Last edited by macomics on 25 Aug 2021, 18:43; edited 3 times in total |
|||
25 Aug 2021, 11:25 |
|
Overclick 25 Aug 2021, 15:36
You cannot do like that...
Your code takes more operations for single rectangle and it is have no sense at all, you missunderstand what .dragwindow is, you cannot compare more than 32bit immediate values, 64bit needs to be preloaded partly to some register for that. And yes, my clicks are prepared for quick size recalculations by SSE and it is aligned to 16 already for that. I probobly will resort positions for better recalc optimisation, will see later, little bussy last days. But it is good idea to compare values by SSE too. All I need is little converting right and bottom values to make sure all values prepared for single compare operation. I will try and see what way is most elegant |
|||
25 Aug 2021, 15:36 |
|
Overclick 25 Aug 2021, 16:07
Yeah, I defenetely will migrate to SSE as my D2D layers uses float rectangles. It is much easy to convert sizes all together as float. I have to prepare my clicks array at same way -- dwords
|
||||||||||
25 Aug 2021, 16:07 |
|
macomics 25 Aug 2021, 17:27
In the example, I just showed the principle by which you can act. In my example, there will be much fewer operations left in the loop, but it will require more operations to prepare for the start of the cycle (see comments). And the immediate values can be written anywhere. How and where to place them is up to you to decide.
Code: mov rax, [r15+r12] or rax, rdi ; rdi = 0x8000800080008000 sub rax, rbx ; ( Y shl 48 ) or ( X shl 32 ) or (( Y - 1 ) shl 16 ) or ( X - 1 ) and rax, rdi ; rdi = 0x8000800080008000 cmp r9w, [r15+r12] ; only for arranged . . . jg .dragwindow ; . . . records cmp rax, rsi ; rsi = 0x8000800000000000 ; L < X - 1, T < Y - 1, L + W >= X, T + H >= Y jnz @b add r15, 8 jmp qword [r15] Code: cmp r9w,[r15+r12] jl @B add r12,4 cmp r10w,[r15+r12] jl @B add r12,4 cmp r9w,[r15+r12] jg @B add r12,4 cmp r10w,[r15+r12] jg @B sub r15,14 jmp qword[r15] Code: push r9 mov [rsp+2], r10w mov [rsp+4], r9w mov [rsp+6], r10w sub dword [rsp], 0x10001 pop rbx mov rdi, [const8000800080008000] mov rsi, [const8000800000000000] mov r12, 16 |
|||
25 Aug 2021, 17:27 |
|
Overclick 25 Aug 2021, 19:43
That is float example. Not sure it gives me any benefits anymore...
|
||||||||||
25 Aug 2021, 19:43 |
|
Overclick 25 Aug 2021, 23:13
This one is much better. Already tested.
|
||||||||||
25 Aug 2021, 23:13 |
|
Overclick 25 Aug 2021, 23:26
But I've got some issue: mouse point coordinates shifted by transparent ages of window or something LOL
Maybe wrong size of window or something, going to check its rect from GetClientRect... ... Yeah,377x494 mystically changed to 363x480. Is there some sort of rules for that sizes? What if I just set it back to required one? Will see... Anyway I need to complete the resizing coeficient for this project... ... Fixed by AdjustWindowRectEx |
|||
25 Aug 2021, 23:26 |
|
macomics 26 Aug 2021, 11:03
The GetWindowRect function instead of GetClientRect does the same thing without AdjustWindowRectEx
add: my typo Then specify where you used the function. GetWindowRect = GetClientRect + AdjustWindowRectEx, but only after creating the window. Last edited by macomics on 26 Aug 2021, 11:56; edited 2 times in total |
|||
26 Aug 2021, 11:03 |
|
Overclick 26 Aug 2021, 11:32
I don't need window's rect for clicks. I need to plase texture's initial rectangle when creating window to hit my clicks coordinates later. The only way to prepare correct sizes is AdjustClientRectEx. GetWindowRect helps nothing for that.
For example: Code: mov [Rect.left],0 ;init point mov [Rect.top],0 mov [Rect.right],377 ;init size of client area mov [Rect.bottom],494 invoke AdjustWindowRectEx,Rect,WS_POPUP or WS_VISIBLE,\ 0,WS_EX_LAYERED or WS_EX_TOPMOST mov r10d,[Rect.right] mov r11d,[Rect.bottom] sub r10d,[Rect.left] ;init size of window to adjust required client area sub r11d,[Rect.top] invoke CreateWindowEx,WS_EX_LAYERED or WS_EX_TOPMOST,\ className,'Any temp',\ WS_POPUP or WS_VISIBLE,\ [Rect.left],[Rect.top],r10d,r11d,0,0,\ [wcex.hInstance],0 |
|||
26 Aug 2021, 11:32 |
|
macomics 26 Aug 2021, 11:58
so the problem was not even in the place that you are dealing with - be careful
|
|||
26 Aug 2021, 11:58 |
|
Overclick 26 Aug 2021, 13:34
What problem you talking about?
|
|||
26 Aug 2021, 13:34 |
|
macomics 26 Aug 2021, 13:53
We initially talked about WM_LBUTTONDOWN, and this is an event handler that occurs after full initialization.
Overclick wrote:
But then you mentioned the AdjustWindowRectEx function, which is only useful during initialization. Overclick wrote:
So I just didn't understand how you fixed the problem, given that you started with the mention of GetClientRect. ... in general, it does not matter. never mind ... And one more clarification. What is the approximate number of areas you have to work with and their state (static/dynamic). |
|||
26 Aug 2021, 13:53 |
|
Overclick 26 Aug 2021, 18:06
You are totally wrong.
1) WM_LBUTTONDOWN works with client area even if my D2D renderTarget can adjust window area instead of client area to render. 2) My clicks rectangles taken from image redactor with fixet sizes. It's pointless to hardly recalculate each one of them. 3) GetClientRect on that context I used for debbuging current size of area. That's it. I may say I will check the rect, for example. 4) State -- Active/Inactive As my areas would be shuted off by some popup or animations or state of switchers... I think it's too much for that little code. I need to move forward. Thanks for your attention, this thread is solved.
|
|||||||||||||||||||
26 Aug 2021, 18:06 |
|
Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.