Re: widget properties

[Neville Smythe via use-livecode]

 (Bug 23670 ) has been 
referred by QualityControl to Expert Review, as Panos was not sure whether this 
is a real bug. As a use-case I have commented that the properties of all 
controls, including widgets, is needed when comparing stacks for example.

In the meantime, I have uploaded version 2 of nsScriptDatabase to Sample 
Stacks,  now optionally allowing adding the properties of objects to the 
database, so the complete state of a stack is captured, although scripts remain 
the main focus. When using the "compare stacks” feature I make up a credible 
list of properties for widgets.

Neville

___
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: Widget properties

[Jim Lambert via use-livecode]

> After a day or two with BBC BASIC on a black screen teenagers will "do 
> anything for me" when they see the, supposedly,
> old-fashioned LiveCode IDE and the ever-so-sexy WYSIWYG GUI.

Using the ol' psychology on 'em. 
Wily!

___
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: Widget properties

[Richmond via use-livecode]

 implementation has 
been chosen and established so long ago, it seems worth mirroring in 
new implementations.


But TBH, since I haven't used widgets in production at all, the only 
time it comes to mind is when someone asks me about it for one of my 
tools, or in discussions like this one. This seemed a good time to see 
what the current vision is. I appreciate the clarity provided.



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

If it does what "the properties" does it would suit my needs.




___
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: Widget properties

[Richard Gaskin via use-livecode]

Thank you for your reply, Monte. Comments inline:

Monte Goulding wrote:
>> On 7 Apr 2022, at 11:25 am, Richard Gaskin wrote:
>> 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.

I've never used a widget in production yet, so I can't say I have an 
opinion there.  If the uses for widgets are viewed as sufficiently 
different from engine-based controls that "the properties" so many of us 
enjoy wouldn't apply, I'm okay with that. Just looking to understand.



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

Pardon my imprecision. I think the readers here are likely aware that 
the company is comprised of many people, and there are likely many 
different opinions on a wide range of topics, including this.  Please 
read that as "a significant member of 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 ;-)

One of the challenges with a tool as vastly capable as LiveCode is 
wrapping one's head around all the use-cases, and all the perceived 
priorities.  Various members of the company and the community have 
expressed a wide range of opinions on many things.


If "the properties" winds up being like the pointer tool requests I used 
to ask about, no worries. I stopped asking about those years ago.


Indeed, even with "the properties" I've had a few discussions on this 
with different team members going back to Dr Brett, back when LCB was in 
its earliest stages.


In my own mind having two different methods for obtaining property data 
for two classes of objects is akin to having two different words for 
"rect" or other basic features.  Where a useful implementation has been 
chosen and established so long ago, it seems worth mirroring in new 
implementations.


But TBH, since I haven't used widgets in production at all, the only 
time it comes to mind is when someone asks me about it for one of my 
tools, or in discussions like this one. This seemed a good time to see 
what the current vision is. I appreciate the clarity provided.



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

If it does what "the properties" does it would suit my needs.

--
 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: widget properties

[Mark Wieder via use-livecode]

On 4/6/22 19:04, Neville Smythe via use-livecode wrote:


Unfortunately LC doesn’t respond with a “object does not have this property” 
error message if you query any old reserved property key for a widget.

It's actually even worse. The clock widget, for instance:
The exported array contains special color options.
These appear in the property inspector colors pane.

You can set the backgroundColor.
You can query the backgroundColor.
But it doesn't appear in the property inspector colors pane.
It also doesn't appear in the custom properties pane.
It does maintain a reasonable value, but it doesn't do anything.
But it *is* serializable.

So does that qualify as a "property" of the widget?

Seems like it might be useful as a way to store "secret" information: 
passwords, api keys, etc. that won't appear anywhere and you have to 
know about them to query for them in the first place.


--
 Mark Wieder
 ahsoftw...@gmail.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: Widget properties

[Tom Glod via use-livecode]

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 <
use-livecode@lists.runrev.com> wrote:

>
> > On 7 Apr 2022, at 11:25 am, Richard Gaskin via use-livecode <
> use-livecode@lists.runrev.com> 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
> 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: Widget properties

[Monte Goulding via use-livecode]

> On 7 Apr 2022, at 11:25 am, Richard Gaskin via use-livecode 
>  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
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: widget properties

[Neville Smythe via use-livecode]

Just a point of clarification; Ali’s post does not explain how to access the 
object properties of a widget. The properties returned by

put the keys of (revIDEExtensionProperties("com.livecode.widget.foo"))


are the intrinsic properties of the widget, which these days  are accessible 
via the 

export widget “foo” to array tBar

command. They are not the ordinary object properties such as its rect, 
visibility etc. 

My current workaround is to just make up a list of likely properties names, for 
example those of a group, deleting the few properties obviously specific to a 
group. Unfortunately LC doesn’t respond with a “object does not have this 
property” error message if you query any old reserved property key for a 
widget. An alternative would be to go through the properties shown in the 
Property Inspector deleting the intrinsic properties specific to the widget; 
but some intrinsic properties are also common object properties, eg showBorder, 
depending on the widget you choose, and further I am not entirely sure that the 
Property Inspector actually exposes all the properties of an object (?). It 
also lists interdependent properties (loc <- rect) which should not be returned 
by the properties function.

Neville

___
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: Widget properties

[Richard Gaskin via use-livecode]

Mark Wieder wrote:

> On 4/6/22 16:39, Richard Gaskin via use-livecode wrote:
>
>>  > ...there has never been any intention of supporting the properties
>>  > for widgets as far as I’m aware...
>>
>> If the company wants widgets to be seen as first-class citizens, a
>> little more conformity with existing object syntax would go a long
>> way to making that happen.
>
>
> Adding to that is the incoming LCS widget architecture, so I'm not
> putting deep learning time into something I'll just have to unlearn
> when the next wave hits.

Succinctly put.


Back when Ben was fleshing out the "before" and "after" messaging 
options, and the object-local mirror of the selectGroupedControls 
property for groups, and other such things that have made the DataGrid 
such a joy to work with, I had high hopes that this effort to 
encapsulate compound objects durably would continue.


I'm very excited by the choice to return to that effort.  LCB is a fine 
language, and I'm as envious of its indexed arrays as I am mystified why 
they haven't found their way into LCS.  But it's so easy to make 
compound objects in LCS I haven't been able to justify the time to learn 
a similar-but-incompatible language.


So soon we will have three classes of objects: engine-native, widgets, 
and whatever the LCS-based widgets are called.


It would be great to have a single robust, uniform serialization for 
their attributes.


--
 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: Widget properties

[Richard Gaskin via use-livecode]

Monte Goulding wrote:

> It seems a stretch to imply the lack of support for a property that
> has little to no use case outside the IDE means the company doesn’t
> take widgets seriously but I’m not going to argue with you about that.

A reasonable choice, given that "seriously" is a colloquialism with no 
specific quantifiable meaning.


Here I used it to try to elicit LC's vision for widgets.  I had the 
(quite possibly mistaken) notion that widgets were a way to craft 
reusable controls that would look and feel like engine objects, but with 
the advantage that they could be created from a scripting language.


We see many queries here about messages common to all other controls not 
working with widgets, and now and then we see queries about properties 
and functions too.


"The properties" is just the latest of these, and your view of that here 
is helpful:


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



> - 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 use "the properties" in a great many things, even outside the IDE 
tools, though those are about half of everything I've been doing as one 
of the few people outside the company working full-time with LC for as 
long as I have.


Much of what I do is bespoke authoring systems, and frequently they're 
implemented as plugins.  This is something I love about xTalks, and the 
SC/MC/LC philosophy that's driven the post-HC world. SC's Bill Appleton 
summed it up well when he once said:


"HyperCard is a multimedia authoring system. SuperCard is a tool
 you can use to build multimedia authoring systems."

For myself, and a good many others I know, the value of making tools is 
not limited to the IDE team, but a core value and key differentiator of 
choosing LiveCode.


I have lot of ways to make software. But few of them let me redefine the 
workflow as flexibly as an xTalk. And no xTalk has been as flexible as 
LiveCode.


It's like the difference between a drawing program and a scriptable 
drawing program, or between Wordpress and Drupal, or between a sculpture 
and modeling clay.


I appreciate your team making an IDE, but for most of us who make our 
living with it it's only part of the toolset we use.



On the more consumer-facing side which may better fit a view in which 
tooling is seen as for the engine team only, consider styling:


When we set "the properties" of an object, it affects only the keys 
present, leaving everything else alone.


This means we can make arrays with any subset of relevant attributes we 
want, and apply them almost like style sheets with just one line.  We 
can even save these prop subsets to disk as LSON files if we like, so we 
can reuse them, mixing and matching from screen to screen and project to 
project as we like.


In fact, using "the properties" has become such a habit across so much 
of what I do I have to admit that I need to think about it to list them 
all, in the way a fish struggles to define water.



Arrays are a great foundational data type, and being able to express 
controls with them efficiently and uniformly is a godsend.


From my perspective, perhaps no less limited than someone who works all 
day on the IDE but coming at it from a different angle, the question 
seems less interesting as "Why is this useful?" than "How could it not be?"



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


--
 Richard 

Re: Widget properties

[Mark Wieder via use-livecode]

On 4/6/22 16:39, Richard Gaskin via use-livecode wrote:


 > ...there has never been any intention of supporting the properties
 > for widgets as far as I’m aware...

If the company wants widgets to be seen as first-class citizens, a 
little more conformity with existing object syntax would go a long way 
to making that happen.



Adding to that is the incoming LCS widget architecture, so I'm not 
putting deep learning time into something I'll just have to unlearn when 
the next wave hits.


--
 Mark Wieder
 ahsoftw...@gmail.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: Widget properties

[Monte Goulding via use-livecode]

> On 7 Apr 2022, at 9:39 am, Richard Gaskin via use-livecode 
>  wrote:
> 
> Monte Goulding wrote:
> 
> > ...there has never been any intention of supporting the properties
> > for widgets as far as I’m aware...
> 
> If the company wants widgets to be seen as first-class citizens, a little 
> more conformity with existing object syntax would go a long way to making 
> that happen.
> 
> It's possible for the engine to derive a set of widget properties. If it's 
> not also possible to map that into how "the properties" works that would be 
> very enlightening.
> 
> 
> FWIW I've had requests to update my 4W Property Sheet tool to special-case 
> for widgets. I tell people I'll take widgets seriously when the company does, 
> and if they do I won't need to update my tool because the existing call to 
> "the properties" that works for everything else will work for widgets.
> 
> Maybe I've been overestimating the importance of widgets to LC Ltd. Guidance 
> welcome.

It seems a stretch to imply the lack of support for a property that has little 
to no use case outside the IDE means the company doesn’t take widgets seriously 
but I’m not going to argue with you about that. 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. In some variants of this use case the copy 
command is much simpler to use here too.
- 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

Cheers

Monte
___
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: widget properties

[Neville Smythe via use-livecode]

I have submitted the bug report (Bug 23670 
) As others have said, it 
is not likely this will be considered a high priority bug but it should be on 
the record.

Interestingly eg setting tbar[“textcolor”] to a value and then

set the properties of widget “foo" to tbar 

does work (although the properties are still reported as empty). 

Many thanks for the reference to Ali’s forum article, which is very helpful. I 
came across this  problem because I am adding listing of all object properties 
to my nsScriptdatabase utility. Thus in version 2 it will be possible to 
compare stacks in the database down to the complete saved state of the stack, 
and so (theoretically) reconstruct the stack. Ali’s post prompts me to add 
listing the handlers of a widget which could be very useful information. I 
expect to upload version 2 within a few days.

Neville

___
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: Widget properties

[Bob Sneidar via use-livecode]

Poor Widget. The bastard child of Livecode objects.  ;-P

Bob S


