LiveCode Forums.

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)

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

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,

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

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

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?

stam wrote: ↑

Wed Jun 09, 2021 11:20 pm

@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 for the kind words.

Feedback like that helps me prioritize some new additions I have in the hopper.

Thanks to Elanor's code it's easy to toggle invisibles:

Code: Select all

set the showInvisibles to not the showInvisibles

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.

I had hoped the IDE code would be smarter than the simplistic brute-force implementation in the engine.

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).

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?

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.

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.

FourthWorld wrote: ↑

Fri Jun 11, 2021 5:26 pm

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.

Dear Richard - thank you! Updated and it works a treat!(very slick update process BTW)

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...

stam wrote: ↑

Fri Jun 11, 2021 7:11 pm

FourthWorld wrote: ↑

Fri Jun 11, 2021 5:26 pm

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.

Dear Richard - thank you! Updated and it works a treat!(very slick update process BTW)

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...

Thank you for your support, Stam. Much appreciated, and very motivating to work through the feature request list.

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...

FourthWorld wrote: ↑

Fri Jun 11, 2021 7:20 pm

If you like the idea I'll see if I can drop it in next week...

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...

stam wrote: ↑

Fri Jun 11, 2021 7:30 pm

FourthWorld wrote: ↑

Fri Jun 11, 2021 7:20 pm

If you like the idea I'll see if I can drop it in next week...

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...

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. #motivating

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?

FourthWorld wrote: ↑

Fri Jun 11, 2021 7:57 pm

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.

Personally i would have no issue at all with this - as you say, a cursory google search does worse...
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

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

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.

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.

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.

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.

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 ->

user configs, specifically LC version, system version, and screen rects.

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.

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.