Test piece for DrawFocusRect API.

[hutch--]

This is just a bare test piece to get the logic right so that you can draw or select rectangular sections in the client area of a Window. It is written in three messages, WM_LBUTTONDOWN, WM_MOUSEMOVE and WM_LBUTTONUP to get the correct pairing of DrawFocusRect() calls so that the XOR characteristic removes the last outline.

The method is probably better canned in a seperate window sio that it can be used a s a child window of a main window and it could do with mouse restraint to the window area but it seems to work OK. It currently draws a white rectangle in the client area of the Window so you know where its been.

[attachment deleted by admin]

[chep]

Hi,

Here the WM_MOUSEMOVE has a real problem (on Windows XP) :(

It behaves oddly :
- with only the first DrawFocusRect call, nothing is displayed (which is a normal behaviour so far)
- but with either both DrawFocusRect calls or only the second one, the result is the same (ie. it behaves just like if there was only the second call) :dazzled: :dazzled: :dazzled:

I also noticed that whenever the mouse is on the same column or row than the original (LBUTTONDOWN) coordinates, I always get the same numbers in the caption : 1244788 2010200898 0 393578.
I don't see how this could be related, but who knows ?
That's really strange, as your code seems ok...



Also, a single click (with no mouse movement) leaves a small mark on the screen.
I solved this by commenting the two subs (Rct.left/top) just before DrawFocusRect in WM_LBUTTONDOWN.

[hutch--]

If the problem is just the numers on the title bar, it is probably a messup I made with the two macros that handle signed and unsigned conversions for the numbers. Would you replace the two macros with these and try it again. I was mainly interested in whether the selection rectange showed correctly.

Code Select Expand


      ustr$ MACRO DDvalue   ;; unsigned integer from string
        LOCAL rvstring
        .data
          rvstring db 20 dup (0)
        align 4
        .code
        ;; invoke dwtoa,DDvalue,ADDR rvstring
        invoke crt__ultoa,DDvalue,ADDR rvstring,10
        EXITM <OFFSET rvstring>
      ENDM

      sstr$ MACRO DDvalue   ;; signed integer from string
        LOCAL rvstring
        .data
          rvstring db 20 dup (0)
        align 4
        .code
        invoke dwtoa,DDvalue,ADDR rvstring
        ;; invoke ltoa,DDvalue,ADDR rvstring
        EXITM <OFFSET rvstring>
      ENDM


[chep]

Well, macros replaced, & I get the same odd numbers whenever (xpos2/3 == xpos1) or (ypos2/3 == ypos1). ::)

I'll dig into my sources if I have the time this afternoon, I remember I made it in C once.

Cheers

[hutch--]

chep,

As I develop on win2k sp4, what I need to know is if the focus rectangle displays properly when dragging the mouse and does it draw the white rectangle with a black line outline.

LATER :
I tested it on win98se and it has problem there as well. I have been caught before developing on win2k and testing it on other versions. I just did a rat threough the archives of 3 machines and I cannot find the last version I wrote that did work.

[chep]

Ok, I guess I haven't expressed myself correctly, sorry about that. :red

The focus rect does display, but the "XOR characteristic removing the last outline" doesn't work properly. You'll find a screenshot attached.
However the white rectangle does display properly when the mouse button is released.

I'm running Windows XP.

[attachment deleted by admin]

[hutch--]

chep,

Thanks, that is the same effect I got on win98se.

[zooba]

Same as Chep for me on Windows XP.

I'll be on a Win2K box later today, I'll give it another go then ;-)

[hutch--]

I have this version working on win98se so it may have fixed the problem. After testing various things, testing for the left button down in the mouse move message seems to have solved the problem. I also set a minimum rectangle size to draw the result sio that a single mouse click did not leave a mark on the client area.

[attachment deleted by admin]

[chep]

:clap: It now works fine here.

However I still think you should remove the two subs (Rct.left/top) just before DrawFocusRect in WM_LBUTTONDOWN :
- if you click then hold the button without moving the mouse, a small mark still appears near the pointer
- if you do the same eg. on the desktop, it doesn't happen

Ok, it's only a 1 pixel problem but this enlarges the selection by one pixel at the left & at the top, which IMHO is not correct strictly speaking. I believe the selection's left & top should really be the original mouse coordinates.

Good work anyway!

[zooba]

Yep, works fine. The original didn't on this Win2K, but the newer one does ;)

BTW. is it using the value in the registry for drag distance or is it just hardcoded? (I haven't looked at the code yet)

[hutch--]

zooba,

I only used the registers to do the swaps of co-ordinates as it was easier in that form than mixed registers and memory. Its probably a bit tidier to do that was as it still involves a memory to memory copy.

chep,

I will play with the location of the minimum start size of a rectangle but it was mainly to get the idea wrking properly first.

[hutch--]

Here is a rewrite that puts the capacity into a self contained window that is placed in the client area as a child window. The last one appeared to work by "magic" in that the overwrite rectangle co-ordinates apear to have been picked up on the stack even though they wree not be saved between iterations of the WndProc. This version uses extra window memory to save the rectangle co-ordinates. It was not intended particularly as a drawing window and the rectangle results are retrieved from the window extra memory by a procedure after the data is written to extra window memory called from the parent WndProc in a WM_COMMAND message.

It is working OK on win98se and win2k.

[attachment deleted by admin]

[Phil]

Thanks Hutch. Works fine on XP too.

[hutch--]

I have kept working on it and its now close to being a properly independent control. It has an extra parameter to specify the WM_COMMAND ID number to process the results with, a more or less garranteed unique class name(1) so that seperate windows can be changed without changing other instances of it. Using a normal API the background colour and cursor can be changed.

(1) The unique name is a string that has the string conversion of GetTickCount appended to it so after 49.5 days, if you start another instance of the window within the same app, there is a one in probably 4 billion chance that you will get the identical tick count and end up with a non-unique name. This may not be a problem.  :green

[attachment deleted by admin]