> On Apr 6, 2022, at 16:39 , Richard Gaskin via use-livecode 
>  wrote:
> 
> Monte Goulding wrote:
> 
> > ...there has never been any intention of supporting the properties
> > for widgets as far as I’m aware...
> 
> If the company wants widgets to be seen as first-class citizens, a little 
> more conformity with existing object syntax would go a long way to making 
> that happen.
> 
> It's possible for the engine to derive a set of widget properties. If it's 
> not also possible to map that into how "the properties" works that would be 
> very enlightening.
> 
> 
> FWIW I've had requests to update my 4W Property Sheet tool to special-case 
> for widgets. I tell people I'll take widgets seriously when the company does, 
> and if they do I won't need to update my tool because the existing call to 
> "the properties" that works for everything else will work for widgets.
> 
> Maybe I've been overestimating the importance of widgets to LC Ltd. Guidance 
> welcome.
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web

___
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: Widget properties

[Richard Gaskin via use-livecode]

Monte Goulding wrote:

> ...there has never been any intention of supporting the properties
> for widgets as far as I’m aware...

If the company wants widgets to be seen as first-class citizens, a 
little more conformity with existing object syntax would go a long way 
to making that happen.


It's possible for the engine to derive a set of widget properties. If 
it's not also possible to map that into how "the properties" works that 
would be very enlightening.



FWIW I've had requests to update my 4W Property Sheet tool to 
special-case for widgets. I tell people I'll take widgets seriously when 
the company does, and if they do I won't need to update my tool because 
the existing call to "the properties" that works for everything else 
will work for widgets.


Maybe I've been overestimating the importance of widgets to LC Ltd. 
Guidance welcome.


--
 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: Widget properties

[Monte Goulding via use-livecode]

I suspect this will be classed as not a bug as there has never been any 
intention of supporting the properties for widgets as far as I’m aware but it 
might be worth submitting it anyway and detailing your use case. I think if you 
look at the old lcVCS discussions on the forums from before my time on the LC 
team Mark implemented import/export widget in response to my needs there. The 
properties is really not that worthwhile for widgets as it would only ever 
support the common object properties like visible, rect etc.

Thinking back when I did a PR for the properties soon after LC went open source 
it should have been deprecated instead of accepting it. I wouldn’t have 
understood that was the best thing to do at the time though. It really would be 
better to add all the other object types to the import/export commands. One 
reason I think it would be good for you to submit a bug report is it could be 
changed to a docs bug and resolved by deprecating the properties, adding a note 
about the lack of widget support and the import/export command that can be used 
there and perhaps opening a feature request to support other objects in 
import/export.

Cheers

Monte

> On 6 Apr 2022, at 10:03 pm, Neville Smythe via use-livecode 
>  wrote:
> 
> Is it not a bug that
> 
> the properties of widget “foo”
> 
> returns empty (for all values of foo)?
> 
> No rect, no visible, no disabled etc, even though these clearly are settable 
> and functional properties of the widget.
> 
> You can
> 
>export widget “foo” to array “bar”
> 
> but that gives the intrinsic properties of the widget not the usual object 
> properties. Oh and don’t forget the reserved word “array” in the above line, 
> that causes an IDE crash (bug 23655 
>  confirmed)
> 
> Neville
> ___
> 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: Widget properties

[Sean Cole via use-livecode]

I would suggest filing a report and get the ball rolling. If you reference
in the post by Ali and your other workarounds it will at least be useful to
some and at best provide information that leads to a fix.

