Re: doMenu

[Bob Sneidar via use-livecode]

Tore even. 

> On Jul 10, 2018, at 07:46 , Bob Sneidar via use-livecode 
>  wrote:
> 
> I agree Tor. 


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: doMenu

[Bob Sneidar via use-livecode]

What do the open and closing double angle brackets do?

For nested menus, in a custom File menu script:

case "New|Stack"

Bob S


> On Jul 10, 2018, at 03:50 , Tore Nilsen via use-livecode 
>  wrote:
> 
>case «Make new graphic»

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: doMenu

[Bob Sneidar via use-livecode]

I agree Tor. The problem with doMenu is, what happens when you want to create 
your own menu group? None of the doMenu calls to the standard menus will work 
anymore. 

Bob S


> On Jul 10, 2018, at 02:07 , Tore Nilsen via use-livecode 
>  wrote:
> 
> I cannot answer your question about the sending of doMenu to items in a 
> hierarchy, but this seems to me to be a situation where you would be better 
> off placing the actual handler for what you would like to do in the stack 
> script. Then all it takes is a call to this handler, be it from the menu item 
> or from somewhere else. This way you do not need to send a doMenu command at 
> all. This is how I teach my students to structure their code.
> 
> Regards
> Tore Nilsen


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: doMenu

[dunbarxx via use-livecode]

Hi.

I would go to the forums and read this all the way to the end:

doMenu not finding the menu
<http://forums.livecode.com/viewtopic.php?f=7=30802=domenu#p165533>  

Craig Newman



--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: doMenu

[Tore Nilsen via use-livecode]

If you are writing all of the code yourself, then it should not be a problem 
knowing what the handler sparked by the menu item should do.Here is how I teach 
my students to structure their code when they want the user to be able to 
perform the same action from various controls:

In the stack script:

on makeNewGraphic
  set the style of the templateGraphic to polygon
  create graphic "zzz"
  set the points of grc «zzz" to fld "PTZ"
end makeNewGraphic


Script in the button:

on mouseUp
makeNewGraphic
end mouseUp


Script in the menu:

on menuPick pItem
  switch pItem
case «Make new graphic»
makeNewGraphic
break
default  #or other cases
Do something else
break
end menuPick

This way you only need to know what you would like the button or the menu item 
to do, and call the appropriate handler for this.

Regards
Tore


> 10. jul. 2018 kl. 12:32 skrev Richmond Mathewson via use-livecode 
> :
> 
> Thanks Tore,
> 
> This is alright if one knows what the actual handler sparked by the menu item 
> is.
> 
> on mouseUp
>   set the style of the templateGraphic to polygon
>   create graphic "zzz"
>   set the points of grc "zzz" to fld "PTZ"
> end mouseUp
> 
> Richmond.
> 
> On 10/7/2018 12:07 pm, Tore Nilsen via use-livecode wrote:
>>> 10. jul. 2018 kl. 10:43 skrev Richmond via use-livecode 
>>> :
>>> 
>>> Is it possible to send a *doMenu* command to a menu item several levels 
>>> down?
>>> 
>>> Such as *Object/New Control/Radio Button* ?
>>> 
>>> Richmond.
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> I cannot answer your question about the sending of doMenu to items in a 
>> hierarchy, but this seems to me to be a situation where you would be better 
>> off placing the actual handler for what you would like to do in the stack 
>> script. Then all it takes is a call to this handler, be it from the menu 
>> item or from somewhere else. This way you do not need to send a doMenu 
>> command at all. This is how I teach my students to structure their code.
>> 
>> Regards
>> Tore Nilsen
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: doMenu

[Richmond Mathewson via use-livecode]

Thanks Tore,

This is alright if one knows what the actual handler sparked by the menu 
item is.


on mouseUp
   set the style of the templateGraphic to polygon
   create graphic "zzz"
   set the points of grc "zzz" to fld "PTZ"
end mouseUp

Richmond.

On 10/7/2018 12:07 pm, Tore Nilsen via use-livecode wrote:

