Ok, the last control got worked over a bit after seeing some NT problems. This is the final control that i will refer to for the tut's purposes. I might l8r make a second version that has "hot tracking", but will then be limited to 98 and above.

This version is full OS suported (as far as i've been told).

Read the README.TXT, there has been mild changes from the last version, basicall cleaned up the requirement to specify bitmap size, and a forced limit on the caption to only 28 bytes.

Feedback and sugestions still welcome.
Here it is. Enjoy.
:alright:
NaN

EDIT Attachment removed, see below.
Posted on 2002-04-24 01:17:20 by NaN
Still doesn't support "up-state on mouseexit", which isn't hottracking
related and can be done with normal SetCapture :].

*whine whine*
Posted on 2002-04-24 02:01:12 by f0dder
Fodder, i read the MSDN for 2 hours following our discussion, and I still have no clue how to keep *everything* together without the use of the 98 API.

I encourage you to find solution, and will more than happy to credit you for your your efforts. I did a test with SetCapture, and it doesnt give me events when the mouse button doenst change a state. I used VKim's debug, and checked the WM_CAPTURECHANGED message (only message the MSDN says it will give up), and i only recieved dubug messages when the mouse button was pressed. Which doesnt help solve the 'moving off the client rect' problem.

Its frustrating to be honest, because I studied normal win95 button and it *can* recognize this. So there is *something* that will fit the bill, but i can't find the needle in this haystack.

Please, you give me something tangable, and i will work it in for you :)

I will give you a head start, heres all the "mouse info" the MSDN got to share on the topic .

:alright:
NaN
Posted on 2002-04-24 02:14:26 by NaN
well, when you have done SetCapture on a window (the foreground
window), you ought to receive WM_MOUSEMOVE messages even when
the mouse isn't above your control.

So, in WM_MOUSEMOVE, check the state of "being_clicked". If you're
currently being clicked, check if the cursor is on or outside the
control and update drawstate accordingly (of course only if it has
changed...)

I think this should work, but please bear over with me if it doesn't,
I'm trying to skew my sleeping disorder forward and turn day back into
day ;).
Posted on 2002-04-24 02:32:37 by f0dder
I feel so dumb that i didnt see that combination.

I just did some tests with the debug.inc, and yes i can now track outside the client area! Thanx for the tip.

I will now add the missing piece for you... (the tut will have alot of do's and dont's and why's to learn from at this point).

:alright:
NaN
Posted on 2002-04-24 02:53:26 by NaN
The above Download was nulled, as (thanx to f0dder's help), i now have it *exactly* like another button.

As well, since i was *still* pumping revisions into it, i provided a catch for when there is an image, but no text. In this case the image is directly centered into the button.

Here it is. It should be bug free, but please check it out.
Please let me know if there is no problems, so i will begin my tutorial on it. It seems every time I draw the line, something comes up :)

Anywho, my oppologies for the numberous 'final' products. I can say that the MASM32 dir never changed if its any consolation :) , however, the other two dirs did.

:alright:
NaN
Posted on 2002-04-24 04:08:52 by NaN
Thanks NaN

Works great on my xp box.
BTW, I guess you know everyting about SetCapture now. Is there a way to set capture to non client area? I have a little problem with my menu emulator in RadASM.

KetilO
Posted on 2002-04-24 04:40:33 by KetilO
SetCapture will redirect all mouse-input to your
window-quene, it doesn't matter if the Mouse
curser is within your client-rect or not... but as
far i know only ONE application can capture the
mouse, if your app is loosing the capture you'll
get a WM_CAPTURECHANGED message... what
is your problem excatly about? i had never
problems with mouse-cap so...


according to the api-ref there are a couple of
limitations so if you really want to get ALL mouse
input (coordinates, clicks, ...) you should use
hooks instead...
Posted on 2002-04-24 04:48:44 by mob
Hi mob

Instead of poluting NaN's thread I will start my own.

KetilO
Posted on 2002-04-24 06:01:23 by KetilO
Heheh, there's *ONE* thing left that I can think of... when a button
is disabled, the menu dropdown is still non-disabled color :).
Posted on 2002-04-24 09:21:04 by f0dder
:alright: Very nice control NaN! I'm sure people can use it.
Works fine on my win2k machine, I'll try later on some other machines.

Thomas
Posted on 2002-04-24 13:09:58 by Thomas
Great to hear it...

I will get going on the tut, while its still fresh in my head.

f0dder, :grin: you found my dirty secret. I found that too, but i decided it wasnt worth packing an extra DWORD's into the heap structure (as i would need to create pens, store them, and back up the DC's frist pen). All just so 9 pixels can be greyed when disabled.

And until now only you noticed it (which is no surprise ) :grin: .
( I will leave it for an excercise in the tut ) .


Thanx everyone else, glad it works well on your machines. I will probabaly start more 'complicated' controlls in the future. Custom edit is something i always wanted (I H*a*t*e using rich edit), but this will be a *very* big job to undertake.

Oh, one last question, I originally was going to focus on 'makeing' a control, but Mob sounds interested in GDI stuff. Do you all want some 'detailled' talk on GDI first? To be honest, i didnt use a whole lot of GDI work (only one brush and backbuffer was created ~ to save memory). But i can talk a bit more global if there are takers?

:alright:
NaN
Posted on 2002-04-24 14:48:53 by NaN
I would just brush over the GDI for this one, and focus more on the messaging, design and structure of an owner drawn control. Try to eliminate all the abiguities that you came across in existing documentation. Your other tuts are great - can't wait to read this one.
Posted on 2002-04-24 16:35:14 by bitRAKE
mh i wouldn't skip the gdi part... i mean gdi is the basis.
sure custom controls are cool and all that stuff but i think
it's more something you code for yourself... i definitively
would NOT use a control coded by someone else. and
yes, you could exemplify the basics of creating a custom
control and without question, it would be very good
but i think it would be useless for gdi-newbies... i for
myself wanted to learn all this stuff a while ago but i
realized that there's *nothing* except a load of sources.
a full-lenght gdi tut would be a enrichment for every
asm-programmer who want to get behind this stuff
without stumbling through million lines of uncommented
code.

BTW: i saw very interesting programs written by E?in,
thomas, testdepartment and many many more, if you
just add the elementary things of those applications
plus a little introduction (what's a dc/...) you already
have the gdi part in your hands.
Posted on 2002-04-24 17:15:16 by mob
NaN, another feature might be to allow the user to close the menu by clicking again on the arrow - like the Back button in IE.
Posted on 2002-04-24 18:46:20 by bitRAKE
Well im about 1/3 done. Im getting a we bit tired of word processing so im putting it down for today :)

One of the reasons i wanted to write it up as a tutorial is so i can find a reason to learn how to make the .chm's. Took me half the afternoon to get it going right, but its looking pretty good now.

Its starting to look like it wont be geared towards GDI, but more towards the design, and related practices.

However, i might make an 'appendix' topic on GDI and the various 'standard' aspects that relates to it like pens/brushes/DC's etc.


BitRake, thanx for the suggestion but I dont think i will implement it as it will add another degree of complexity in the mouse capturing. The fact it does this is because the up-click that presents the menu, also resets the capture. So clicking off the menu kills the menu (as it is designed) and at the same time starts another 'event' from the start.

The only solution i can think of is having the menu no longer send back to the parent, but to the control, where it then forwards back to the parent. By seing menu events (or the lack of an event) with state information and capture events, you can determine if the user clicked off the menu and back on the button. In this case just do nothing as you want.

:alright:
NaN
Posted on 2002-04-25 02:52:40 by NaN