On Wed, 6 Apr 2022 at 14:30, matthias rebbe via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Maybe.
>
> But the last 6 years no one filed a bug report, even Ali did not. So i
> doubt, that it will be fixed in the near future even with a bug report.
> Anyway, without a bug report there is definitely no chance that it will be
> ever fixed.
>
>
> > Am 06.04.2022 um 15:22 schrieb Tweedly via use-livecode <
> use-livecode@lists.runrev.com>:
> >
> > That post from Ali says they are not available; it doesn’t say they
> should be not available.
> >
> > I’d say they should be -  Ali’s workaround is good for the IDE only.
> >
> > So no reason not to submit as a bug/request, and get a proper
> determination from LCLtd.
> >
> > Alex
> >
> > Sent from my iPad
> >
> >> On 6 Apr 2022, at 13:37, matthias rebbe via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >>
> >> That is not available according to this post from Ali Lloyd
> >>
> >> https://forums.livecode.com/viewtopic.php?t=27183#p141945 <
> https://forums.livecode.com/viewtopic.php?t=27183#p141945>
> >>
> >>
> >>> Am 06.04.2022 um 14:03 schrieb Neville Smythe via use-livecode <
> use-livecode@lists.runrev.com>:
> >>>
> >>> Is it not a bug that
> >>>
> >>>   the properties of widget “foo”
> >>>
> >>> returns empty (for all values of foo)?
> >>>
> >>> No rect, no visible, no disabled etc, even though these clearly are
> settable and functional properties of the widget.
> >>>
> >>> You can
> >>>
> >>>  export widget “foo” to array “bar”
> >>>
> >>> but that gives the intrinsic properties of the widget not the usual
> object properties. Oh and don’t forget the reserved word “array” in the
> above line, that causes an IDE crash (bug 23655 <
> https://quality.livecode.com/show_bug.cgi?id=23655> confirmed)
> >>>
> >>> Neville
> >>> ___
> >>> 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
>
>
> ___
> 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: Widget properties

[matthias rebbe via use-livecode]

Maybe.

But the last 6 years no one filed a bug report, even Ali did not. So i doubt, 
that it will be fixed in the near future even with a bug report.
Anyway, without a bug report there is definitely no chance that it will be ever 
fixed.


> Am 06.04.2022 um 15:22 schrieb Tweedly via use-livecode 
> :
> 
> That post from Ali says they are not available; it doesn’t say they should be 
> not available.
> 
> I’d say they should be -  Ali’s workaround is good for the IDE only.
> 
> So no reason not to submit as a bug/request, and get a proper determination 
> from LCLtd.
> 
> Alex
> 
> Sent from my iPad
> 
>> On 6 Apr 2022, at 13:37, matthias rebbe via use-livecode 
>>  wrote:
>> 
>> That is not available according to this post from Ali Lloyd
>> 
>> https://forums.livecode.com/viewtopic.php?t=27183#p141945 
>> 
>> 
>> 
>>> Am 06.04.2022 um 14:03 schrieb Neville Smythe via use-livecode 
>>> :
>>> 
>>> Is it not a bug that
>>> 
>>>   the properties of widget “foo”
>>> 
>>> returns empty (for all values of foo)?
>>> 
>>> No rect, no visible, no disabled etc, even though these clearly are 
>>> settable and functional properties of the widget.
>>> 
>>> You can
>>> 
>>>  export widget “foo” to array “bar”
>>> 
>>> but that gives the intrinsic properties of the widget not the usual object 
>>> properties. Oh and don’t forget the reserved word “array” in the above 
>>> line, that causes an IDE crash (bug 23655 
>>>  confirmed)
>>> 
>>> Neville
>>> ___
>>> 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


___
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: Widget properties

[Tweedly via use-livecode]

That post from Ali says they are not available; it doesn’t say they should be 
not available.

I’d say they should be -  Ali’s workaround is good for the IDE only.

So no reason not to submit as a bug/request, and get a proper determination 
from LCLtd.

Alex

Sent from my iPad

> On 6 Apr 2022, at 13:37, matthias rebbe via use-livecode 
>  wrote:
> 
> That is not available according to this post from Ali Lloyd
> 
> https://forums.livecode.com/viewtopic.php?t=27183#p141945 
> 
> 
> 
>> Am 06.04.2022 um 14:03 schrieb Neville Smythe via use-livecode 
>> :
>> 
>> Is it not a bug that
>> 
>>the properties of widget “foo”
>> 
>> returns empty (for all values of foo)?
>> 
>> No rect, no visible, no disabled etc, even though these clearly are settable 
>> and functional properties of the widget.
>> 
>> You can
>> 
>>   export widget “foo” to array “bar”
>> 
>> but that gives the intrinsic properties of the widget not the usual object 
>> properties. Oh and don’t forget the reserved word “array” in the above line, 
>> that causes an IDE crash (bug 23655 
>>  confirmed)
>> 
>> Neville
>> ___
>> 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: Widget properties

[matthias rebbe via use-livecode]

Forgot to mention that his post also has a solution to fetch the list of all 
available properties for a widget.


> Am 06.04.2022 um 14:36 schrieb matthias_livecode_150...@m-r-d.de:
> 
> That is not available according to this post from Ali Lloyd
> 
> https://forums.livecode.com/viewtopic.php?t=27183#p141945 
> 
> 
> 
>> Am 06.04.2022 um 14:03 schrieb Neville Smythe via use-livecode 
>> mailto:use-livecode@lists.runrev.com>>:
>> 
>> Is it not a bug that
>> 
>> the properties of widget “foo”
>> 
>> returns empty (for all values of foo)?
>> 
>> No rect, no visible, no disabled etc, even though these clearly are settable 
>> and functional properties of the widget.
>> 
>> You can
>> 
>>export widget “foo” to array “bar”
>> 
>> but that gives the intrinsic properties of the widget not the usual object 
>> properties. Oh and don’t forget the reserved word “array” in the above line, 
>> that causes an IDE crash (bug 23655 
>> > > confirmed)
>> 
>> Neville
>> ___
>> 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: Widget properties

[matthias rebbe via use-livecode]

That is not available according to this post from Ali Lloyd

https://forums.livecode.com/viewtopic.php?t=27183#p141945 



> Am 06.04.2022 um 14:03 schrieb Neville Smythe via use-livecode 
> :
> 
> Is it not a bug that
> 
> the properties of widget “foo”
> 
> returns empty (for all values of foo)?
> 
> No rect, no visible, no disabled etc, even though these clearly are settable 
> and functional properties of the widget.
> 
> You can
> 
>export widget “foo” to array “bar”
> 
> but that gives the intrinsic properties of the widget not the usual object 
> properties. Oh and don’t forget the reserved word “array” in the above line, 
> that causes an IDE crash (bug 23655 
>  confirmed)
> 
> Neville
> ___
> 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

Widget properties

[Neville Smythe via use-livecode]

Is it not a bug that

 the properties of widget “foo”

returns empty (for all values of foo)?

No rect, no visible, no disabled etc, even though these clearly are settable 
and functional properties of the widget.

You can

export widget “foo” to array “bar”

but that gives the intrinsic properties of the widget not the usual object 
properties. Oh and don’t forget the reserved word “array” in the above line, 
that causes an IDE crash (bug 23655 
 confirmed)

Neville
___
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: Widget Properties

[J. Landman Gay via use-livecode]

Don't despair, not all widgets are duds. I've used several with good 
success: the browser widget, spinner, tree view, switch button, nav bar, 
segmented control and probably some others I can't remember. Since each 
widget is authored by an individual, the properties they support vary but 
like any software, feature requests are considered.


In my case I usually can't wait for a specific feature so I use LC controls 
or groups that emulate the control I need. In my last project I created a 
navigation bar with LC controls but it was recently updated to support a 
feature I needed and now I'm using it again.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On April 25, 2020 9:19:00 AM Graham Samuel via use-livecode 
 wrote:



Thanks Jacque

You’re adding to my gloom about widgets being offered as native controls - 
the only reason they were produced AFAIKS was to produce a superior result 
to whatever else was on offer, and if they don’t, why bother? I have a 
feeling not many people are trying to use them - you don’t for example, and 
so far nobody on this list has come to their defence. Perhaps LC’s widget 
factory is right to put their energies elsewhere.


Graham

On 25 Apr 2020, at 00:03, J. Landman Gay via use-livecode 
 wrote:


My suggestion was just to see what properties are available in the widget. 
But when I just tried it, I see that it doesn't respond in the IDE, what 
you see is just a placeholder. You can search for "ios native button" in 
the dictionary, where I see only two available properties: enabled and label.


If the widget author doesn't support the rest of them, they don't exist. I 
do see that you can resize the rectangle, but since I don't use the native 
buttons I'm not sure if the size will be retained on an iPhone or whether 
it just defaults to the standard native size.


Typically only the properties that the author has supported will appear in 
the property inspector.



On 4/24/20 3:35 PM, Graham Samuel via use-livecode wrote:
Thanks Jacque - info safely stored in my “how to make a mobile app look 
like one” archive!
Thanks for the other info about properties - how would you then refer to a 
property that isn’t shown in the Property Inspector for a widget, such as 
fontColor (or whatever)? I assume the array is just a way of accessing the 
whole collection and not the route to setting an individual property - but 
I’m probably wrong.

Graham
On 24 Apr 2020, at 20:26, J. Landman Gay via use-livecode 
 wrote:


On 4/24/20 3:37 AM, Graham Samuel via use-livecode wrote:
As my app took shape, I noticed how unlike a typical iPhone app it looked, 
mostly because I was using the controls I was familiar with, such as radio 
buttons and ordinary fields. I wondered if my users might find its 
interface unfamiliar. Therefore I have been seeking to make my app’s user 
interface look and feel more like other iPhone apps. I have already had a 
lot of help from this list, but it seems there is no one packaged solution 
to getting an ‘iPhone look and feel’.


You mentioned the iOS native button doesn't look right. If it makes you 
feel better, the Android one doesn't either. So what I did was use a 
round-rect graphic as a button. Set the linesize to 1 and the round radius 
to 8. You can set the border color and the text color.


I use the same graphic for Android. Sometimes Android buttons have a fill 
color, sometimes they are just borderless text. I adjust those properties 
based on platform. IOS buttons use sentence capitalization, Android buttons 
use all-caps. The label can be adjusted the same way based on platform.


It's an easy fix and looks native.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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



--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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: Widget Properties

[Graham Samuel via use-livecode]

Thanks Jacque

You’re adding to my gloom about widgets being offered as native controls - the 
only reason they were produced AFAIKS was to produce a superior result to 
whatever else was on offer, and if they don’t, why bother? I have a feeling not 
many people are trying to use them - you don’t for example, and so far nobody 
on this list has come to their defence. Perhaps LC’s widget factory is right to 
put their energies elsewhere.

Graham

> On 25 Apr 2020, at 00:03, J. Landman Gay via use-livecode 
>  wrote:
> 
> My suggestion was just to see what properties are available in the widget. 
> But when I just tried it, I see that it doesn't respond in the IDE, what you 
> see is just a placeholder. You can search for "ios native button" in the 
> dictionary, where I see only two available properties: enabled and label.
> 
> If the widget author doesn't support the rest of them, they don't exist. I do 
> see that you can resize the rectangle, but since I don't use the native 
> buttons I'm not sure if the size will be retained on an iPhone or whether it 
> just defaults to the standard native size.
> 
> Typically only the properties that the author has supported will appear in 
> the property inspector.
> 
> 
> On 4/24/20 3:35 PM, Graham Samuel via use-livecode wrote:
>> Thanks Jacque - info safely stored in my “how to make a mobile app look like 
>> one” archive!
>> Thanks for the other info about properties - how would you then refer to a 
>> property that isn’t shown in the Property Inspector for a widget, such as 
>> fontColor (or whatever)? I assume the array is just a way of accessing the 
>> whole collection and not the route to setting an individual property - but 
>> I’m probably wrong.
>> Graham
>>> On 24 Apr 2020, at 20:26, J. Landman Gay via use-livecode 
>>>  wrote:
>>> 
>>> On 4/24/20 3:37 AM, Graham Samuel via use-livecode wrote:
 As my app took shape, I noticed how unlike a typical iPhone app it looked, 
 mostly because I was using the controls I was familiar with, such as radio 
 buttons and ordinary fields. I wondered if my users might find its 
 interface unfamiliar. Therefore I have been seeking to make my app’s user 
 interface look and feel more like other iPhone apps. I have already had a 
 lot of help from this list, but it seems there is no one packaged solution 
 to getting an ‘iPhone look and feel’.
>>> 
>>> You mentioned the iOS native button doesn't look right. If it makes you 
>>> feel better, the Android one doesn't either. So what I did was use a 
>>> round-rect graphic as a button. Set the linesize to 1 and the round radius 
>>> to 8. You can set the border color and the text color.
>>> 
>>> I use the same graphic for Android. Sometimes Android buttons have a fill 
>>> color, sometimes they are just borderless text. I adjust those properties 
>>> based on platform. IOS buttons use sentence capitalization, Android buttons 
>>> use all-caps. The label can be adjusted the same way based on platform.
>>> 
>>> It's an easy fix and looks native.
>>> 
>>> -- 
>>> Jacqueline Landman Gay | jac...@hyperactivesw.com
>>> HyperActive Software   | http://www.hyperactivesw.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
> 
> 
> -- 
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.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: Widget Properties

[J. Landman Gay via use-livecode]

My suggestion was just to see what properties are available in the widget. But when I just 
tried it, I see that it doesn't respond in the IDE, what you see is just a placeholder. You can 
search for "ios native button" in the dictionary, where I see only two available properties: 
enabled and label.


If the widget author doesn't support the rest of them, they don't exist. I do see that you can 
resize the rectangle, but since I don't use the native buttons I'm not sure if the size will be 
retained on an iPhone or whether it just defaults to the standard native size.


Typically only the properties that the author has supported will appear in the 
property inspector.


On 4/24/20 3:35 PM, Graham Samuel via use-livecode wrote:

Thanks Jacque - info safely stored in my “how to make a mobile app look like 
one” archive!

Thanks for the other info about properties - how would you then refer to a 
property that isn’t shown in the Property Inspector for a widget, such as 
fontColor (or whatever)? I assume the array is just a way of accessing the 
whole collection and not the route to setting an individual property - but I’m 
probably wrong.

Graham


On 24 Apr 2020, at 20:26, J. Landman Gay via use-livecode 
 wrote:

On 4/24/20 3:37 AM, Graham Samuel via use-livecode wrote:

As my app took shape, I noticed how unlike a typical iPhone app it looked, 
mostly because I was using the controls I was familiar with, such as radio 
buttons and ordinary fields. I wondered if my users might find its interface 
unfamiliar. Therefore I have been seeking to make my app’s user interface look 
and feel more like other iPhone apps. I have already had a lot of help from 
this list, but it seems there is no one packaged solution to getting an ‘iPhone 
look and feel’.


You mentioned the iOS native button doesn't look right. If it makes you feel 
better, the Android one doesn't either. So what I did was use a round-rect 
graphic as a button. Set the linesize to 1 and the round radius to 8. You can 
set the border color and the text color.

I use the same graphic for Android. Sometimes Android buttons have a fill 
color, sometimes they are just borderless text. I adjust those properties based 
on platform. IOS buttons use sentence capitalization, Android buttons use 
all-caps. The label can be adjusted the same way based on platform.

It's an easy fix and looks native.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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




--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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: Widget Properties

[Graham Samuel via use-livecode]

Thanks Jacque - info safely stored in my “how to make a mobile app look like 
one” archive!

Thanks for the other info about properties - how would you then refer to a 
property that isn’t shown in the Property Inspector for a widget, such as 
fontColor (or whatever)? I assume the array is just a way of accessing the 
whole collection and not the route to setting an individual property - but I’m 
probably wrong.

Graham

> On 24 Apr 2020, at 20:26, J. Landman Gay via use-livecode 
>  wrote:
> 
> On 4/24/20 3:37 AM, Graham Samuel via use-livecode wrote:
>> As my app took shape, I noticed how unlike a typical iPhone app it looked, 
>> mostly because I was using the controls I was familiar with, such as radio 
>> buttons and ordinary fields. I wondered if my users might find its interface 
>> unfamiliar. Therefore I have been seeking to make my app’s user interface 
>> look and feel more like other iPhone apps. I have already had a lot of help 
>> from this list, but it seems there is no one packaged solution to getting an 
>> ‘iPhone look and feel’.
> 
> You mentioned the iOS native button doesn't look right. If it makes you feel 
> better, the Android one doesn't either. So what I did was use a round-rect 
> graphic as a button. Set the linesize to 1 and the round radius to 8. You can 
> set the border color and the text color.
> 
> I use the same graphic for Android. Sometimes Android buttons have a fill 
> color, sometimes they are just borderless text. I adjust those properties 
> based on platform. IOS buttons use sentence capitalization, Android buttons 
> use all-caps. The label can be adjusted the same way based on platform.
> 
> It's an easy fix and looks native.
> 
> -- 
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.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: Widget Properties

[Richard Gaskin via use-livecode]

J. Landman Gay wrote:

> So what I did was use a round-rect graphic as a button. Set the
> linesize to 1 and the round radius to 8. You can set the border color
> and the text color.

Using the graphic is a much better choice than a roundRect button, 
because the button uses an older non-antialiased corner.


If any of the C programmers here have a few minutes, we could enjoy all 
the benefits roundRect button with appearances as good as a roundRect 
graphic with what Monte describes as a fairly minor bit of work:


   This is possibly a good user contribution. It's just wrapping
   the drawroundrect call with `dc -> setquality(QUALITY_SMOOTH);
   ` & `dc -> setquality(QUALITY_DEFAULT);`

https://quality.livecode.com/show_bug.cgi?id=21118

--
 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: Widget Properties

[J. Landman Gay via use-livecode]

On 4/23/20 11:41 AM, Graham Samuel via use-livecode wrote:

  Hoping that other properties were just not showing up, I tried

   put the properties of widget “myWidget”

in the message box and got nothing, so I don’t know how to proceed.


The properties are an array so they won't display in the message box. I usually write a tiny 
one-line handler and put a breakpoint in so I can see the array in the variable pane.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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: Widget Properties

[J. Landman Gay via use-livecode]

On 4/24/20 3:37 AM, Graham Samuel via use-livecode wrote:

As my app took shape, I noticed how unlike a typical iPhone app it looked, 
mostly because I was using the controls I was familiar with, such as radio 
buttons and ordinary fields. I wondered if my users might find its interface 
unfamiliar. Therefore I have been seeking to make my app’s user interface look 
and feel more like other iPhone apps. I have already had a lot of help from 
this list, but it seems there is no one packaged solution to getting an ‘iPhone 
look and feel’.


You mentioned the iOS native button doesn't look right. If it makes you feel better, the 
Android one doesn't either. So what I did was use a round-rect graphic as a button. Set the 
linesize to 1 and the round radius to 8. You can set the border color and the text color.


I use the same graphic for Android. Sometimes Android buttons have a fill color, sometimes they 
are just borderless text. I adjust those properties based on platform. IOS buttons use sentence 
capitalization, Android buttons use all-caps. The label can be adjusted the same way based on 
platform.


It's an easy fix and looks native.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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: Widget Properties

[Graham Samuel via use-livecode]

Hello Scott

Just to keep you in the loop, I have been trying to produce a mobile app (right 
now it’s iPhone — Android may come later). I’m trying to do this as rapidly as 
possible (it is connected in a minor way to the lockdown measures for the 
pandemic).  I have lots of experience of LiveCode development but almost zero 
for mobile. 

As my app took shape, I noticed how unlike a typical iPhone app it looked, 
mostly because I was using the controls I was familiar with, such as radio 
buttons and ordinary fields. I wondered if my users might find its interface 
unfamiliar. Therefore I have been seeking to make my app’s user interface look 
and feel more like other iPhone apps. I have already had a lot of help from 
this list, but it seems there is no one packaged solution to getting an ‘iPhone 
look and feel’. As LC offers some ‘native’ controls, I tried to use the maximum 
of these - I even paid for a pack of native widgets. That’s why I was using the 
button widget.

So far the results have been disappointing in the widget line, although other 
features like mobilePick and the choice of soft keyboards have worked well. On 
the whole up to now, the widget solutions have only been marginally helpful. 

Hope that explains it - probably more than you want to know!

Graham

> On 23 Apr 2020, at 22:32, scott--- via use-livecode 
>  wrote:
> 
> Hello Graham,
> 
> Sorry if I missed this earlier but, what made you go with a button widget 
> rather than just using a standard LiveCode button?
> 
> —
> Scott
> 
>> On Apr 23, 2020, at 9:41 AM, Graham Samuel via use-livecode 
>>  wrote:
>> 
>> I am getting rather fed up with the widgets I’ve been trying to use for my 
>> mobile app. For example, the iOS button widget (a press button, not a 
>> switch) has so few properties that you can’t change the colour of the text 
>> in any way I could see and sometimes mine turn out blue or red for no 
>> apparent reason. Hoping that other properties were just not showing up, I 
>> tried
>> 
>> put the properties of widget “myWidget”
>> 
>> in the message box and got nothing, so I don’t know how to proceed. 
>> 
>> I also hate that the object doesn’t have a label separate from its name. I 
>> would never recommend anyone to put spaces in names of objects for 
>> scripting, but of course they’re essential for many kinds of label seen by a 
>> user, so the two different strings which work in normal LC are essential, in 
>> my opinion.
>> 
>> Oh dear, this has some danger of becoming a rant…
>> 
>> Graham
>> ___
>> 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: Widget Properties

[scott--- via use-livecode]

Hello Graham,

Sorry if I missed this earlier but, what made you go with a button widget 
rather than just using a standard LiveCode button?

—
Scott

> On Apr 23, 2020, at 9:41 AM, Graham Samuel via use-livecode 
>  wrote:
> 
> I am getting rather fed up with the widgets I’ve been trying to use for my 
> mobile app. For example, the iOS button widget (a press button, not a switch) 
> has so few properties that you can’t change the colour of the text in any way 
> I could see and sometimes mine turn out blue or red for no apparent reason. 
> Hoping that other properties were just not showing up, I tried
> 
>  put the properties of widget “myWidget”
> 
> in the message box and got nothing, so I don’t know how to proceed. 
> 
> I also hate that the object doesn’t have a label separate from its name. I 
> would never recommend anyone to put spaces in names of objects for scripting, 
> but of course they’re essential for many kinds of label seen by a user, so 
> the two different strings which work in normal LC are essential, in my 
> opinion.
> 
> Oh dear, this has some danger of becoming a rant…
> 
> Graham
> ___
> 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

Widget Properties

[Graham Samuel via use-livecode]

I am getting rather fed up with the widgets I’ve been trying to use for my 
mobile app. For example, the iOS button widget (a press button, not a switch) 
has so few properties that you can’t change the colour of the text in any way I 
could see and sometimes mine turn out blue or red for no apparent reason. 
Hoping that other properties were just not showing up, I tried

  put the properties of widget “myWidget”

in the message box and got nothing, so I don’t know how to proceed. 

I also hate that the object doesn’t have a label separate from its name. I 
would never recommend anyone to put spaces in names of objects for scripting, 
but of course they’re essential for many kinds of label seen by a user, so the 
two different strings which work in normal LC are essential, in my opinion.

Oh dear, this has some danger of becoming a rant…

Graham
___
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: widget properties

[Bob Sneidar via use-livecode]

+1 Sounds like a good idea. The only bugaboo I see is if the properties of a 
widget were in some other format than an LC string, but I don't know that. 

Bob S


> On Feb 24, 2018, at 12:19 , Richard Gaskin via use-livecode 
>  wrote:
> 
> [This message was identified as a phishing scam. Learn about phishing at 
> http://aka.ms/LearnAboutPhishing]
> 
> Brian Milby wrote:
> 
> >> > Brian M. wrote:
> >> > One other thing that could be done is to extend the export to
> >> > include everything that the engine knows about the widget (i.e.
> >> > add the properties array to it).
> >>
> >> The widget author can already do that by defining a list of
> >> persistent properties. Why should the engine override that?
> >
> > I see this as a unification rather than override.
> 
> Exactly.  My request is almost exactly as you worded it, but in reverse:
> rather than adding the info obtainable from the universally-supported
> "the properties" to something widget-specific, I'm suggesting the engine
> have an enhancement to add the widget-specific info to the
> universally-supported "the properties" info.
> 
> This suggestion would seem to address hh's concern as well:
> > The documentation and property-infos are a *lot* of work and will
> > raise the price of a widget (if not free), just as with standalones
> > or externals.
> 
> By having an engine-level enhancement to include the values already
> supplied by the widget per the widget spec included in the existing "the
> properties" function, we would then have one universal array to work
> with which would adequately describe any object with no additional work
> needed from any widget developer.
> 
> Consider the LC IDE's Inspector:  to populate its controls it obtains
> "the properties" from all LC-native objects, and "the properties" +
> widget-specific info from widgets.
> 
> If the engine included the widget-specific info in "the properties", the
> Inspector need only query one place to obtain all relevant info about an
> object.
> 
> And given that "the properties" was introduced to provide a universal
> way of obtaining object info, and that widgets were introduced as a way
> to provide native-like objects without requiring engine-level
> implementation, honoring the purpose of "the properties" by extending it
> to include widget-specific info would seem every bit as useful as having
> "the properties" has been until the introduction of widgets.
> 
> --
> 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: widget properties

[Richard Gaskin via use-livecode]

Ali Lloyd wrote:

> Essentially my point of view is that a properties property should
> return all properties. Otherwise it can't really work with widgets.

Would it simplify things if what is needed for widgets is done for 
widgets, and the current data derived from engine-native objects remains 
as-is?


--
 Richard Gaskin
 Fourth World Systems

___
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: widget properties

[Ali Lloyd via use-livecode]

You didn't misunderstand, that is (almost) exactly what I'm suggesting
(once we had import/export for all objects), although I think the way set
works should probably be tweaked so that we *don't* do any manual fettling
- we just document that setting certain groups of properties via the
properties is undefined behavior. If you want to set *all* the properties
of an object to the same as another, don't do it like that, use
export/import instead.

Essentially my point of view is that a properties property should return
all properties. Otherwise it can't really work with widgets. The manual
fettling for the order of properties to set isn't really compatible with
the fact that widget authors can define properties in innumerable ways that
we don't know in advance, unless we force widget authors to provide the
equivalent of the engine's s_preprocess_props.

I just realised though that you can't set if it's a function, so it would
have to be a property, and then you couldn't include the properties
property :-(

On Mon, Feb 26, 2018 at 3:20 AM Monte Goulding via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> I must have misunderstood. I thought you were proposing adding all
> gettable properties to the properties and not changing the way set works
> (i.e. iterating all elements and setting them one at a time).
>
> Cheers
>
> Monte
>
___
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: widget properties

[Brian Milby via use-livecode]

Looking at the source, when a stack is saved, here is the general flow for
an individual widget (widget.cpp):

OnSave called to get internal widget state (array)
Write uint1 OT_WIDGET to indicate a widget
Save the object state
Save the widget kind
Save the internal widget state
Save the property sets

Suggestion is to add the object state ($object) and property sets ($props)
to the existing export array.

Once the object state function was in place, most of the work to add other
classic controls would already be done.

The couple of OnLoad handlers that I’ve looked into seem to handle extra
data fine since it is just ignored. It gets lost on save though. This is
some of the things that came to light when vertical was added to the
segmented control. This should not have any impact to this idea.
On Sun, Feb 25, 2018 at 10:10 PM Brian Milby  wrote:

> I’m not sure I follow.  The proposal I’m making is no different than what
> the engine does today, just allowing the same information to be saved to an
> array.  The internal state of the widget is the same as what would be used
> on export/import.  It just adds the other properties (rect, ...) to the
> array.
>
> I’ll need to look again, but I think that export uses OnSave to get the
> array.  Import uses OnLoad.  This would save the step of setting the other
> properties.
>
> On Sun, Feb 25, 2018 at 10:02 PM hh via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> > Brian M. wrote:
>> > My 0.02 is that export should mirror what the engine saves to the stack
>> > file such that import could exactly recreate an object (with some logic
>> on
>> > how to handle ID collisions - overwrite, throw error, assign new ID...)
>>
>> If you are developing and testing a widget this would make you crazy.
>> What I want are some persistent properties from "OnSave" and "OnLoad" but
>> NOT the saved state of a probable buggy widget.
>>
>> And if I open a stack half a year later while the widget was updated,
>> then I want, as it is currently, the new version without deleting and
>> reinstalling all widgets of that kind (think of a stack that has a lot of
>> svg-icon-widgets).
>>
>>
>> ___
>> 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: widget properties

[Brian Milby via use-livecode]

I’m not sure I follow.  The proposal I’m making is no different than what
the engine does today, just allowing the same information to be saved to an
array.  The internal state of the widget is the same as what would be used
on export/import.  It just adds the other properties (rect, ...) to the
array.

I’ll need to look again, but I think that export uses OnSave to get the
array.  Import uses OnLoad.  This would save the step of setting the other
properties.

On Sun, Feb 25, 2018 at 10:02 PM hh via use-livecode <
use-livecode@lists.runrev.com> wrote:

> > Brian M. wrote:
> > My 0.02 is that export should mirror what the engine saves to the stack
> > file such that import could exactly recreate an object (with some logic
> on
> > how to handle ID collisions - overwrite, throw error, assign new ID...)
>
> If you are developing and testing a widget this would make you crazy.
> What I want are some persistent properties from "OnSave" and "OnLoad" but
> NOT the saved state of a probable buggy widget.
>
> And if I open a stack half a year later while the widget was updated,
> then I want, as it is currently, the new version without deleting and
> reinstalling all widgets of that kind (think of a stack that has a lot of
> svg-icon-widgets).
>
>
> ___
> 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: widget properties

[Brian Milby via use-livecode]

Exactly... that would be the overwrite option I was thinking about.

import object from array tMyArray [with OverwriteID]
import object from array tMyArray [with AutoID]

If neither option specified and the ID exists, an error would be thrown.
On Sun, Feb 25, 2018 at 9:52 PM Monte Goulding via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
>
> > On 26 Feb 2018, at 2:47 pm, Brian Milby  wrote:
> >
> > My 0.02 is that export should mirror what the engine saves to the stack
> file such that import could exactly recreate an object (with some logic on
> how to handle ID collisions - overwrite, throw error, assign new ID...)
>
> Yes that makes sense. It would also be nice if we could somehow apply that
> exported data to an existing object.
>
> Cheers
>
> Monte
> ___
> 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: widget properties

[hh via use-livecode]

> Brian M. wrote:
> My 0.02 is that export should mirror what the engine saves to the stack
> file such that import could exactly recreate an object (with some logic on
> how to handle ID collisions - overwrite, throw error, assign new ID...)

If you are developing and testing a widget this would make you crazy.
What I want are some persistent properties from "OnSave" and "OnLoad" but
NOT the saved state of a probable buggy widget.

And if I open a stack half a year later while the widget was updated,
then I want, as it is currently, the new version without deleting and
reinstalling all widgets of that kind (think of a stack that has a lot of
svg-icon-widgets).


___
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: widget properties

[Monte Goulding via use-livecode]

> On 26 Feb 2018, at 2:47 pm, Brian Milby  wrote:
> 
> My 0.02 is that export should mirror what the engine saves to the stack file 
> such that import could exactly recreate an object (with some logic on how to 
> handle ID collisions - overwrite, throw error, assign new ID...)

Yes that makes sense. It would also be nice if we could somehow apply that 
exported data to an existing object.

Cheers

Monte
___
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: widget properties

[Brian Milby via use-livecode]

My 0.02 is that export should mirror what the engine saves to the stack
file such that import could exactly recreate an object (with some logic on
how to handle ID collisions - overwrite, throw error, assign new ID...)
On Sun, Feb 25, 2018 at 9:21 PM Monte Goulding via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
>
> > On 26 Feb 2018, at 9:45 am, Ali Lloyd via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> >> No there isn't, because if you aren't using it to completely import an
> > object (i.e. set the properties of obj1 to the properties of obj2) it's
> > your lookout what properties you include in the array to set - so just
> > don't include all the forms of text.
>
> I must have misunderstood. I thought you were proposing adding all
> gettable properties to the properties and not changing the way set works
> (i.e. iterating all elements and setting them one at a time).
>
> Cheers
>
> Monte
> ___
> 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: widget properties

[Monte Goulding via use-livecode]

> On 26 Feb 2018, at 9:45 am, Ali Lloyd via use-livecode 
>  wrote:
> 
>> No there isn't, because if you aren't using it to completely import an
> object (i.e. set the properties of obj1 to the properties of obj2) it's
> your lookout what properties you include in the array to set - so just
> don't include all the forms of text.

I must have misunderstood. I thought you were proposing adding all gettable 
properties to the properties and not changing the way set works (i.e. iterating 
all elements and setting them one at a time).

Cheers

Monte
___
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: widget properties

[Ali Lloyd via use-livecode]

>
>
> > If we have export for all object types, there's no
> > reason (other than backwards compatibility) that the properties property
> > couldn't return the value of every single gettable property of an object
> > type.
>
> Yes there is. If we include all the different forms of text for example
> (htmlText, text, rtfText, styledText) then we have to have even more
> complicated precedence rules than we currently do when setting.
>
> No there isn't, because if you aren't using it to completely import an
object (i.e. set the properties of obj1 to the properties of obj2) it's
your lookout what properties you include in the array to set - so just
don't include all the forms of text.
___
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: widget properties

[Richard Gaskin via use-livecode]

Monte wrote:

> I think probably the VCS use-case is a non-issue right now.

Agreed.


>> If we have export for all object types, there's no
>> reason (other than backwards compatibility) that the properties
>> property couldn't return the value of every single gettable property
>> of an object type.
>
> Yes there is. If we include all the different forms of text for
> example (htmlText, text, rtfText, styledText) then we have to have
> even more complicated precedence rules than we currently do when
> setting.

FWIW, if it keeps things simpler I wouldn't change anything at all in 
"the properties" beyond adding the export info for widgets.


Below I've copied the list of keys from getting "the properties" of a 
field. Neither rtfText nor even text are there, because both are 
permutations of the one form that covers what's needed to reproduce 
field contents, htmlText.


Apparently a fair bit of thought went into "the properties".  Unless 
there's a show-stopping need to alter it, I'd leave it as-is, add the 
widget info, and move on to other tasks.


If something more complete or somehow different is needed in the future, 
the future would be a good time to address it. :)  That is, maintain 
what we have, and take your time thinking through a new form of this 
sort of array representation of an object as that need becomes defined. 
As much as I appreciate the interest in this, my own needs are modest, 
and I know that you folks have quite a queue filled with other things.



altId
autoHilite
autoTab
backColor
backPattern
behavior
blendLevel
borderColor
borderPattern
borderWidth
bottomColor
bottomPattern
cantSelect
colorOverlay
cursorMovement
disabled
dontSearch
dontWrap
dropShadow
firstIndent
fixedLineHeight
focusColor
focusPattern
foreColor
forePattern
hGrid
hiliteColor
hilitedLines
hilitePattern
hScroll
hScrollbar
htmlText
id
ink
innerGlow
innerShadow
layer
layerMode
listBehavior
lockLoc
lockText
margins
multipleHilites
name
noncontiguousHilites
opaque
outerGlow
rect
scrollbarWidth
shadow
shadowColor
shadowOffset
shadowPattern
sharedText
showBorder
showFocusBorder
showLines
style
tabStops
textAlign
textDirection
textFont
textHeight
textSize
textStyle
threeD
threeDHilite
toggleHilites
toolTip
topColor
topPattern
traversalOn
vGrid
visible
vScroll
vScrollbar

--
 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: widget properties

[Monte Goulding via use-livecode]

> On 26 Feb 2018, at 2:57 am, Ali Lloyd via use-livecode 
>  wrote:
> 
> The trick is to ensure that the VCS use-case
> can be extricated.

I think probably the VCS use-case is a non-issue right now. I’m not sure if 
anyone is still using lcVCS but script only stacks + stackFiles with no scripts 
is significantly simpler to deal with. Either way export object covers that 
better.

> If we have export for all object types, there's no
> reason (other than backwards compatibility) that the properties property
> couldn't return the value of every single gettable property of an object
> type.

Yes there is. If we include all the different forms of text for example 
(htmlText, text, rtfText, styledText) then we have to have even more 
complicated precedence rules than we currently do when setting.

I would suggest if we can look at all the metadata we need in the IDE about an 
object property and provide a way to access as much of that as possible by 
introspecting the object most people would be happy regardless of whether we 
provide an array prop to get and set it in one hit. Just about all the data is 
there already in the property tables.

Cheers

Monte
___
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: widget properties

[Richard Gaskin via use-livecode]

Ali Lloyd wrote:

> Richard wrote:
>> For example, taking the delta between two objects gives you a great
>> way to concisely express what would be needed to reproduce one from
>> the other. Such conciseness is esp. useful in Internet applicationsL
>
> These seem to me to be perfect examples of why export  to tVar
> would be useful to extend to all objects.

Whether we use what we've been using for all types, or add all types to 
the newer currently-widget-specific syntax, is fine by me.


It's encouraging that you share an interest in this.  Whatever syntax 
you prefer would be fine by me.



>>  > It is not correct to say that the properties property is used to
>>  > create the property inspector
>>
>> I don't know anyone who said that.  But imagine how much simpler it
>> would be to make an Inspector if "the properties" were completed to
>> handle this new class of objects.
>>
> You did, in your earlier email ;-)

If I did say that it does rather than that it could, I'll trust your 
memory on that.  I have been prone to optimism.


In the conversation we're having I didn't, because I've recently poked 
around in the IDE enough to have a sense of how the Inspector works.


Chipp, Geoff, Ken, Pete, I, and others use "the properties" for our 
respective prop viewing/editing tools.  This may be why revNavigator's 
prop sheet doesn't support widgets; Chipp's doesn't either, and 
discovering that my own doesn't is what prompted this thread.




> Unless you meant 'the properties' abstractly. If that's the case then
> there is such a function - it is in the IDE library and the IDE does
> use it on all object types to generate the property inspector.

Yes, as I wrote to hh yesterday this isn't a show-stopper by any means. 
LC is a very flexible language, and there's little we can't script.


My request here to treat widgets like first-class objects using the same 
long-standing mechanism we enjoy for all other objects is more akin to 
the recent extension of the "files" and "folders" functions:


It never killed any of us to have to write our own custom functions to 
get the working directory, change to the one we're interested in, get 
the files/folders, and restore the working directory to what it was, and 
then return the list. But it's oh so very convenient to have that 
functionality built into the engine now.


Same with obtaining a prop array:  those of us who make good use of "the 
properties" won't fall over dead if we have to add additional code to 
support one newer object class. It would just be oh so very convenient 
to have that built into the engine.


If it were, all tools and libraries written to use "the properties" 
would work for widgets as well.


As it is, widgets are unsupported by all of them, until every author 
gets around to adding the additional code needed for that one object type.


For those invested in promoting widget adoption, the choice would seem 
clear.




> I'm not trying to argue that we shouldn't extend the properties
> property - actually efficiency may indeed be one of the best reasons
> in terms of being able to set a bunch of properties in one go. I'm
> just trying to gather information to figure out the priority of such
> a thing.

Your interest is much appreciated.


>> I'm familiar with the existing mechanisms, but help me understand:
>> which scriptable properties would a widget have which would not be of
>> interest to a scripter?
>
> I didn't say they aren't of interest to the scripter, I said you might
> not want to present them in a property inspector. And it's not just
> widgets, all objects have properties that are not really relevant to
> the property inspector. Most obviously, the properties property.

Of course (though it does conjure amusing ideas of recursion; "It's 
properties all the way down" ).  And the script property as well, 
handled separately given its special role.  I'm fine with continuing that.



> Others are, for example, the noncontiguousHilites of a standard text
> field, or the menuHistory of a default button. Many widgets have other
> properties that overlap, for example the itemArray of the navigation
> bar, which overlaps with (in fact subsumes) the itemLabels, itemIcons,
> itemSelectedIcons etc.

Thank you, those are very good examples.

The completeness of "the properties" does not oblige any toolmaker to 
present information in ways that aren't useful.




> Again, I am not arguing that there shouldn't be a properties property
> extended to widgets. I see that efficiency and property sheets are
> reasonable use-cases for it. The trick is to ensure that the VCS
> use-case can be extricated. If we have export for all object types,
> there's no reason (other than backwards compatibility) that the
> properties property couldn't return the value of every single gettable
> property of an object type.
>
> I wonder if the properties of  should actually be a function, to
> avoid there always being a property that (for obvious reasons) 

Re: widget properties

[Ali Lloyd via use-livecode]

>
> My interest this morning came from a property sheet I build some years
> ago as an alternative to an inspector.  There are many good reasons why
> a property sheet is a much better fit for an IDE, but we can save that
> for another thread.
>
> Another reason Kevin asked Scott Raney to add "the properties" as a
> universal representation of object props back around '00 was for the
> rapid things we can do for new object creation.
>
> As an array, the value lends itself particularly well for a wide range
> of needs.
>
> For example, taking the delta between two objects gives you a great way
> to concisely express what would be needed to reproduce one from the
>
other. Such conciseness is esp. useful in Internet applicationsL


These seem to me to be perfect examples of why export  to tVar would
be useful to extend to all objects.


> Another would be transferable styles.  I can make a button or field how
> I like it, and then store only the things I care about to represent that
> "style".  Later I can union that subset with "the properties" of another
> object of that type and have them applied in one simple and highly
> efficient move.
>
> There may be other reasons this was requested as a universal way of
> representing object properties.  That's just the short list of things
> that come to mind off the top of my head right now.
>

>  > It is not correct to say that the properties property is used to
>  > create the property inspector
>
> I don't know anyone who said that.  But imagine how much simpler it
> would be to make an Inspector if "the properties" were completed to
> handle this new class of objects.
>
>
You did, in your earlier email ;-)

> Consider the LC IDE's Inspector:  to populate its controls it obtains
> "the properties" from all LC-native objects, and "the properties" +
> widget-specific info from widgets.

In fact, add that to the use-case list above.
>
> Having one universal means of getting and setting object properties en
> masse is very helpful.
>

Unless you meant 'the properties' abstractly. If that's the case then there
is such a function - it is in the IDE library and the IDE does use it on
all object types to generate the property inspector.


> And we've had it for more than a decade and a half.
>
> And we have it still, except for one new class of objects, widgets.
>
> If we extend this mechanism to include the data the engine already knows
> about properties, widgets will be elevated to first class objects like
> anything else.
>
> Isn't having widgets behave more like engine-native controls the reason
> we use them over compound groups?
>
>
I'm not trying to argue that we shouldn't extend the properties property -
actually efficiency may indeed be one of the best reasons in terms of being
able to set a bunch of properties in one go. I'm just trying to gather
information to figure out the priority of such a thing.


>  >- that is in fact done from property definition files. There are things
>  > that are properties that you might not want to present in a property
>  > inspector, and there are things that you might want to present in the
>  > property inspector that are not strictly properties. Hence we maintain
>  > these lists:
>  >
>
> https://github.com/livecode/livecode-ide/tree/develop/Toolset/resources/supporting_files/property_definitions
>
> I'm familiar with the existing mechanisms, but help me understand: which
> scriptable properties would a widget have which would not be of interest
> to a scripter?
>

I didn't say they aren't of interest to the scripter, I said you might not
want to present them in a property inspector. And it's not just widgets,
all objects have properties that are not really relevant to the property
inspector. Most obviously, the properties property. Others are, for
example, the noncontiguousHilites of a standard text field, or the
menuHistory of a default button. Many widgets have other properties that
overlap, for example the itemArray of the navigation bar, which overlaps
with (in fact subsumes) the itemLabels, itemIcons, itemSelectedIcons etc.
See the navigation bar's itemArray editor in the PI - in my view this is
much nicer than a set of fields. Another type would be transient properties
of mobile native objects - eg the 'focused' property of the android native
field which is not saved with the object. It is completely unuseful to set
this property via PI in the IDE, but still needs to be a property so you
can set it from script. As the existence of such properties is subject to
the whims of the widget author, they could crop up anywhere, hence the
desire to make the ones that *should* show up part of the metadata.


>
 > Because the 'classic controls' are somewhat multipurpose, the notion
>  > of control type isn't fine-grained enough to use the properties
>  > property for a good property inspector.
>
> Agreed.  Another good argument for a property sheet, but that's for
> another thread.
>

I don't understand how that's an argument 

Re: widget properties

[Mark Wieder via use-livecode]

On 02/24/2018 03:08 PM, Ali Lloyd via use-livecode wrote:


The VCS-related use case for an expanded properties property still exists
though, as far as I can tell, although 'properties' is kind of a bad name
for it. Actually I think it might be better to add 'export' syntax for
classic controls. The nice thing about the export syntax is that you get
exactly the distinct pieces of information required to reconstruct the
widget (according to the widget author's implementation). It might actually
be a completely distinct representation of the widget state than that
provided by a list of properties and their values (although in practice,
it's usually a subset of the properties).


I've always found the property lists in the engine clumsy and hard to 
maintain, in addition to them not being accessible outside the engine 
other than getting a subset through "the properties".


It's actually very easy to reconstruct objects with a property list that 
may contain non-settable entries. I do this with preference files all 
the time to stay out of trouble...


local tList -- contains the cr-separated properties as
-- tPropertyNametValue

local tObject -- the object whose properties we're setting
local tProperty, tValue
repeat for each line tLine in tList
  put item 1 of tLine into tProperty
  put item 2 of tLine into tValue
  try
set the tProperty of tObject to tValue
  end try
end repeat

--
 Mark Wieder
 ahsoftw...@gmail.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: widget properties

[Richard Gaskin via use-livecode]

hh wrote:

>> Richard G. wrote:
>> What's missing is support for the universal method by which we can
>> obtain property info, "the properties" function.
>
> In order to work with a widget you have to know what the single
> properties do.

That is true of all objects of all properties.


> I can't see what should be the purpose of such a "full list".

Consider the list I included in my reply to Ali, and spend some time 
experimenting.  LC's associative arrays are very powerful and very 
flexible.  With union and intersect, even more so.  All sorts of rapid 
object styling, replication, serializing for transport, and so much more 
becomes trivial and fun.



Sure, I could write my own functions to do this.  And if I'm the only 
one who's interested it wouldn't take me long.


But the ease and power of this way of working with "the properties" has 
become second nature to me because many years ago Kevin had the insight 
to request that array from the then-engine-maintainer.  If he hadn't 
asked for that, I might still be stuck in the ancient xTalk way of doing 
these things, manually maintaining lists of properties and slavishly 
applying them one at a time in line after line of long blocks of code.


So I'm good either way.  I'm just thinking about the next generation of 
LiveCode scripters.


If we abandon "the properties" as the universal array representation for 
all types, we either lose the value of that function by making it into a 
"sometimes" thing, or reduce the value of widgets by not treating them 
as "real" objects.


--
 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: widget properties

[Richard Gaskin via use-livecode]

Ali Lloyd wrote:

> Not much has changed since this question was last asked:
> http://lists.runrev.com/pipermail/use-livecode/2015-October/219630.html

So it seems, hence my question. :)


> The question here really is what you want to use the properties
> property for.

My interest this morning came from a property sheet I build some years 
ago as an alternative to an inspector.  There are many good reasons why 
a property sheet is a much better fit for an IDE, but we can save that 
for another thread.


Another reason Kevin asked Scott Raney to add "the properties" as a 
universal representation of object props back around '00 was for the 
rapid things we can do for new object creation.


As an array, the value lends itself particularly well for a wide range 
of needs.


For example, taking the delta between two objects gives you a great way 
to concisely express what would be needed to reproduce one from the 
other. Such conciseness is esp. useful in Internet applications.


Another would be transferable styles.  I can make a button or field how 
I like it, and then store only the things I care about to represent that 
"style".  Later I can union that subset with "the properties" of another 
object of that type and have them applied in one simple and highly 
efficient move.


There may be other reasons this was requested as a universal way of 
representing object properties.  That's just the short list of things 
that come to mind off the top of my head right now.




> It is not correct to say that the properties property is used to
> create the property inspector

I don't know anyone who said that.  But imagine how much simpler it 
would be to make an Inspector if "the properties" were completed to 
handle this new class of objects.


In fact, add that to the use-case list above.

Having one universal means of getting and setting object properties en 
masse is very helpful.


And we've had it for more than a decade and a half.

And we have it still, except for one new class of objects, widgets.

If we extend this mechanism to include the data the engine already knows 
about properties, widgets will be elevated to first class objects like 
anything else.


Isn't having widgets behave more like engine-native controls the reason 
we use them over compound groups?



>- that is in fact done from property definition files. There are things
> that are properties that you might not want to present in a property
> inspector, and there are things that you might want to present in the
> property inspector that are not strictly properties. Hence we maintain
> these lists:
> 
https://github.com/livecode/livecode-ide/tree/develop/Toolset/resources/supporting_files/property_definitions


I'm familiar with the existing mechanisms, but help me understand: which 
scriptable properties would a widget have which would not be of interest 
to a scripter?



> Because the 'classic controls' are somewhat multipurpose, the notion
> of control type isn't fine-grained enough to use the properties
> property for a good property inspector.

Agreed.  Another good argument for a property sheet, but that's for 
another thread.


Either way, it's a settable value which can be scripted.

Scripting them will be simpler and more enjoyable to write with one 
consistent mechanism for all object types.


All I'm suggesting is that we remove a limitation that makes widgets 
second-class citizens in the LC object world.


And since the information is already available, it would seem a 
relatively easy task, at least as far as powerful feature-completeness 
requests go, yes?


--
 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: widget properties

[Brian Milby via use-livecode]

@Ali... I’ve been mulling over the very idea of extending the export
mechanism. What I would propose is to add an $object key that would contain
the engine related things required to recreate the widget. The same could
be done for any LC object (using $kind to identify the classic
control/object type or possibly just “classic control”). Possibly more than
one additional key. In theory, you could export a whole stack as an array
this way.

The export code currently just processes widgets, but a modification there
would not be that difficult. The functions used to load/save an object
would need mirror functions to load/return an array. Once that is done,
things higher up would need similar treatment (card/stack). I just have not
had the time to sit down and try to implement my thoughts.


> The VCS-related use case for an expanded properties property still exists
> though, as far as I can tell, although 'properties' is kind of a bad name
> for it. Actually I think it might be better to add 'export' syntax for
> classic controls. The nice thing about the export syntax is that you get
> exactly the distinct pieces of information required to reconstruct the
> widget (according to the widget author's implementation). It might actually
> be a completely distinct representation of the widget state than that
> provided by a list of properties and their values (although in practice,
> it's usually a subset of the properties).
>
___
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: widget properties

[hh via use-livecode]

> Richard G. wrote:
> What's missing is support for the universal method by which we can 
> obtain property info, "the properties" function.

In order to work with a widget you have to know what the single properties
do. I can't see what should be the purpose of such a "full list". 

> Given that the engine is apparently already able to obtain that info, 
> adding it to the universal mechanism for this should seem short work, no?

Yes, this last part. Using "the properties" you can get what's implemented
for use in the property inspector, but NO short work for the author's part:

(a) The LCS-LCB conversions are not simple, e.g.
= Number-Text conversions (for lists),
= LCB hast true lists, LCS not,
= LCS has arrays with numbers as keys, LCB not.
The widget's author has to implement all such conversions.

(b) The property inspector has not enough (appropriate) tabs for a widget
with a lot of properties.

With my first widgets the properties-part needed up to 70% of work and
code lines. I have it down to 10% now and I will reduce that for new and
updated widgets to a short list (which is not a property).
Will introduce preferences files instead.


___
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: widget properties

[Ali Lloyd via use-livecode]

Not much has changed since this question was last asked:
http://lists.runrev.com/pipermail/use-livecode/2015-October/219630.html

The question here really is what you want to use the properties property
for. It is not correct to say that the properties property is used to
create the property inspector - that is in fact done from property
definition files. There are things that are properties that you might not
want to present in a property inspector, and there are things that you
might want to present in the property inspector that are not strictly
properties. Hence we maintain these lists:
https://github.com/livecode/livecode-ide/tree/develop/Toolset/resources/supporting_files/property_definitions

Because the 'classic controls' are somewhat multipurpose, the notion of
control type isn't fine-grained enough to use the properties property for a
good property inspector. In the property definition files, they are split
up into control types (more like how widgets should be, i.e. one widget
kind per distinct functionality)

The VCS-related use case for an expanded properties property still exists
though, as far as I can tell, although 'properties' is kind of a bad name
for it. Actually I think it might be better to add 'export' syntax for
classic controls. The nice thing about the export syntax is that you get
exactly the distinct pieces of information required to reconstruct the
widget (according to the widget author's implementation). It might actually
be a completely distinct representation of the widget state than that
provided by a list of properties and their values (although in practice,
it's usually a subset of the properties).



On Sat, Feb 24, 2018 at 10:11 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> hh wrote:
>
>  >> Richard G. wrote:
>  >> I'm suggesting the engine have an enhancement to add
>  >> the widget-specific info to the  universally-supported
>  >> "the properties" info.
>  >
>  > It would be possible to simply add all the info that the property
>  > inspector can display. But that can also easily be scripted by the
>  > user of the widget.
>  > Or use the demo-stacks of the widget's author (I usually provide
>  > these) which contain (parts of) setter and getter scripts.
>
> Exactly.  There are many workarounds available.
>
> What's missing is support for the universal method by which we can
> obtain property info, "the properties" function.
>
> Given that the engine is apparently already able to obtain that info,
> adding it to the universal mechanism for this should seem short work, no?
>
> --
>   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: widget properties

[Richard Gaskin via use-livecode]

hh wrote:

>> Richard G. wrote:
>> I'm suggesting the engine have an enhancement to add
>> the widget-specific info to the  universally-supported
>> "the properties" info.
>
> It would be possible to simply add all the info that the property
> inspector can display. But that can also easily be scripted by the
> user of the widget.
> Or use the demo-stacks of the widget's author (I usually provide
> these) which contain (parts of) setter and getter scripts.

Exactly.  There are many workarounds available.

What's missing is support for the universal method by which we can 
obtain property info, "the properties" function.


Given that the engine is apparently already able to obtain that info, 
adding it to the universal mechanism for this should seem short work, no?


--
 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: widget properties

[hh via use-livecode]

> Richard G. wrote:
> I'm suggesting the engine have an enhancement to add the widget-specific info
> to the  universally-supported "the properties" info.

It would be possible to simply add all the info that the property inspector
can display. But that can also easily be scripted by the user of the widget.
Or use the demo-stacks of the widget's author (I usually provide these) which
contain (parts of) setter and getter scripts.
[You can set the settable properties to an array. So you can get in just the 
same
way an array of gettable properties. This needs only a list of gettable/settable
properties in the dictionary.]

> Brian M. wrote:
> Now I’m really confused:
> 
> put the properties of widget id 1004 into tA
> 
> Results in an empty tA. If I put something into tA[“rect”] and then set the
> properties to tA then it does move to that rect.

That's correct(*). Setting tA is just an array of (valid) properties to set,
needed also when using a widget as popup.
The properties returns the widget property "properties" which is usually empty.

(*) "rect" is a LCS property of the widget, the widget author can currently set
such properties only by posting to the widget's script object.
From that it is a bug, all gettable/settable LCS properties of the widget
(see https://livecode.com/topic/accessing-livecode-control-properties/)
should populate the "the properties"-array (this list is missing "rect").


___
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: widget properties

[Richard Gaskin via use-livecode]

Brian Milby wrote:

>> > Brian M. wrote:
>> > One other thing that could be done is to extend the export to
>> > include everything that the engine knows about the widget (i.e.
>> > add the properties array to it).
>>
>> The widget author can already do that by defining a list of
>> persistent properties. Why should the engine override that?
>
> I see this as a unification rather than override.

Exactly.  My request is almost exactly as you worded it, but in reverse: 
 rather than adding the info obtainable from the universally-supported 
"the properties" to something widget-specific, I'm suggesting the engine 
have an enhancement to add the widget-specific info to the 
universally-supported "the properties" info.


This suggestion would seem to address hh's concern as well:
> The documentation and property-infos are a *lot* of work and will
> raise the price of a widget (if not free), just as with standalones
> or externals.

By having an engine-level enhancement to include the values already 
supplied by the widget per the widget spec included in the existing "the 
properties" function, we would then have one universal array to work 
with which would adequately describe any object with no additional work 
needed from any widget developer.


Consider the LC IDE's Inspector:  to populate its controls it obtains 
"the properties" from all LC-native objects, and "the properties" + 
widget-specific info from widgets.


If the engine included the widget-specific info in "the properties", the 
Inspector need only query one place to obtain all relevant info about an 
object.


And given that "the properties" was introduced to provide a universal 
way of obtaining object info, and that widgets were introduced as a way 
to provide native-like objects without requiring engine-level 
implementation, honoring the purpose of "the properties" by extending it 
to include widget-specific info would seem every bit as useful as having 
"the properties" has been until the introduction of widgets.


--
 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: widget properties

[Brian Milby via use-livecode]

Now I’m really confused:

put the properties of widget id 1004 into tA

Results in an empty tA. If I put something into tA[“rect”] and then set the
properties to tA then it does move to that rect. Is that just my 2
computers (Mac and Win10)? I checked 9DP11 and 8.1.7 (will get the latest 8
now though).
On Sat, Feb 24, 2018 at 1:41 PM Brian Milby  wrote:

> > Brian M. wrote:
>> > One other thing that could be done is to extend the export to include
>> > everything that the engine knows about the widget (i.e. add the
>> > properties array to it).
>>
>> The widget author can already do that by defining a list of persistent
>> properties. Why should the engine override that?
>
>
> I see this as a unification rather than override.  When a stack is saved
> it asks each widget what it wants to save but also includes other
> properties too (rect, layer, id, ...).
>
___
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: widget properties

[Brian Milby via use-livecode]

> > Brian M. wrote:
> > One other thing that could be done is to extend the export to include
> > everything that the engine knows about the widget (i.e. add the
> > properties array to it).
>
> The widget author can already do that by defining a list of persistent
> properties. Why should the engine override that?


I see this as a unification rather than override.  When a stack is saved it
asks each widget what it wants to save but also includes other properties
too (rect, layer, id, ...).
___
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: widget properties

[hh via use-livecode]

> Richard G. wrote:
> When we query the properties of any object, we get an array that lets us 
> understand and even reproduce that object easily.
> 
> Except with widgets.
> 
> When we query the properties of a widget we get only the subset of 
> properties common to all widgets, but none of the properties unique to 
> any given widget type.
> 
> Should the widget spec be enhanced to map its unique properties to be 
> included among "the properties" array?

A widget is not an ordinary "object". It's more like a micro-standalone.
You'll get what the author provides, as with a standalone or an external.

The documentation and property-infos are a *lot* of work and will raise
the price of a widget (if not free), just as with standalones or externals.

> Brian M. wrote:
> One other thing that could be done is to extend the export to include
> everything that the engine knows about the widget (i.e. add the
> properties array to it).

The widget author can already do that by defining a list of persistent 
properties. Why should the engine override that?


___
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: widget properties

[Brian Milby via use-livecode]

I meant “does”
To get what you want (if different than above) would require something
defined within each widget to export the desired internal information.
One other thing that could be done is to extend the export to include
everything that the engine knows about the widget (i.e. add the properties
array to it).

Thanks,
Brian
On Sat, Feb 24, 2018 at 10:12 AM Brian Milby  wrote:

> Doe this get what you want:
> export widget to array arrayVar
> On Sat, Feb 24, 2018 at 10:01 AM Richard Gaskin via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> When we query the properties of any object, we get an array that lets us
>> understand and even reproduce that object easily.
>>
>> Except with widgets.
>>
>> When we query the properties of a widget we get only the subset of
>> properties common to all widgets, but none of the properties unique to
>> any given widget type.
>>
>> Should the widget spec be enhanced to map its unique properties to be
>> included among "the properties" array?
>>
>> --
>>   Richard Gaskin
>>   Fourth World Systems
>>
>> ___
>> 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: widget properties

[Brian Milby via use-livecode]

Doe this get what you want:
export widget to array arrayVar
On Sat, Feb 24, 2018 at 10:01 AM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> When we query the properties of any object, we get an array that lets us
> understand and even reproduce that object easily.
>
> Except with widgets.
>
> When we query the properties of a widget we get only the subset of
> properties common to all widgets, but none of the properties unique to
> any given widget type.
>
> Should the widget spec be enhanced to map its unique properties to be
> included among "the properties" array?
>
> --
>   Richard Gaskin
>   Fourth World Systems
>
> ___
> 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

widget properties

[Richard Gaskin via use-livecode]

When we query the properties of any object, we get an array that lets us 
understand and even reproduce that object easily.


Except with widgets.

When we query the properties of a widget we get only the subset of 
properties common to all widgets, but none of the properties unique to 
any given widget type.


Should the widget spec be enhanced to map its unique properties to be 
included among "the properties" array?


--
 Richard Gaskin
 Fourth World Systems

___
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: Widget properties

[Bob Sneidar via use-livecode]

The answer to that question may be academic. But the best answer I can come up 
with is that mobile devices are fundamentally different than desktop devices. 
It's already an amazing thing to get a single layout to display in the various 
desktop operating systems in a consistent manner, and Windows/Mac/Unix/Linux 
are similar enough for that. iOS and Android are vastly different interfaces, 
so to look and behave "natively" on these requires in many instances a 
different kind of object. 

It is not a big chore, but you can create your own "scalable" radio buttons 
from regular buttons and some reasonably high resolution images, or even just 
the images themselves. That is one of the great things about livecode. You can 
with some ingenuity create your own custom controls. 

Bob S


> On Oct 22, 2017, at 05:35 , Pyyhtiä Christer via use-livecode 
>  wrote:
> 
> When fixing a problem with non-scaling radio buttons one solution was to use 
> widget switch button, which can be scaled.
> 
> Now it appears that those buttons do not retain the setup theme, but you need 
> to redo it at every stack startup.  Why not.
> 
> Actually the first question is why can't the LiveCode team make the radio 
> buttons scalable?  Using those on a mobile device you hardly see what the 
> hilite status is.
> 
> 
> Christer Pyyhtiä
> chris...@mindcrea.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

Widget properties

[Pyyhtiä Christer via use-livecode]

When fixing a problem with non-scaling radio buttons one solution was to use 
widget switch button, which can be scaled.

Now it appears that those buttons do not retain the setup theme, but you need 
to redo it at every stack startup.  Why not.

Actually the first question is why can't the LiveCode team make the radio 
buttons scalable?  Using those on a mobile device you hardly see what the 
hilite status is.


Christer Pyyhtiä
chris...@mindcrea.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: Widget Properties

[Mark Waddingham]

On 2015-10-11 02:18, Monte Goulding wrote:

Yes this is an odd one which I’ve queried before. You can now use
export widget to array to get the widget defined properties as they
will be saved. I don’t think this includes the base object properties
like visible, rect, disabled etc though. This is one of the things I
need to investigate if I ever have time to get lcVCS working on LC 8…


Well I added a minimal 'export widget to array' command precisely for 
use by lcVCS (as well as the 'is really a ' operators).


As it stands it returns a standard array structure which encodes the 
internal state required by a widget to reconstruct it's portion of 
things. The eventual aim is that the command will work on any object to 
return its internal structure in a similar way.


The 'parent' properties aren't currently there because none of the 
engine object classes (apart from Widget) currently implement an 
appropriate 'export to array' mechanism; and I figured it would be easy 
enough for you to leverage existing lcVCS code to fetch the small set of 
base properties that also need to be saved.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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: Widget Properties

[Mark Wieder]

On 10/10/2015 11:11 PM, Monte Goulding wrote:


No I haven’t reported it. I got the impression from the discussion that it was 
never intended to support the properties so it wouldn’t happen. I’m about to 
propose (on the engine forum) a refactor of the properties property (which I’ll 
do if they want me to) that will essentially make the properties property self 
maintaining rather than the current situation which means the list of 
properties for an object type needs to be maintained manually. This wasn’t 
possible before the refactor and there’s still a few issues like identifying 
which synonym of a property is the one to use in the properties array and which 
properties should be in the array. The end result will mean the properties of a 
widget will be kind + the standard properties for a control + the standard 
properties for an object.


Oh, please do. I hate that manual updating thing.


--
 Mark Wieder
 ahsoftw...@gmail.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: Widget Properties

[Monte Goulding]

> On 11 Oct 2015, at 5:26 pm, Mark Wieder  wrote:
> 
> On 10/10/2015 11:11 PM, Monte Goulding wrote:
> 
>> No I haven’t reported it. I got the impression from the discussion that it 
>> was never intended to support the properties so it wouldn’t happen. I’m 
>> about to propose (on the engine forum) a refactor of the properties property 
>> (which I’ll do if they want me to) that will essentially make the properties 
>> property self maintaining rather than the current situation which means the 
>> list of properties for an object type needs to be maintained manually. This 
>> wasn’t possible before the refactor and there’s still a few issues like 
>> identifying which synonym of a property is the one to use in the properties 
>> array and which properties should be in the array. The end result will mean 
>> the properties of a widget will be kind + the standard properties for a 
>> control + the standard properties for an object.
> 
> Oh, please do. I hate that manual updating thing.

Here’s what I’m thinking:

http://forums.livecode.com/viewtopic.php?f=66=25563 


If I get the go ahead there’s going to be bucket loads trivial changes and 
stuff like identifying which token is a synonym and which is the official 
token. Things like rect and rectangle are curly because just about nobody uses 
rectangle yet obviously rect is the synonym and has been used in the properties 
property for as long as it has existed...

Cheers

Monte
___
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: Widget Properties

[Monte Goulding]

> On 11 Oct 2015, at 8:08 pm, Mark Waddingham  wrote:
> 
> I don't think we have ever had the intention not to update the properties 
> property to make it work for widgets - we just haven't done so yet.
> 
> Part of the reason for this is that 'the properties' property is quite 
> ill-posed. As it stands it is essentially 'the properties needed to recreate 
> the object' (after the work Monte did on it a couple of years ago); however 
> that concept is difficult as it actually requires hard-coded rules in it to 
> ensure that when you set 'the properties' the properties are set in the 
> correct order.

Oh, yeah that was a headache working all that out...
> 
> Widgets complicate matters somewhat. We make no requirement that the state a 
> widget must preserve to recreate itself be directly related to the properties 
> you actually set (this is actually also true of existing engine controls - 
> hence why there is a need for 'hardcoded' rules in the properties property 
> implementation).
> 
> Now, I'm not saying this situation is ideal, there are various things we 
> could do in the future to make widgets easier to write if they follow the 
> rule that 'there should be a set of persistent properties which don't overlap 
> and fully faithfully allow recreation of the object' (for widgets that claim 
> to be this, they wouldn't need an OnSave / OnLoad handler as the engine could 
> synthesise one).

Nice idea
> 
> However, that doesn't change the fact that currently engine controls don't 
> follow that rule and I'd be loathe to put a restriction on all widgets in 
> that fashion as I cannot forsee the widgets people might wish to write.
> 
> Basically there is a bit distinction between:
> 
>  1) The data you need to recreate an object (this is what lcVCS needs).
> 
>  2) The information you need to provide good introspection on created objects 
> (this is what the IDE / inspectors etc. need).
> 
> Right now, I'd be incredibly dubious if a single 'properties' property could 
> be made to handle both these uses - the lengthy thread a couple of years ago 
> on this precise topic made that absolutely clear.
> 
> Moreover, we have worked quite hard in the IDE to provide a mechanism for (2) 
> - it is what the new property inspector is based on - i.e. APIs for returning 
> information and data about objects in the environment.

Yes, 2 is not really my concern. Having said that I’m not really sure why some 
of the stuff in the manifest (handlers and properties) couldn’t have just been 
done by introspection. Was it necessary to know all that stuff before loading 
the extension? I can understand the dependencies, icon, name etc but the 
handlers and properties seems a missed opportunity as it looks like they are 
available in the exported definitions.

Re 1 a possibility could be some combination of the properties and the exported 
array from OnSave. The properties of a widget could be something like:

- kind
- control & object props (rect, visible etc)
- state
- the stuff in the $state key from the exported array

The only problem here is you can’t just create a blank widget and set the kind 
like this so its probably not worthwhile having kind in there. The rest could 
work fine and the widget author is in full control of how the state array is 
parsed.

However, it may be better to just deprecate the properties and finish the 
export to array stuff.

Cheers

Monte

___
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: Widget Properties

[Mark Waddingham]

On 2015-10-11 12:31, Monte Goulding wrote:

Yes, 2 is not really my concern. Having said that I’m not really sure
why some of the stuff in the manifest (handlers and properties)
couldn’t have just been done by introspection. Was it necessary to
know all that stuff before loading the extension? I can understand the
dependencies, icon, name etc but the handlers and properties seems a
missed opportunity as it looks like they are available in the exported
definitions.


It's not about needing to know it before the extension is loaded, it is 
more about where the appropriate information is stored.


The widget module file stores all the code / embedding related things 
(so compiled bytecode, public handler definitions, property definitions 
etc.) but it doesn't contain anything that might be called 'metadata' - 
things like the name of the editor widget to use for a particular 
property (which is not necessarily related to its type).


Therefore, the manifest file stores all the metadata which is not 
related to the actually running of the widget as well as the exported 
public definitions in an easy to access way. (Basically, we needed 
sideline information which wasn't suitable for inclusion in the actual 
module format, and thus it seemed sensible to put the other information 
the IDE would need in the manifest too rather than it having to both 
interrogate an XML file *and* introspect on the loaded module).


At some point the metadata expressed in widget lcb files might well get 
put into the compiled module blob - but it seemed more expedient whilst 
developing the ideas to keep it separate as it is easier to change the 
XML format that is emitted and read than it is the compiled module blob 
format.



Re 1 a possibility could be some combination of the properties and the
exported array from OnSave. The properties of a widget could be
something like:

- kind
- control & object props (rect, visible etc)
- state
- the stuff in the $state key from the exported array

The only problem here is you can’t just create a blank widget and set
the kind like this so its probably not worthwhile having kind in
there. The rest could work fine and the widget author is in full
control of how the state array is parsed.


That was essentially what I was envisaging.

You shouldn't think of a 'widget' as being something which can change 
its kind. A widget takes on its kind when it is created, so the 'kind' 
property falls into the same class as 'button' or 'field'. So you create 
a widget of a given kind *then* set its state.



However, it may be better to just deprecate the properties and finish
the export to array stuff.


The export to array stuff is the best (future) basis for things such as 
lcVCS. Indeed eventually, if it was rolled out across all engine 
objects, the stackfile format would become 
arrayEncode(stackExportedToArray("my stack")) - although that would 
require a much more efficient arrayEncode format (something which has 
been at the back of my mind for ages - but nothing I've had time to put 
into action).


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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: Widget Properties

[Mark Waddingham]

On 2015-10-11 08:11, Monte Goulding wrote:

On 11 Oct 2015, at 11:36 am, Peter Haworth  wrote:

Thanks Monte.  Maybe I should file a QCC report or have you already 
done so?


No I haven’t reported it. I got the impression from the discussion
that it was never intended to support the properties so it wouldn’t
happen. I’m about to propose (on the engine forum) a refactor of the
properties property (which I’ll do if they want me to) that will
essentially make the properties property self maintaining rather than
the current situation which means the list of properties for an object
type needs to be maintained manually. This wasn’t possible before the
refactor and there’s still a few issues like identifying which synonym
of a property is the one to use in the properties array and which
properties should be in the array. The end result will mean the
properties of a widget will be kind + the standard properties for a
control + the standard properties for an object.


I don't think we have ever had the intention not to update the 
properties property to make it work for widgets - we just haven't done 
so yet.


Part of the reason for this is that 'the properties' property is quite 
ill-posed. As it stands it is essentially 'the properties needed to 
recreate the object' (after the work Monte did on it a couple of years 
ago); however that concept is difficult as it actually requires 
hard-coded rules in it to ensure that when you set 'the properties' the 
properties are set in the correct order.


Widgets complicate matters somewhat. We make no requirement that the 
state a widget must preserve to recreate itself be directly related to 
the properties you actually set (this is actually also true of existing 
engine controls - hence why there is a need for 'hardcoded' rules in the 
properties property implementation).


Now, I'm not saying this situation is ideal, there are various things we 
could do in the future to make widgets easier to write if they follow 
the rule that 'there should be a set of persistent properties which 
don't overlap and fully faithfully allow recreation of the object' (for 
widgets that claim to be this, they wouldn't need an OnSave / OnLoad 
handler as the engine could synthesise one).


However, that doesn't change the fact that currently engine controls 
don't follow that rule and I'd be loathe to put a restriction on all 
widgets in that fashion as I cannot forsee the widgets people might wish 
to write.


Basically there is a bit distinction between:

  1) The data you need to recreate an object (this is what lcVCS needs).

  2) The information you need to provide good introspection on created 
