>I think that is more important than a 'button' per se. ActiveX controls
>could be used, but I'm pretty sure we lose some performance. The window's
>message maps could handle the click events and check (in z order) for items
>containing the clicked point. The window message-handler adjusts the point
>relative to the topleft of the object (button etc) and then trips it's
>handler.
Dylan,
this is the usual technique used for hit-testing inside objects on screen,
yes. But you have to stop thinking in terms of ActiveX and the likes. This
stuff will all done by our own code. Example:
When the stack window receives the click, it loops over its list of card
parts (=buttons & text fields) and checks whether the click coordinate was
inside the part's rect. If it was, it performs some additional tests to
ensure a strangely-shaped button like Oval or similar was really hit, if it
wasn't it goes on with the loop.
To draw the object, we'd use whatever we're offered. For Standard buttons,
we use the appropriate API calls to draw the object (this will often
require some fiddling as both the MacOS and Windows if I'm not mistaken
have no official way of drawing a control w/o creating one, if necessary
we'll create one and clip it to the OpenCard button's rect when drawing).
For our own button styles we simply draw it "by hand".
Cheers,
-- M. Uli Kusterer
------------------------------------------------------------
http://www.weblayout.com/witness
'The Witnesses of TeachText are everywhere...'
--- HELP SAVE HYPERCARD: ---
Details at: http://www.hyperactivesw.com/SaveHC.html
Sign: http://www.giguere.uqam.ca/petition/hcpetition.html