hypercard domenu comptability

[Eric Engle]

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