Re: menu buttons and showname

Agreed. Which brings me back to the point that when the label of a popup menu is empty there ought to be some default behavior like displaying the tootTip or a property containing a value the developer can set. I think we are all agreed that what it ought NOT to do is display the object name. Wo

Re: menu buttons and showname

Hi Bob: I would propose that empty is not an informative value for a user. Something like "" or a call to action "Select an option" is going to be more helpful than an empty line. Regards, Scott Rossi Creative Director Tactile Media, UX/UI Design On 7/6/15, 12:55 PM, "Bob Sneidar" wrote: >

Re: menu buttons and showname

There are all kinds of workarounds for this. What is being discussed is why we need workarounds in the first place. Bob S > On Jul 3, 2015, at 05:25 , David Epstein wrote: > > “Set the label of button myBtn to space” makes an option button appear blank > but does not interfere with a user’s

Re: menu buttons and showname

New copier device. Popup menu of manufacturers. I want user to explicitly pick a manufacturer, not just ignore the manufacturer that is there. I set it to empty and then check for empty before saving the data. Bob S On Jul 2, 2015, at 20:07 , Kay C Lan mailto:lan.kc.macm...@gmail.com>> wrote:

Re: menu buttons and showname

“Set the label of button myBtn to space” makes an option button appear blank but does not interfere with a user’s subsequent choice of an option. While disabling the button or hiding the button are other ways of making clear that no option is in effect, an able but blank option button means that

Re: menu buttons and showname

I still can't invisage a situation where you'd want an empty option button. If in Peter's example the first btn was a list of customers, and the second button was a list of their invoices, if a customer has no invoices their name shouldn't appear in the first button. If on the the other hand the

Re: menu buttons and showname

Because if you don’t set the label to empty, then the name of the control is displayed as the default choice. It looks like crap, and irritated me, so as a quick fix, I set mine to empty as well. There are times when there is no default choice, that any choice is as viable as the rest. Bob S

Re: menu buttons and showname

What might be handy is some kind of “useTooltipIfEmpty” property. Then the end user would not need to parse the text to eliminate the “call to action” from the real data before working with it, t hen adding the “call to action” back when done. Bob S > On Jul 2, 2015, at 08:28 , Richard Gaski

Re: menu buttons and showname

Don't think you're missing anything. The example of table/column menus doesn't illustrate the original question I had since it's pretty much impossible to have a db without tables or a table without column. Maybe a better example of the empty menu might be one menu with a list of customers and a

Re: menu buttons and showname

As far as there being a "correct type of control", that's open to endless debate. :-) >From what you describe, there doesn't seem to be a need for a call to action -- this was suggested simply to address the case that a selection MUST be made for things to work. Since this doesn't seem to be rele

Re: menu buttons and showname

Interesting observation Scott. Makes me wonder if I'm actually using the correct type of menu. For example, I might have an option menu which lists the names of tables in a database and another one that lists the columns in the selected table. There's no "call to action" in that situation (other

Re: menu buttons and showname

Scott Rossi wrote: > Often, this type of control has a call to action such as "Choose an > item", as opposed an indication "No selection". It depends on the > context of your control. It does, and I wish more Web designers understood that. ;) This became popular with form designers where they

Re: menu buttons and showname

Often, this type of control has a call to action such as "Choose an item", as opposed an indication "No selection". It depends on the context of your control. If a selection is required in your set up, the call to action is more communicative. Otherwise, if "No selection" is a valid selection the

Re: menu buttons and showname

Good point. For lots of reasons, the names of my option menus aren't suitable for display to a user. Maybe the cleanest thing to do then is, if the text of the menu is empty, set its label as suggested by Richard. I like that. Most of the menus in question are under the control of a behavior so thi

Re: menu buttons and showname

Peter Haworth wrote: So my technique of setting showname to false if the text is empty is the only way round this? Also, you can have a label for an option menu with empty text. Try setting the text of an option menu to empty, then use the message box to set its label to some value. With the