10. jul. 2018 kl. 10:43 skrev Richmond via use-livecode 
:

Is it possible to send a *doMenu* command to a menu item several levels down?

Such as *Object/New Control/Radio Button* ?

Richmond.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

I cannot answer your question about the sending of doMenu to items in a 
hierarchy, but this seems to me to be a situation where you would be better off 
placing the actual handler for what you would like to do in the stack script. 
Then all it takes is a call to this handler, be it from the menu item or from 
somewhere else. This way you do not need to send a doMenu command at all. This 
is how I teach my students to structure their code.

Regards
Tore Nilsen
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: doMenu

[Tore Nilsen via use-livecode]

> 10. jul. 2018 kl. 10:43 skrev Richmond via use-livecode 
> :
> 
> Is it possible to send a *doMenu* command to a menu item several levels down?
> 
> Such as *Object/New Control/Radio Button* ?
> 
> Richmond.
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

I cannot answer your question about the sending of doMenu to items in a 
hierarchy, but this seems to me to be a situation where you would be better off 
placing the actual handler for what you would like to do in the stack script. 
Then all it takes is a call to this handler, be it from the menu item or from 
somewhere else. This way you do not need to send a doMenu command at all. This 
is how I teach my students to structure their code.

Regards
Tore Nilsen
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

doMenu

[Richmond via use-livecode]

Is it possible to send a *doMenu* command to a menu item several levels 
down?


Such as *Object/New Control/Radio Button* ?

Richmond.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: DoMenu not working right?

[Bob Sneidar via use-livecode]

In fact, it seems I can also select which tab I want hilited like so:

open stack "revPropertyInspector 1"
dispatch "menuPick" to stack "revPropertyInspector 1" with "Position" -- or 
whatever the name of the tab is

I am working on a contextual app builder, and this will come in handy. 

Bob S


> On Dec 27, 2017, at 14:20 , Bob Sneidar  wrote:
> 
> Ah! I didn't read that far. I don't think menuPick will work, unless the 
> Livecode default menu is actually an IDE menubar. It's not really important 
> now, I just ran into it whilst trying to use the message box to get the 
> properties of the selected object without having to manually pop a menu. 
> 
> I suppose I could just find out what the name of the Object Inspector stack 
> is and open it. :-)
> 
> Bob S


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: DoMenu not working right?

[Bob Sneidar via use-livecode]

Ah! I didn't read that far. I don't think menuPick will work, unless the 
Livecode default menu is actually an IDE menubar. It's not really important 
now, I just ran into it whilst trying to use the message box to get the 
properties of the selected object without having to manually pop a menu. 

I suppose I could just find out what the name of the Object Inspector stack is 
and open it. :-)

Bob S



> On Dec 27, 2017, at 14:03 , Richard Gaskin via use-livecode 
> <use-livecode@lists.runrev.com> wrote:
> 
> Bob Sneidar wrote:
> 
> > Dictionary states: doMenu menuItem [of menu menuName]. I state: select
> > button "Development";domenu "Object Inspector" of menu "Object". I
> > get:
> > Message execution error:
> >
> > Error description: Handler: can't find handler
> >
> > Hint: of
> >
> > ?
> 
> The Dictionary also states:
> 
>   The doMenu command is not implemented for all menu items.
>   This command is included in LiveCode for compatibility
>   with imported HyperCard stacks.
> 
> 
> When I need to trigger a menu item I dispatch a menuPick message to the menu 
> button with the appropriate string.
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: DoMenu not working right?

[Richard Gaskin via use-livecode]

Bob Sneidar wrote:

> Dictionary states: doMenu menuItem [of menu menuName]. I state: select
> button "Development";domenu "Object Inspector" of menu "Object". I
> get:
> Message execution error:
>
> Error description: Handler: can't find handler
>
> Hint: of
>
> ?

The Dictionary also states:

   The doMenu command is not implemented for all menu items.
   This command is included in LiveCode for compatibility
   with imported HyperCard stacks.


When I need to trigger a menu item I dispatch a menuPick message to the 
menu button with the appropriate string.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

