At the conference I will announce a plugin, which will have the code read and write widget properties. The code for the plugin will be on github. I'm insanely busy at the moment, so I can't accelerate the release. No magic, just hardcoded property names. :)
On Wed, Apr 6, 2022 at 10:08 PM Monte Goulding via use-livecode < [email protected]> wrote: > > > On 7 Apr 2022, at 11:25 am, Richard Gaskin via use-livecode < > [email protected]> wrote: > > > > > I will say there’s two main use cases for `the properties` and neither > > > of them it serves very well: > > > > > > - Getting the properties of an object to apply to recreate the object > > > elsewhere. export widget does a much better job of this and was > > > designed specifically for that use case. > > > > Can you help me understand how it's better than "the properties", and > why this superior method isn't used for engine controls? > > > > Because the array created by export and used by import contains the state > of the widget as is saved when saving the stack. The content may or may not > be the same as the property names exposed to user scripts but a widget > created with that state should be the same as if it were saved in the stack > and the stack re-opened. > > > > > > - Introspecting what properties an object has in order to create an > > > editor without maintaining your own lists of properties. It has never > > > been good at this. It doesn’t tell you anything about acceptable > > > values for those properties, it doesn’t tell you the importance of > > > the property, it doesn’t tell you about alternative object properties > > > that may be more useful to edit (text, styledText, htmlText, rtfText > > > etc) or whether it’s potentially risky to present a UI that can edit > > > it. Really this use case is served best by a well documented library > > > that covers all objects. Currently you would need to dig the details > > > out of the IDE scripts > > > > That seems to answer the first question, though while the metadata about > types and options is useful for some things, it would still be useful to > get just the name-value pairs as "the properties" does. > > > > That the company has such a narrowly specific view of the applicability > of "the properties" is indeed helpful. Thank you for chiming in. > > I’m not the company. Mark may spend a lot more time pondering the utility > of `the properties` than I do and indeed may have a different opinion. > Indeed my opinion was much closer to yours is now when I sent in a PR for > LC 6.1 all those years ago ;-) > > > Let me simplify the question: > > > > How hard would it be for the team to map the existing means of > extracting widget properties to "the properties”? > > I don’t think it would be particularly tricky to iterate the exported > property definitions to come up with a list of property names then turn > that into a key/value array. Whether it would provide the utility you are > looking for is a separate question. > > Cheers > > Monte > > > > _______________________________________________ > use-livecode mailing list > [email protected] > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
