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).
From the programmer's point of view, a button is created, and after someinterval, destroyed. Perhaps this is managed automatically by a dialog box that the button appears in, but the construction and destruction happens regardless, and the button persists over some number of iterations of the event loop. The button can be located pretty much anywhere within some bounding area (such as a window).
A menu, on the other hand, is transient, unless we're considering NeXTstep or window managers that mimic it. But more importantly, the menu items are all in a column. Same horizontal position, same width, one below the other. Often, they are the same height. Typically, the system does mouse-over highlighting of the items, which it doesn't for buttons (except rarely -- IRIX does this).
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.
It very well may work, but that doesn't mean it's a good design. (Note that I'm not asserting it's not a good design; I'm merely raising the question.) You can implement pseudo-random access in terms of sequential access and it will work (for some values of "work"), but it won't scale.
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).
I'm afraid I don't follow what you're saying.
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.
Of course, the stack exporter only needs to run in HyperCard, but exported stacks may use the same idiom.
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
Oh, like the pseudo-random access example I gave above -- how coincidental! Does HyperCard really do that? You can optimize for this situation: Whenever the construct "repeat with i from 1 the number of <class>" occurs, iterate once over the available items (which you had to do anyway to count the instances of that class) and cache the ID numbers of those instances, for the duration of the repeat block. Then, "<class> i" becomes an ID lookup, and complexity is linear instead of quadratic.
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 repeat
I assume you meant:
put rot13 (card scrolling field i) into card scrolling field i
In HyperCard, you'd have to repeat over all card fields and selectively process them using if-then.
That 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 repeat
I agree that this is better code, because it doesn't rely on the parser being clever. However, existing HyperTalk code doesn't do this, since it's not supported, so I suggest making the parser clever.
This is effectively the iterator pattern in Java:
In Perl, 'foreach' does the same thing.
If a Java programmer were to implement that in the HyperCard way: he'd be shot and rightfully so
That sounds a little excessive to me. Perhaps a different treatment is called for here... :-) <http://www.c2.com/cgi/wiki?ParkingLotTherapy>
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.
A different optimization: When "the number of <class>" occurs in the context "repeat with i from 1 to the number of <class>", don't actually count them. Instead, internally iterate over every item, and if the class of the item matches, execute the block, resolving "<class> i" to the current item, and increment i. If i is not used other than as a subscript (e.g. for output), then you don't even need to have it at all.
Thanks for the input Josh, I'll have a think about the best way to handle this.
You're welcome. It's my pleasure to contribute.
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