objects (this is what the IDE / inspectors etc. need).


Right now, I'd be incredibly dubious if a single 'properties' property 
could be made to handle both these uses - the lengthy thread a couple of 
years ago on this precise topic made that absolutely clear.


Moreover, we have worked quite hard in the IDE to provide a mechanism 
for (2) - it is what the new property inspector is based on - i.e. APIs 
for returning information and data about objects in the environment.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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: Widget Properties

[Monte Goulding]

> On 11 Oct 2015, at 11:36 am, Peter Haworth  wrote:
> 
> Thanks Monte.  Maybe I should file a QCC report or have you already done so?

No I haven’t reported it. I got the impression from the discussion that it was 
never intended to support the properties so it wouldn’t happen. I’m about to 
propose (on the engine forum) a refactor of the properties property (which I’ll 
do if they want me to) that will essentially make the properties property self 
maintaining rather than the current situation which means the list of 
properties for an object type needs to be maintained manually. This wasn’t 
possible before the refactor and there’s still a few issues like identifying 
which synonym of a property is the one to use in the properties array and which 
properties should be in the array. The end result will mean the properties of a 
widget will be kind + the standard properties for a control + the standard 
properties for an object. 

Cheers

Monte
___
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: Widget Properties

[Peter Haworth]

On Sun, Oct 11, 2015 at 2:08 AM, Mark Waddingham <m...@livecode.com> wrote:

