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're not as different as you think actually. The visual representation is different but the function and behavior is nearly identical. When it comes down to it, a button is an area on screen which is capable of "firing" either when the user clicks within that area or through some equivalent keyboard action (eg: pressing space bar) while the button has the focus. The second part may or may not apply depending on the OS and the specific configuration (it doesn't ever apply to OS 9, always applies to Windows and may or may not apply to OS X).
Now, what part of that does a menu item not fit? Ah, I just noticed the use of the word "menu" instead of "menu item", the same case still applies to a large degree (a menu it really just a specialized menu item, which is just a specialized button - think submenus to make this distinction clearer) but you're right on Mac OS a menu does appear as quite substantially different, however I can assure you that implementing it as a button type does work.
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".
That's a slightly different case. In the original case, I was referring to a particular item on the card and adding a descriptor before it, eg:
get the contents of cd fld 1
In your case, you are counting the number of items on the current card which match the description "button". This would still be possible in FreeCard as each item knows whether or not it matches the description "button" (or any other description).
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.
This is a good point and something I will have to consider. The real problem being the inherent slowness of continually counting your way through the list of card fields to get to "i" - something that HyperCard is well known to suffer from. The difficulty is that there is no longer 1 type of field (nor should there ever have been). Imagine the extra functionality you'd have if you could skip the label fields in your stack while rot13'ing them. eg:
repeat with i from 1 to the number of card scrolling fields
put rot13 (card field i) into card field i
end repeatThat way only the scrolling fields would be encrypted. Alternately, an even better syntax (both because it's simpler and because it's faster) would be the way a MetaCard programmer should approach this (excuse the incorrect syntax):
repeat with each scrolling field theFIeld in this card
put rot13 (theField) into theField
end repeatThis is effectively the iterator pattern in Java:
for (Iterator i = cardFields.iterator(); i.hasNext(); ) {
Field theField = i.next();
theField.setText(rot13(theField.getText()));
}If a Java programmer were to implement that in the HyperCard way:
for (int i = 0; i < cardFields.size(); i++) {
Field theField = cardFields.get(i);
theFields.setText(rot13(theField.getText()));
}he'd be shot and rightfully so because this is very likely to be a performance bottle neck if there are a significant number of fields and the storage format of cardFields is not an array (ie: it's a linked list to improve the speed at which new fields can be created, or because there may be a lot of fields and some should be stored on disk until required).
Definitely something to think about here though. We need to have a simple and efficient way of iterating over specific types of items rather than just all the items, however numbering each item type independently is too restrictive because it prevents you from having custom types (eg: a progress bar type, quicktime movie type etc). Clearly the most efficient option is to avoid counting the items whenever possible (ie: whenever the data you're trying to extract is the number of items), since it is quite efficient to iterate over the items and just skip any that don't match the criteria, but being able to count them either requires the count to be stored somewhere or for all of the items to be iterated over and counted.
Josh
Thanks for the input Josh, I'll have a think about the best way to handle this.
Regards,
Adrian Sutton. ---------------------------------------------- Intencha "tomorrow's technology today" Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com
------------------------------------------------------- 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