Re: menu buttons and showname

Yep, that's one of the things I've done. On Thu, Jul 2, 2015, 7:54 AM Randy Hengst wrote: > Have you tried adding a blank line to the list of options? I’ve done it > that way before… then just set the menuHistory of that option button to the > line that is blank. > > be well, > randy > > Randy H

Re: menu buttons and showname

Have you tried adding a blank line to the list of options? I’ve done it that way before… then just set the menuHistory of that option button to the line that is blank. be well, randy Randy Hengst www.classroomFocusedSoftware.com > On Jul 2, 2015, at 9:46 AM, Peter Haworth wrote: > > No, I s

Re: menu buttons and showname

So my technique of setting showname to false if the text is empty is the only way round this? Also, you can have a label for an option menu with empty text. Try setting the text of an option menu to empty, then use the message box to set its label to some value. On Wed, Jul 1, 2015, 11:18 PM J. L

Re: menu buttons and showname

No, I simply want an option menu with empty text display an empty label, not its name property. As mentioned in the original post, I do that now by setting showname to false if the text is empty. On Wed, Jul 1, 2015, 11:29 PM Kay C Lan wrote: > Peter, > > I agree with the other here that the beh

Re: menu buttons and showname

Peter, I agree with the other here that the behaviour is as I'd expect and works the way I want it to. Can you better explain what it is you are after? Is it you have a button named "Make a Choice" and it's dynamically filled with 0 to umpteen choices, but regardless of whats in there, OR what a

Re: menu buttons and showname

On 7/1/2015 8:52 PM, Peter Haworth wrote: The showName property needs to be true for the the user's selected choice from, for example, an option menu to be displayed. First problem - that's the label not the name. But if the text of the menu happens to be empty, its name is displayed instead of

Re: menu buttons and showname

This happens when the complete text of an option menu is empty, not when a line of the text is empty. On Wed, Jul 1, 2015, 8:23 PM wrote: > > I am misunderstanding. In an option menu, if I have, say, the second line > of the text of the button as empty, I get empty in the selected choice. > Thi

Re: menu buttons and showname

I am misunderstanding. In an option menu, if I have, say, the second line of the text of the button as empty, I get empty in the selected choice. This has nothing to do with the name of the button itself, which does not show itself, nor the state of the show name. This is the behavior of an

Re: Menu Buttons and the text property

Yes, but that part of the script already works. I have no problem deleting all of the text in the combo box, as I have a special case to account for that. Bob S > On Feb 13, 2015, at 17:17 , Randy Hengst wrote: > > I'm not at my computer so this idea might just be worthless. Can the first >

Re: Menu Buttons and the text property

I'm not at my computer so this idea might just be worthless. Can the first line of your industry list be empty and when you trap for delete go to line 1? > On Feb 13, 2015, at 6:43 PM, Bob Sneidar wrote: > > Thanks for the reply. Let me explain what I am trying to accomplish. > > I have a com

Re: Menu Buttons and the text property

Thanks for the reply. Let me explain what I am trying to accomplish. I have a combo box with a property containing a list of Industry Names. Things like Retail Services, Auto Repair and such. As the user types, I want to autofill the text with the first choice in that list that matches what the

Re: Menu Buttons and the text property

Sounds like menuHistory might be helpful. > On Feb 13, 2015, at 5:37 PM, Bob Sneidar wrote: > > Hi all. > > If I set the text of a Combo Menu to a return delimited list, not only does > it change the menu options (as it should) but it also sets the Label to the > first line of the menu opti

Re: Menu Buttons and the text property

Trying to come up with a workaround. Turns out that in a combo box the selectedChunk does NOT return the insertion point. Instead it returns the description of the first line of the text of it. For example, I have 5 characters in the combo box, the insertion point is at the end of that text. I

Re: Menu Buttons

Sure, I understand I can check things in menuPick. I guess it comes down to what's the behavior that works most of the time for most people, making that the default, and providing a way to get round the default if it's not what you want. In this very personal sample of one (me), I have yet to co