> Moreover, we have worked quite hard in the IDE to provide a mechanism for
> (2) - it is what the new property inspector is based on - i.e. APIs for
> returning information and data about objects in the environment.
>

Hi Mark,
The PI for a widget includes some of the non-widget properties such as ink,
blendlevel, size and position info, text info, and a few others.  Is there
an API to get a list of which non-widget properties are available or are
they hard coded into the PI?

Thanks,

Pete
lcSQL Software <http://www.lcsql.com>
Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
SQLiteAdmin <http://www.lcsql.com/sqliteadmin.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: Widget Properties

[Peter Haworth]

You have my vote to go ahead with that and thanks for proposing it.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 

On Sat, Oct 10, 2015 at 11:44 PM, Monte Goulding <
mo...@sweattechnologies.com> wrote:

>
> > On 11 Oct 2015, at 5:26 pm, Mark Wieder  wrote:
> >
> > On 10/10/2015 11:11 PM, Monte Goulding wrote:
> >
> >> No I haven’t reported it. I got the impression from the discussion that
> it was never intended to support the properties so it wouldn’t happen. I’m
> about to propose (on the engine forum) a refactor of the properties
> property (which I’ll do if they want me to) that will essentially make the
> properties property self maintaining rather than the current situation
> which means the list of properties for an object type needs to be
> maintained manually. This wasn’t possible before the refactor and there’s
> still a few issues like identifying which synonym of a property is the one
> to use in the properties array and which properties should be in the array.
> The end result will mean the properties of a widget will be kind + the
> standard properties for a control + the standard properties for an object.
> >
> > Oh, please do. I hate that manual updating thing.
>
> Here’s what I’m thinking:
>
> http://forums.livecode.com/viewtopic.php?f=66=25563 <
> http://forums.livecode.com/viewtopic.php?f=66=25563>
>
> If I get the go ahead there’s going to be bucket loads trivial changes and
> stuff like identifying which token is a synonym and which is the official
> token. Things like rect and rectangle are curly because just about nobody
> uses rectangle yet obviously rect is the synonym and has been used in the
> properties property for as long as it has existed...
>
> Cheers
>
> Monte
> ___
> 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: Widget Properties

