quick question... (show invisibles) [Solved]
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller
quick question... (show invisibles) [Solved]
Hi all,
is it possible to invoke the 'show invisible objects' menu item in script?
(basically i use this so much i thought it would be nice to assign it to a button in 4wDevo)
is it possible to invoke the 'show invisible objects' menu item in script?
(basically i use this so much i thought it would be nice to assign it to a button in 4wDevo)
Last edited by stam on Fri Jun 11, 2021 7:55 pm, edited 1 time in total.
-
- VIP Livecode Opensource Backer
- Posts: 9662
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: quick question...
Quick answer.
The old HC "doMenu" command, much to my dismay, is no longer much supported. Alas.
But you can:
If you do this elsewhere, know that every separator and submenu occupies a slot in the menuItem "count"
Craig
The old HC "doMenu" command, much to my dismay, is no longer much supported. Alas.
But you can:
Code: Select all
on mouseUp
select menuItem 20 of menu "view"
end mouseUp
Craig
-
- VIP Livecode Opensource Backer
- Posts: 9837
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: quick question...
Glad to hear you're enjoying devolution.
As you may find in devo's code, I prefer to call menu items by name rather than by number. Although either is subject to change, I find the order of things changes a little more often than a well thought out name,
As you may find in devo's code, I prefer to call menu items by name rather than by number. Although either is subject to change, I find the order of things changes a little more often than a well thought out name,
Code: Select all
dispatch "menupick" to btn "View" of stack "revMenubar" with "Show Invisible Objects"
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- VIP Livecode Opensource Backer
- Posts: 9662
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: quick question...
Richard.
So is "doMenu", which does not work if we, say:
but does work if we:
so weakened that it has no reliable value?
And why does the second work but not the first? How do the engine know? I know it is a holdover to help compatibility with older HC stacks, But how could a command be kept so long with no way, apart from testing it on a case by case basis, to know if it will work or not? It does not even throw an error when it fails.
I miss it so.
And it has funny things about it. The above command
works fine from msg, but not from a button. It actually makes a new card, but then throws an error. However,
works everywhere.
Craig
So is "doMenu", which does not work if we, say:
Code: Select all
doMenu "Show Invisible Objects" of menu "View"
Code: Select all
doMenu "New Card" of menu "Object"
And why does the second work but not the first? How do the engine know? I know it is a holdover to help compatibility with older HC stacks, But how could a command be kept so long with no way, apart from testing it on a case by case basis, to know if it will work or not? It does not even throw an error when it fails.
I miss it so.
And it has funny things about it. The above command
Code: Select all
doMenu "New Card" of menu "Object"
Code: Select all
doMenu "New Card"
Craig
Re: quick question...
Another way to do it is to set the showInvisibles property.
This is ultimately what the item in the View menu does.
Kind regards
Elanor
Code: Select all
set the showInvisibles to {true | false}
Kind regards
Elanor
Elanor Buchanan
Software Developer
LiveCode
Software Developer
LiveCode
Re: quick question...
Thanks for the 'quick answers' everyone
@Elanor - fantastic, that's exactly what i was looking for, thank you.
@Richard - thank you for Devo - am enjoying quite a bit; this and Bernd's bnGuides are standard plugins that i run all the time. Would really like to see these functionalities built into the IDE!
Thank you also for showing how to invoke menu items - much like you, i'd prefer to call by name rather than menu number, as probably less likely to change but more importantly makes code easier to maintain (but good to know i can do both- thanks Craig).
Thanks to Elanor's code it's easy to toggle invisibles: but i ran into a slight snag with Devo: the invisible group 'droppad' covers all controls, so of course when u show invisibles it makes the custom buttons inaccessible.
In the end i assigned the code to button 'Custom 4' and shortened the height of the 'droppad' group so that it only extends to cover button 'custom 3' that way btn 'custom 4' is not obscured when showing invisible objects - hope that doesn't break anything...
but also raises the question - what is the best use for the 'droppad' group?
@Elanor - fantastic, that's exactly what i was looking for, thank you.
@Richard - thank you for Devo - am enjoying quite a bit; this and Bernd's bnGuides are standard plugins that i run all the time. Would really like to see these functionalities built into the IDE!
Thank you also for showing how to invoke menu items - much like you, i'd prefer to call by name rather than menu number, as probably less likely to change but more importantly makes code easier to maintain (but good to know i can do both- thanks Craig).
Thanks to Elanor's code it's easy to toggle invisibles:
Code: Select all
set the showInvisibles to not the showInvisibles
In the end i assigned the code to button 'Custom 4' and shortened the height of the 'droppad' group so that it only extends to cover button 'custom 3' that way btn 'custom 4' is not obscured when showing invisible objects - hope that doesn't break anything...
but also raises the question - what is the best use for the 'droppad' group?
-
- VIP Livecode Opensource Backer
- Posts: 9837
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: quick question...
Thank you for the kind words.
Feedback like that helps me prioritize some new additions I have in the hopper.
I had hoped the IDE code would be smarter than the simplistic brute-force implementation in the engine.Thanks to Elanor's code it's easy to toggle invisibles:but i ran into a slight snag with Devo: the invisible group 'droppad' covers all controls, so of course when u show invisibles it makes the custom buttons inaccessible.Code: Select all
set the showInvisibles to not the showInvisibles
Sadly, I was optimistic. After tracing through the IDE's long series of nested calls for that menu item, I see that in the end it merely calls that line to toggle the built-in showInvisibles property. That property is truly global, and will affect all open stacks regardless of mode.
The tool property is smarter: it only affects toplevel stacks. That's appropriate for the largest range of use cases, and I would argue that the authoring workflows where showInvisibles is useful would benefit from the same approach.
Hiding and showing controls is pretty common in tools. I'm surprised this hasn't bitten anything in the IDE (perhaps it has, I haven't checked everything).
It's a vestigial element from an early experiment in handling the dropping of stack files onto the devo window. It can be removed, but there's a line of code that refers to it in the card script (only to ensure it's hidden), so that would need to be removed as well.In the end i assigned the code to button 'Custom 4' and shortened the height of the 'droppad' group so that it only extends to cover button 'custom 3' that way btn 'custom 4' is not obscured when showing invisible objects - hope that doesn't break anything...
but also raises the question - what is the best use for the 'droppad' group?
Better, I just removed the old "droppad" group, and changed the location of the popup menu control, so neither is now visible when showInvisibles is true. I've posted the new build so you can just update, most easily from the "Check for Updates" button in the devo About box.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: quick question...
Dear Richard - thank you! Updated and it works a treat!(very slick update process BTW)FourthWorld wrote: ↑Fri Jun 11, 2021 5:26 pmBetter, I just removed the old "droppad" group, and changed the location of the popup menu control, so neither is now visible when showInvisibles is true. I've posted the new build so you can just update, most easily from the "Check for Updates" button in the devo About box.
Given what a common task this is, would you consider adding an extra button for it? (using custom buttons is fine - just limits available buttons)
In any case thank you for providing this quality tool - it's very much appreciated...
-
- VIP Livecode Opensource Backer
- Posts: 9837
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: quick question...
Thank you for your support, Stam. Much appreciated, and very motivating to work through the feature request list.stam wrote: ↑Fri Jun 11, 2021 7:11 pmDear Richard - thank you! Updated and it works a treat!(very slick update process BTW)FourthWorld wrote: ↑Fri Jun 11, 2021 5:26 pmBetter, I just removed the old "droppad" group, and changed the location of the popup menu control, so neither is now visible when showInvisibles is true. I've posted the new build so you can just update, most easily from the "Check for Updates" button in the devo About box.
Given what a common task this is, would you consider adding an extra button for it? (using custom buttons is fine - just limits available buttons)
In any case thank you for providing this quality tool - it's very much appreciated...
I've considered a check on startup for updates, which would keep the UI free and be arguably simpler, since you'd never have to even think about it until an update is available.
If you like the idea I'll see if I can drop it in next week...
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: quick question...
yes absolutely - i'll be honest, i'd seen the 'check for updates' button before but completely forgot it was there until you mentioned it...FourthWorld wrote: ↑Fri Jun 11, 2021 7:20 pmIf you like the idea I'll see if I can drop it in next week...
-
- VIP Livecode Opensource Backer
- Posts: 9837
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: quick question...
It's easy to overlook. Next week is a busy one, but I'll try to squeeze some time in to automate the update check. Remembering things like that is a better task for a computer to do than to waste human mental energy on. Thanks for bringing this up. #motivatingstam wrote: ↑Fri Jun 11, 2021 7:30 pmyes absolutely - i'll be honest, i'd seen the 'check for updates' button before but completely forgot it was there until you mentioned it...FourthWorld wrote: ↑Fri Jun 11, 2021 7:20 pmIf you like the idea I'll see if I can drop it in next week...
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- VIP Livecode Opensource Backer
- Posts: 9837
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: quick question...
This reminds me of something I've been thinking about for a while:
It would be very helpful for myself and other devs to obtain a few details about user configs, specifically LC version, system version, and screen rects.
Those three things provide a LOT of useful guidance, and contain no personal information about the user.
A "Check for Updates" feature could easily send that info each time if grabs the update info, but even as innocuous as it is I'm always reluctant to send any data without explicit opt-in.
But if I make a checkbox for that opt-in in Prefs, the odds of anyone checking it are close to zero. So it's a lot of set up time to collate statistics that will produce no useful result.
Apps send lots of data, often things that can be to a user's disadvantage, and most folks don't think twice about it. If I sent those three system info items by default, would that be a concern? There would still be a checkbox to opt out, but it's pretty safe info and completely anonymous, and unless I get the info for a substantial number of users it's not useful to establishing trends.
I would of course also provide a summary of the stats for all developers, so anyone making plugins can get a good sense of the types of systems we need to design for.
Thoughts?
It would be very helpful for myself and other devs to obtain a few details about user configs, specifically LC version, system version, and screen rects.
Those three things provide a LOT of useful guidance, and contain no personal information about the user.
A "Check for Updates" feature could easily send that info each time if grabs the update info, but even as innocuous as it is I'm always reluctant to send any data without explicit opt-in.
But if I make a checkbox for that opt-in in Prefs, the odds of anyone checking it are close to zero. So it's a lot of set up time to collate statistics that will produce no useful result.
Apps send lots of data, often things that can be to a user's disadvantage, and most folks don't think twice about it. If I sent those three system info items by default, would that be a concern? There would still be a checkbox to opt out, but it's pretty safe info and completely anonymous, and unless I get the info for a substantial number of users it's not useful to establishing trends.
I would of course also provide a summary of the stats for all developers, so anyone making plugins can get a good sense of the types of systems we need to design for.
Thoughts?
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: quick question...
Personally i would have no issue at all with this - as you say, a cursory google search does worse...FourthWorld wrote: ↑Fri Jun 11, 2021 7:57 pmIt would be very helpful for myself and other devs to obtain a few details about user configs, specifically LC version, system version, and screen rects.
Those three things provide a LOT of useful guidance, and contain no personal information about the user.
Providing summary stats for devs will only be to everyone's benefit. As you intend to include an 'opt out' I can't really foresee any LC devs having any objections as long as performance isn't impacted (but that's just me), and would wholeheartedly support this...
Hope that helps,
Stam
Re: quick question... (show invisibles) [Solved]
You just knew some of these questions would draw me in I bet heh. Well, whether you want it or not (and if you don't, skip to the next post! No point in raising your blood pressure, and mine is already too high), here is my lunch monies worth
I don't use Google to do much of anything except 2 things, both of which I regret even starting, and I don't appreciate the way they feel free to siphon whatever data they feel like about people who do use their services without at least asking if they can. I have other problems with Google, but that is for another day
Of course, ultimately it is your creation, so go whatever way you choose, as I said, I just popped in to point out that not everyone would be all in for that combo. My votes really don't count for much, I'm rarely up to Rev v2 anymore, never mind a version Devo would run in, so am an unlikely candidate for returning anything useful to you anyway (aside from the bugs I already reported).
*Edit - I forgot I was also going to point out that ->
I suppose everyone jumps on this bandwagon eventually, but I would suggest making it optional to check for updates on startup. People can be funny about things like that, and I may be the funniest of all about it. At the very least, I would also suggest a way to undo an update to the users last version. And for the love of all that is holy, if you *do* list updates, only show stable updates, unless your core is extremely devoted beta testing guinea pigs.FourthWorld wrote:I've considered a check on startup for updates, which would keep the UI free and be arguably simpler, since you'd never have to even think about it until an update is available.
If it were me personally, and not you, I would take the time to put in the check box and possibly run it on first start or on (voluntary / agreed upon) update.It would be very helpful for myself and other devs to obtain a few details about user configs, specifically LC version, system version, and screen rects.
Those three things provide a LOT of useful guidance, and contain no personal information about the user.
I don't use Google to do much of anything except 2 things, both of which I regret even starting, and I don't appreciate the way they feel free to siphon whatever data they feel like about people who do use their services without at least asking if they can. I have other problems with Google, but that is for another day
Of course, ultimately it is your creation, so go whatever way you choose, as I said, I just popped in to point out that not everyone would be all in for that combo. My votes really don't count for much, I'm rarely up to Rev v2 anymore, never mind a version Devo would run in, so am an unlikely candidate for returning anything useful to you anyway (aside from the bugs I already reported).
*Edit - I forgot I was also going to point out that ->
The system version if you get the return from Lc is only going to ever be able to point out what Lc *thinks* it is running on, which isn't always in agreement with what even the OS reports, I'm not sure if you remember that (quite long) thread.user configs, specifically LC version, system version, and screen rects.
Re: quick question... (show invisibles) [Solved]
I'm not sure what the user base for Devo is, but I should think anyone using it will "know and trust" you Richard, and wouldn't be put off by a check-box to opt in.
Other faceless companies or with a lower reputation maybe not.
I am not deeply familiar with GDPR but I "sort of heard" there's a difference in regulation globally, in Europe I believe it is supposedly mandatory to have an "opted out" default position (maybe only to web cookies - or not). Legal beagles have twisted things so that this isn't always the case. Then you get every site being horrible and tries to worm out of things with a slew of confusing buttons and introduction of the "legitimate interest" option which apparently is legitimately allowed to be set to opt in by default, because it's legit. And then a million 3rd parties for which you have to select individual choices or "go to their website to opt out".
I think you would be fine to put an opt-in choice, unless you're masochistic enough to delve "that deep" into the GDPR legalities internationally.
Other faceless companies or with a lower reputation maybe not.
I am not deeply familiar with GDPR but I "sort of heard" there's a difference in regulation globally, in Europe I believe it is supposedly mandatory to have an "opted out" default position (maybe only to web cookies - or not). Legal beagles have twisted things so that this isn't always the case. Then you get every site being horrible and tries to worm out of things with a slew of confusing buttons and introduction of the "legitimate interest" option which apparently is legitimately allowed to be set to opt in by default, because it's legit. And then a million 3rd parties for which you have to select individual choices or "go to their website to opt out".
I think you would be fine to put an opt-in choice, unless you're masochistic enough to delve "that deep" into the GDPR legalities internationally.