Re: Menu Buttons

Pete- Wednesday, May 11, 2011, 3:26:28 PM, you wrote: > Of course, I'm definitely biased because I'm relying on the current behavior > of menuHistory in some of my code. OTOH, it's easy to check for the current value in the menuPick handler and exit if it's the same. The reason for bug #9301 i

Re: Menu Buttons

To play the bad guy's advocate, why then does it work differently when you select the same thing in an option menu? The *bug* is that the two methods produce different results. But we are straining at gnats here. Bob On May 11, 2011, at 3:26 PM, Pete wrote: > Hi Mark, > Thanks for the update

Re: Menu Buttons

Hi Mark, Thanks for the update. I guess it depends on the definition of a bug but to be honest, I think the way this works currently is what I'd expect - no menuPick because nothing new got picked. If processing is needed even though nothing changed, you can send a menuPick message, that way there

Re: Menu Buttons

Ahah! Good shew Sherlock! Bob On May 11, 2011, at 2:49 PM, Mark Wieder wrote: > Pete- > > Wednesday, May 11, 2011, 9:44:31 AM, you wrote: > >> That's strange because that's not what I'm seeing - no wonder there's >> confusion! Here's what I did to test. > >> Put an option menu on a card wi

Re: Menu Buttons

Bob- Wednesday, May 11, 2011, 8:30:33 AM, you wrote: > I checked this yesterday with 4.6.1. If I issue menuhistory from > the message window to a button with the current choice. menupick > does NOT get sent. I know this because I put a breakpoint at the > start of the menupick handler in that but

Re: Menu Buttons

Pete- Wednesday, May 11, 2011, 9:44:31 AM, you wrote: > That's strange because that's not what I'm seeing - no wonder there's > confusion! Here's what I did to test. > Put an option menu on a card with the default choices. I just reopened bug #9301. It's fixed for pulldown and popup menu butto

Re: Menu Buttons

Yep, I do the same thing, it prevents needless database updating when the value hasn't changed. Just trying to figure out why you and I see the behavior where setting the menuHistory to its existing values does not trigger menuPick but it does for Mark. Pete Molly's Revenge

Re: Menu Buttons

Well what I do, as I said in a previous post, is I save the last successful choice in a property in the menu. Next time around I get the current selection and compare it to the last choice. If it's the same I exit menuPick. If it's not, then I process the handler, update the property, and pass m

Re: Menu Buttons

That's strange because that's not what I'm seeing - no wonder there's confusion! Here's what I did to test. Put an option menu on a card with the default choices. Put a menuPick handler on the option menu: on menuPIck pitemname answer information pitemname end menuPick Put a button on the

Re: Menu Buttons

Thanks for the input and suggestions, but the set menuhistory .. strategy works to accomplish the task. To deal with the problem of once set-never forget, I set the value to 99 with a second set menuhistory line in my list and had my handler do nothing with the choice was blank. So,

Re: Menu Buttons

I checked this yesterday with 4.6.1. If I issue menuhistory from the message window to a button with the current choice. menupick does NOT get sent. I know this because I put a breakpoint at the start of the menupick handler in that button and nothing happened. However, if I physically select th

Re: Menu Buttons

Pete- Tuesday, May 10, 2011, 8:40:34 PM, you wrote: > Hmmm, well I just tried it and got no menuPick when I set the menuHistory to > its existing value (running 4.6.0.) Here's the issue: setting the menuHistory of menu buttons would work, but *only* if a new value was being set (not the same as

Re: Menu Buttons

Hmmm, well I just tried it and got no menuPick when I set the menuHistory to its existing value (running 4.6.0.) I read the text of the bug report and it's a little confusing about what actually got fixed or even if anything did. My reply was strictly to do with option menus but the bug report se

Re: Menu Buttons