[Monte Goulding]

> On 11 Oct 2015, at 10:10 pm, Mark Waddingham  wrote:
> 
> Basically, we needed sideline information which wasn't suitable for inclusion 
> in the actual module format, and thus it seemed sensible to put the other 
> information the IDE would need in the manifest too rather than it having to 
> both interrogate an XML file *and* introspect on the loaded module).

Ah, forgot about stuff like property editors being in there.
> 
> At some point the metadata expressed in widget lcb files might well get put 
> into the compiled module blob - but it seemed more expedient whilst 
> developing the ideas to keep it separate as it is easier to change the XML 
> format that is emitted and read than it is the compiled module blob format.

Fair enough

> The export to array stuff is the best (future) basis for things such as 
> lcVCS. Indeed eventually, if it was rolled out across all engine objects, the 
> stackfile format would become arrayEncode(stackExportedToArray("my stack")) - 
> although that would require a much more efficient arrayEncode format 
> (something which has been at the back of my mind for ages - but nothing I've 
> had time to put into action).

Wouldn’t it also bloat the file format considerably with array keys? I guess 
the advantages will probably outweigh the disadvantages though. You would never 
need to worry about file format changes again unless you had to change the 
arrayEncode format.
___
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: Widget Properties

[Monte Goulding]

> On 11 Oct 2015, at 11:06 am, Peter Haworth  wrote:
> 
> I assume widgets can have standard LC built-in properties as well as their
> own specific properties?
> 
> For example if I set the disabled of a widget, it no longer reacts to mouse
> clicks, but if I get its properties, they are empty.
> 
> I know widgets have their own property definitions but I would have thought
> any of the standard built-in properties would have been returned by their
> properties property.

