> And what happens if you have two buttons that
overlap
> each other and you click the one that is partially
> covered? Will it appear to "jump forward" then, like
a
> Macintosh control? Or will it just highlight the
parts
> that are visible, like a button in HyperCard?
Alain: Macintosh controls "jump forward" ?? Windows do
that - if you click on a window that is not in the
foreground, it will jump forward to the foreground and
become the active window. But controls??
> Good Question. I have investigate the problem, but
it
> seem that only the first option is handled.
> We obviously need the latter behaviour.
> No luck !
Alain: The hiliting of parts in HyperCard is the same
as the hiliting of Macintosh controls, aren't they??
Did HyperCard stray THAT far from Apple's Human
Interface Guidelines??
> Also, since we need to send messages when a button
> is clicked (mouseDown, mouseStillDown, mouseUp),
> it can be done i Think !
Alain: We will be supporting all of the events that
HyperCard 2.x supports, right? In this particular
case, we will thus support :
mouseDown
mouseStillDown
mouseUp
mouseDoubleClick
mouseEnter
mouseWithin
mouseLeave
> It'd be best if we could do the tracking of a button
> in FreeCard-specific code ...
Alain: Are you talking about : (a) FreeCard-specific
source code, written in C/C++, or (b) FreeCard script
language code (FreeScript) ?
> else whenever we add new messages we have to add the
> code to dispatch the messages to the current
object's
> script (to "send" a message to it) to *both* the
> Windows and the Mac code. It'd be best if we could
> just make the abstraction layer call a function both
> on Windows and on Mac and then we would have that
> function do the actual work.
Alain: Absolutely!
> And we have to be able to change a button's style to
> some custom style whenever its "style" property
> changes ...
Alain: set the style of <button> to <buttonStyle>
Alain : But the <buttonStyle> token will have to be
defined somewhere, in a structure that detects and/or
asks the user for the current/projected
platform/context in order to only offer the btnStyles
that are supported. But how do you switch custom
btnStyles when someone goes from one platform to
another? Unless, of course, each mac-btnStyle has a
corresponding win-btnStyle and linux-btnStyle. If
these corresponding btnStyles are not identical, then
FreeCard will look different on every platform. So
what's it going to be ? Same look and styles
irregardless of platform, or platform-specific
enhanced looks/styles that are quite distinct for each
platform?
> ... which is also a lot easier if we can just call
an
> abstraction-layer function and we don't have to add
> different code depending on which platform we
compile
> for.
Alain: Absolutely. Abstraction of implementation
details of each platform would undoubtedly be one of
the Ten Commandments of programming, if such a thing
existed. The only hitch is that universality usually
translates into designing for the
Lowest-Common-Denominator that is common to all of the
targeted platforms.
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