DoMenu not working right?

[Bob Sneidar via use-livecode]

Dictionary states: doMenu menuItem [of menu menuName]. I state: select button 
"Development";domenu "Object Inspector" of menu "Object". I get: 
Message execution error:

Error description: Handler: can't find handler

Hint: of

?

Bob S
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: DoMenu

[Alain Farmer]

Hello Richard,I disagree with your conclusion that DoMenu was necessary in 
HyperCard because that language wasn't rich enough to build an entire IDE 
in.DoMenu was an integral part of HyperCard's ease-of learning-to-program.One 
command (doMenu) versus many commands to learn/use/remember.Part of this 
paradigm: you can literally script something as-you-would-do-it-as-a-user.For 
power-users, you could intercept  handle doMenu, add-to-it-then-pass or even 
re-define it.For what it's worth,Alain


On Dec 8, 2014, at 1:13 PM, Richard Gaskin ambassa...@fourthworld.com wrote:

 William Prothero wrote:
 
 I got no response from the doMenu command, so perhaps I needed
 to include the shortcut key in the name?
 
 DoMenu is pretty limited in LiveCode.  It was necessary in HyperCard because 
 that language wasn't rich enough to build an entire IDE in, so the only way 
 you could invoke some of the IDE features was through doMenu as a sort of 
 catch-all.
 
 In LiveCode of course the IDE is make in its own language, so anything you 
 see in the IDE can be done more directly in your own stacks than having to 
 rely on a generic catch-all.
 
 If you do need to trigger an IDE menu item, you can dispatch a menuPick 
 handler to the relevant menu button in revMenubar with the name of the menu 
 item as its param.
 
 But quit is very essential - every app needs it - so that's built right into 
 the language with the quit command.
 
 If you need to do any processing before the app actually quits, you can trap 
 the shutdownRequest message.
 
 -- 
 Richard Gaskin
 Fourth World Systems
 LiveCode training and consulting: http://www.fourthworld.com
 Webzine for LiveCode developers: http://www.LiveCodeJournal.com
 Follow me on Twitter: http://twitter.com/FourthWorldSys
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your subscription 
 preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

  
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: DoMenu

[Richard Gaskin]

Alain Farmer wrote:

 Hello Richard,I disagree with your conclusion that DoMenu was
 necessary in HyperCard because that language wasn't rich enough
 to build an entire IDE in.

Did Apple ever release a version of HC with its IDE written in HyperTalk?


 DoMenu was an integral part of HyperCard's ease-of learning-
 to-program.One command (doMenu) versus many commands to learn/use
 /remember.

I suppose it could be a matter of taste, whether one writes scripts that 
invoke menu items that invoke commands or writes scripts that invoke the 
commands directly.


Personally, quit seems simpler and more intuitive to me than domenu 
quit.


Reliance on doMenu as a language design element also introduces 
inconsistencies:  what happens when you make your own custom menus and 
still need access to a command normally handled by doMenu?


Even if HC allowed that, it would seem odd (at least to me) to have to 
invoke a menu that doesn't exist.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: DoMenu

[dunbarx]

Richard.


...Reliance on doMenu as a language design element also introduces 
inconsistencies:  what happens when you make your own custom menus and still 
need access to a command normally handled by doMenu?...


I understand the exigencies of cross platform support. That said, I miss most 
of all the menu handling in HC, as opposed to the button group in LC.


The creation of a custom menu with associated menuMessages was clean and clear, 
and those menuMessages could be invoked via doMenu, but did not require it. 
The menuMessage handler references were loaded upon menu creation, accessible 
like ordinary handlers with a simple call.


But you know all this. I am obviously misunderstanding your statement above. 


Craig



-Original Message-
From: Richard Gaskin ambassa...@fourthworld.com
To: use-livecode use-livecode@lists.runrev.com
Sent: Mon, Dec 8, 2014 6:11 pm
Subject: Re: DoMenu