Yes this is an odd one which I’ve queried before. You can now use export widget 
to array to get the widget defined properties as they will be saved. I don’t 
think this includes the base object properties like visible, rect, disabled etc 
though. This is one of the things I need to investigate if I ever have time to 
get lcVCS working on LC 8…

Cheers

Monte
___
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: Widget Properties

[Peter Haworth]

Thanks Monte.  Maybe I should file a QCC report or have you already done so?

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 

On Sat, Oct 10, 2015 at 5:18 PM, Monte Goulding  wrote:

>
> > On 11 Oct 2015, at 11:06 am, Peter Haworth  wrote:
> >
> > I assume widgets can have standard LC built-in properties as well as
> their
> > own specific properties?
> >
> > For example if I set the disabled of a widget, it no longer reacts to
> mouse
> > clicks, but if I get its properties, they are empty.
> >
> > I know widgets have their own property definitions but I would have
> thought
> > any of the standard built-in properties would have been returned by their
> > properties property.
>
> Yes this is an odd one which I’ve queried before. You can now use export
> widget to array to get the widget defined properties as they will be saved.
> I don’t think this includes the base object properties like visible, rect,
> disabled etc though. This is one of the things I need to investigate if I
> ever have time to get lcVCS working on LC 8…
>
> Cheers
>
> Monte
> ___
> 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

Widget Properties

[Peter Haworth]

I assume widgets can have standard LC built-in properties as well as their
own specific properties?

For example if I set the disabled of a widget, it no longer reacts to mouse
clicks, but if I get its properties, they are empty.

I know widgets have their own property definitions but I would have thought
any of the standard built-in properties would have been returned by their
properties property.


Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 
___
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