Moving things around the screen w/GDI

[zedd]

It is much better now.

But there are issues when bitmap.x or bitmap.y is outside of the client area. The transistor gets placed, but is immovable after that placement.





When can we see the code?

[NoCforMe]

For those interested, code is attached.
Yes, selection is still imperfect; still no boundary checking being done. (Which is surprising, since the display code couldn't care less about that, but it does prevent re-selection if you move the thing outside the window.)

Here's the current, simplified moving scheme:

You cannot view this attachment.

So this is pretty much done as a proof of concept.
There are issues to be considered. One is this: if this is used in a graphics program with lots of objects on-screen, then you need to deal with the Z-axis problem.

As it is, any "object" you move is going to end up on top of everything else. But that isn't always what you want if you have objects that are in a certain Z-order.

Easy enough to fix, though: when done moving, just redraw everything in the proper Z-order.

[NoCforMe]

OK, that's basically what I said 

Yes. You certainly deserve credit for that.

[sinsi]

when done moving, just redraw everything in the proper Z-order.

I imagine that's what happens anyway, draw the final screen on mouse up.

Are you capturing the mouse or using down/move/up?

[zedd]

Are you capturing the mouse or using down/move/up?

The source is in #16...

[NoCforMe]

Are you capturing the mouse or using down/move/up?

Good question; no, not using mouse capture. It didn't seem to be needed, although it might solve the drag-the-thing-partially-off-window problem.

In DialogGen I found I had to use mouse capture to make moving things around work properly.
Further research needed.

[sinsi]

After a quick look, just one thing. With WM_LBUTTONDOWN the mouse coordinates in lParam are signed words, so you should be using movsx and the signed jumps (JL rather than JB).
It doesn't matter nearly all of the time but you will eventually have it bite you in the arse 

I'll go through it in more detail once my visitors (Jack and Mary) have departed but it looks good

[zedd]

After assembling the source from #16 the program shows me no signs of any artifacts. No obvious flickering either. 

I did however change the main window style to enable minimizing/maximizing and resizing the window by dragging window edges. Of course severe gdi leaks occurred when adjusting the main window. But you already know about that.

Minimal gdi leaks otherwise, but still present. Also already known.

It seems to be getting much closer to "production ready" in any case. 

One thing though. How easy/hard would it be to place the transistor, and deslect it upon releasing the left mouse button, instead of having to click outside of the transistors RECT to deselect it?
Another possible bug...
Added later: Sometimes the transistor stays bound to the mouse cursor position even after releasing the left mouse button... Not often, and cannot determine if is at certain positions only or just randomly. Once it happens though, the transistor can no longer be deselected, no matter the state of the left mouse button - and the transistor continues to follow mouse position.

more later upon further testing... (possible cause) If the left mouse button is double clicked while inside the transistorst RECT (as opposed to pressed and held while moving mouse)  that sometimes happens.

[NoCforMe]

OK, this version solves the "stranded at the border" problem.
It was an easy fix (and @sinsi, our minds ran in the same rut here):
It was a matter of using signed instead of unsigned comparisons in my hit-testing code (in the WM_LBUTTONDOWN handler:

Old way (bad):

Code Select Expand

; Hit testing:
CMP EAX, CurrObjX
JB noHit
CMP EDX, CurrObjY
JB noHit
MOV ECX, CurrObjX
ADD ECX, BmpW
CMP EAX, ECX
JA noHit
MOV ECX, CurrObjY
ADD ECX, BmpH
CMP EDX, ECX
JA noHit

; Hit!

New way (good):

Code Select Expand

CMP EAX, CurrObjX
JL noHit
CMP EDX, CurrObjY
JL noHit
MOV ECX, CurrObjX
ADD ECX, BmpW
CMP EAX, ECX
JG noHit
MOV ECX, CurrObjY
ADD ECX, BmpH
CMP EDX, ECX
JG noHit

There's still that occasional problem of the mouse getting "stuck" to the OBM. Further research required here.

I tried mouse capture, but it led to some weird problems, like the OBM completely disappearing.

[zedd]

There's still that occasional problem of the mouse getting "stuck" to the OBM. Further research required here.

Well shucks. But you are making some progress at least. I applaud your persistence.

[NoCforMe]

There's still that occasional problem of the mouse getting "stuck" to the OBM. Further research required here.

Well shucks. But you are making some progress at least. I applaud your persistence.

Well, that's actually the complicated part of this whole scheme: the sequencing of events.
You need to define what state the code is in, from selecting an object by clicking on it to starting to move it by dragging the mouse. That's the main problem I'm trying to solve here; my DialogGen program suffers some of the same problems due to incorrect handling of state.

I figure I'm about 75% there, with another 75% to go ...

[zedd]

I figure I'm about 75% there, with another 75% to go ...

Wait a minute! 75+75=150.

Does that mean it will end up 50% better than originally planned? 

[NoCforMe]

I figure I'm about 75% there, with another 75% to go ...

Wait a minute! 75+75=150.

Does that mean it will end up 50% better than originally planned? 

You mean you never heard anyone say "it's 90% done with 90% to go"?

It means it will take at least 50% longer to get anywhere than hoped for.

[zedd]

You mean you never heard anyone say "it's 90% done with 90% to go"?

Nope, never heard of it.

It means it will take at least 50% longer to get anywhere than hoped for.

Don't be so hard on yourself.
I would have put this in my "unfinished" pile already. I lack persistence and patience.

[TimoVJL]

"it's 90% done with 90% to go"

does that mean, that there is still 9% left  and 0.9 % abandoned and rest is tolerance