Hi First, I must say: I don't just want a solution for me. I want a solution for anyone using revolution or metacard.
Second, I think it is reasonable to expect a solution. The question that raises is how to do the solution. Richard gives me the impression that there is in fact no way out. MetaCard does not let you override handler (or write self modifying code - and on these two points I prefer hypercard). The handlers for "doMenu" are there, just not implemented. Consequently, if I understand Richard correctly they cannot be overriden by card objects. Alain, I agree, I could easily modify my own stacks so that my own projects would be compatible on my own machine. You're missing the point: the issue is the compatability on all machines running any flavor of metacard/revolution. Also, Scott very much still owns metacard. He has licensed its engine to revolution in exchange for a GUI, nothing more or less. As far as I know they are two different companies with no overlapping directors or ownership of stock. Anyway, my point remains: this is an unimplemented feature. In the interest of compatability it should be implemented. It need not be implemented in a manner that either interferes with speed of other functions. However it must be implemented such that revolution/metacard can properly import hypercard stacks. Which means while it could be scripted using open source it would have to be implemented by MC/RR. Once upon a time metacard had no native bitmap art tools just vector tools and there was no art compatability. Now there is and most art stacks run fine under metacard. Currently many domenu items are not implemented. They could be. Mostly though my domenu commands return "no such menu". Which to me means that they could be implemented just by adding invisible menu items to the metacard menu bar. Richard is implying that that is not possible. And Alain thinks it is but is ignoring the fact that I'm not autistic. If I implement a change on my version of metacard that does nothing for the other people using metacard. I don't want a solution just for myself. I want a proper solution that benefits all users of xTalk machines. > one of the reasons MC is so darn fast is that it doesn't allow the > overriding of built-in commands and functions (it cuts the token search > space down dramatically). Fortunately, for the few cases where that > might be useful it isn't hard to work around it: That argument ignores the processor speed of machines is increasing and will continue to increase such that any speed gain is really not that important and will become less and less important. > For example, you could write a menuPick handler at the stack level and > move your doMenu stuff there. That way you could handle visible menu > items there and also makes calls to it from other scripts by writing: > > menuPick "Menu Item Name" > > ...rather than HC's: > > doMenu "Menu Item Name" Which is no solution for the easy import of hypercard stacks to metacard, you're missing my point. > Indeed. I have longed for doMenu in MC, many times, > for many years. So have I. > I had a in-depth debate about it with > Scott Raney, back when MC was still owned and hosted > by Scott. Still is. > He concluded with the argument that Richard > reiterated in a very-recent post to this list, e.g. > MC's speed is dramatically improved without "doMenu'. I rebut processor speed is increasing rapidly and point out the lack of compatability is extremely frustrating to people thinking of switching. This is an argument for supercard, isn't it... > There is nothing preventing you from editing MC's menu > bar. Yes, but that is no solution for everyone else. > > This is an avoidable and easily solved problem. > > the invisible button would not solve syntax > > like doMenu item 3 of menu 2 (or similar) but > > I never used that syntax ... > > Some of do use that syntax, and it was awesome in > terms of learning to script HyperCard gra-du-ally, by > coding exactly what the user normally does manually. Sure, and IDEALLY the metacard menu would ALSO reflect that: all menus and menu items of hypercard would be retained, with new menu items appended after the existing menu items or using entirely new menus in addition to the cloned hypercard menus. I would also point out I want a tear off tools palette. With art tools built in. A tear off pattern palette would be nice - including the hypercard patterns which are now available on metacard but not in the metacard pattern palette. > I have no comment to make on your "invisible menu" > idea but it seems to me that you could achieve your > goal by scripting a "doMenu" handler, in MetaCard, > which maps the doMenu requested with its corresponding > equivalent in MC code. Not according to Richard, unless I'm misreading him. > > Example: > > doMenu "New stack..." without dialog > > gets handled by : > > on doMenu menuItem > -- > -- setup a CASE statement, > -- one case for each menuItem possibility > -- > -- case where menuItem is the above > create new stack > break > -- > -- other cases where menuItem is other > -- > end doMenu > __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail _______________________________________________ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard