At 07:39 pm 03/06/99 +0200, you wrote:
>>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".
Uli,
I understand that. We won't be using ActiveX or windows contros per se.
But our objects will have (user-defined) event-handlers won't they?
Dylan Just
[EMAIL PROTECTED]