Alain Farmer wrote:

  Hello Richard,I disagree with your conclusion that DoMenu was
  necessary in HyperCard because that language wasn't rich enough
  to build an entire IDE in.

Did Apple ever release a version of HC with its IDE written in HyperTalk?


  DoMenu was an integral part of HyperCard's ease-of learning-
  to-program.One command (doMenu) versus many commands to learn/use
  /remember.

I suppose it could be a matter of taste, whether one writes scripts that 
invoke menu items that invoke commands or writes scripts that invoke the 
commands directly.

Personally, quit seems simpler and more intuitive to me than domenu 
quit.

Reliance on doMenu as a language design element also introduces 
inconsistencies:  what happens when you make your own custom menus and 
still need access to a command normally handled by doMenu?

Even if HC allowed that, it would seem odd (at least to me) to have to 
invoke a menu that doesn't exist.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  
  ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

 

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: DoMenu

[Richard Gaskin]

dunbarx wrote:

 I understand the exigencies of cross platform support. That said,
 I miss most of all the menu handling in HC, as opposed to the button
 group in LC.

 The creation of a custom menu with associated menuMessages was clean
 and clear, and those menuMessages could be invoked via doMenu, but
 did not require it. The menuMessage handler references were loaded
 upon menu creation, accessible like ordinary handlers with a simple
 call.

The xTalk world has seen at least three methods for handling menus:

HyperCard:  text only, created entirely in scripts

SuperCard:  objects for both menus and items, created in the IDE
or via scripts

LiveCode:   objects for menus, items are text, created in the IDE
or via scripts


Creation

HyperCard came with one set of menus, so if there was a menu you didn't 
want in your app you had to explicitly remove it, and then add any you 
did want.  All of this had to be done in scripts, as menus weren't 
persistent objects.


SuperCard uses persistent objects for both menus and menu items, so you 
can create them once using the UI provided in the IDE and be done with 
it.  In the olden days these were sometimes slow if you had to do a lot 
of updating, but I'd guess on modern machines there's no noticeable 
slowdown with those today.


LiveCode is sort of in the middle, with persistent objects for menus, 
which contain the strings that define menu items.  But unlike SuperCard, 
you can populate an entire menu with one chunk expression, and unlike 
HyperCard you don't need to write scripts to populate items.



Updates
---
In addition to creating items, the other common task we face is updating 
them so that specific items are disabled or enabled appropriate to the 
current context state.


All three xTalk dialects provide ways to handle that, but the main 
difference is triggering:  when exactly do you handle that updating?


In HC and SC you had to keep track of state changes that might affect 
menu disabling throughout your code, modifying menus on the fly as 
actions are performed.


In LC you can just write your code to focus on the action it performs, 
and respond to a single mouseDown event in the menu group to handle menu 
updates discretely.


This seems like a small detail, and perhaps it is, but it's saved me 
many hours of tracking down update stuff to make sure the menus always 
reflect the appropriate state at the moment they're accessed.



Messaging
-
HyperCard's menuMessage was indeed a godsend, something I missed with SC 
and for a long time with LC as well.  It let us assign a handler name to 
an item, so even if we change the item's name, or also call the routine 
from a context menu which may have a different name, it was easy to 
specify the handler that would be invoked.


In LC we don't have menuMessage, but we have something else which helps 
in many similar circumstance: items can have tags - e.g.:


  Quit/Q|QuitItem

The tag is the trailing portion following the pipe (|) - when present, 
that's the value that gets passed with the menuPick message.


With menu item tags we can change the name of an item (like Quit on 
Mac and Linux with Exit on Windows, or updating the Paste item to 
show things like Paste Text or Paste Objects, etc.), and we need to 
write only one case statement to handle any of those variants.


While not quite as convenient as HC's menuMessage, it still lets us use 
centralized code to handle a wide range of menu commands, whether in the 
menu bar or a context menu, by using a single menuPick handler.



All in all, the middle-ground approach LC takes between fully textual 
menus (that have no persistence) and fully object menus (that are 
sometimes slower and less convenient to work with) strikes a balance 
that makes me a happy xTalker.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode