--On Saturday, July 26, 2003 6:34 PM +1000 Adrian Sutton <[EMAIL PROTECTED]> wrote:

In the same vein, and if we implement menus as buttons
like MC does, then I'd like us to derive a new "menu"
class from the "button" class, removing all the button
stuff that is not relevant to a menu, and adding all
of the menu stuff that isn't relevant to btns. This
removal of menu stuff also *simplifies* the button's
definition. IOW, a new 'menu' class and a simplified
'button' class.

As a Mac user (and developer), implementing a menu in terms of a button sounds weird to me. They're just different beasts, over here.


they would be different things rather than just
changing depending on the type attribute.

The only complication, as you point out below, is that it complicates matters when it comes to *referring* to these different parts as "buttons" or "fields". We might want to consider, though, extending our xTalk to include these new classes. Here are some examples:

set the content of label 1 to "Name:"
set the menuItems of menu "File" to myFileMenuItems

The reality is that in FreeCard the type of item is largely irrelevant. For instance:

set the content of <????> 1 to "Name:"

is perfectly unambiguous because there can only be one item of any type
either with ID 1, in Z-Axis position 1 (ie: card number).  In short,
there's no difference between:

set the content of label 1 to "Name:"
and
set the content of item 1 to "Name:"

both roughly evaluate to the Java code:

card.getItem(1).setProperty(new FCValue("content"), new FCValue("Name:"));

A slightly bigger problem is the HyperCard
syntax: "get card button 1"

get popup button 1 get push button 1 etc

This would be more keyword to learn
but that's not too big a big deal, is it?
It may not be an elegant solution though.
More reflexion needed.

I think we just design the compiler to ignore whatever you put there then you can call it what you like. If people want checks, the compiler could find the actual button being referred to and ask if it can be referred to by the specified name. There's no ambiguity because you can't have a button 1 and a field 1 on the same card since things are only given a part number.

This not how HyperCard works. In HC, every item in the stack has a unique ID. "get button id 12345" does an ID lookup. "the number of buttons" will return the sum of "the number of card buttons" and "the number of background buttons", and "card button 1" and "bkg button 1" will always be different items, assuming they both even exist, and one of them will be the same as "button 1".


This allows you to write things like:

repeat with i from 1 to the number of card fields
   put rot13(card field i) into card field i
end repeat

Incidentally, the HC stack exporter will need to iterate over items that way.

If everything is sharing the same index table, that code will break.

Josh




------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Freecard-general mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freecard-general

Reply via email to