Pete- Tuesday, May 10, 2011, 11:15:38 AM, you wrote: > I think it's also worth commenting on setting the menuHistory to solve this > problem. If a handler sets the menuHistory to it's existing value, no > menuPick message is generated. I can't tell if that's significant to this > problem but go

Re: Menu Buttons

I think that menuHistory behavior is what you'd want most of the time but just good to make people aware of it, just in case. And yes, selecting the current selection does trigger a menuPick so that's the way to do get around the menuHistory behavior if it matters. But then, as you pointed out, y

Re: Menu Buttons

Oh hey didn't know that. It is true however, that selecting the current menu selection DOES trigger a menupick, which is probably why I thought setting the menuhistory to what it already is did the same thing. Bob On May 10, 2011, at 11:15 AM, Pete wrote: > I think it's also worth commenting

Re: Menu Buttons

The original code examples didn't have the && between menuPick and (line 3 of btn "Examples") - that was the real problem I saw, probably should have made that clearer. Personally, I've got into the habit of using dispatch rather than send whenever possible just because the syntax lends itself to

Re: Menu Buttons

On May 10, 2011, at 9:43 AM, Pete wrote: I might be wrong but I think the send commands, as you listed them, aren't correct - I believe the message and it's parameters have to be one string. So something like: send "menuPick aspirin" to button "Examples" or send "menuPick" && (line 3 of b

Re: Menu Buttons

or dispatch "menupick" to button "Examples" with "Aspirin" Bob On May 10, 2011, at 9:43 AM, Pete wrote: > I might be wrong but I think the send commands, as you listed them, aren't > correct - I believe the message and it's parameters have to be one string. > So something like: > > send "menu

Re: Menu Buttons

If it's a menu that can change programmatically (like a list of departments for example) then get the text of the field, get the lineoffset of what you are looking for, then set the menuhistory to that. For extra credit, save the last pick in a property, then check to see if the user selected

Re: Menu Buttons

I might be wrong but I think the send commands, as you listed them, aren't correct - I believe the message and it's parameters have to be one string. So something like: send "menuPick aspirin" to button "Examples" or send "menuPick" && (line 3 of btn "Examples") to btn "Examples" Pete Molly's

Re: Menu Buttons

Or try: select menuItem 1 of menu "File" -- Tom McGrath III http://lazyriver.on-rev.com 3mcgr...@comcast.net On May 9, 2011, at 10:05 PM, Mark Wieder wrote: > David- > > Monday, May 9, 2011, 2:18:41 PM, you wrote: > >> I've tried things like: > >> send menupick (line 3 of btn "Examples") to

Re: Menu Buttons

Bonjour David, Did you try : set the menuHistory of btn "examples" to 1 -- (or 2, 3, etc) Best regards from Grenoble André Le 9 mai 2011 à 23:18, David Brooks a écrit : > I DO exactly those sorts of things. But, when I send a menupick message, > nothing happens. > > I've tried things like

Re: Menu Buttons

David- Monday, May 9, 2011, 2:18:41 PM, you wrote: > I've tried things like: > send menupick (line 3 of btn "Examples") to btn "Examples" > and > send menupick aspirin to btn "Examples" Try setting the menuHistory of the button -- -Mark Wieder mwie...@ahsoftware.net

Re: Menu Buttons

I think you may need to structure the send statement differently: put "menupick" && line 3 of btn "Examples" into myCommand send myCommand to btn "Examples" send "menupick aspirin" to btn "Examples" Pete Molly's Revenge On Mon, May 9, 2011 at 2:18 PM, David Bro

Re: Menu Buttons

I DO exactly those sorts of things. But, when I send a menupick message, nothing happens. I've tried things like: send menupick (line 3 of btn "Examples") to btn "Examples" and send menupick aspirin to btn "Examples" However, I've never used the term "combo box" and it looks as if I have a

Re: Menu Buttons

When you say you want to drive the menuItems displayed by script, does that mean you never want to use the mouse at all? I made a workaround recently where I did something like this, and I am giving you a snippet for your examination. Make two buttons, one an ordinary one, and one a combo box. P