Re: widget properties

(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

Re: Widget properties

> 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

Re: Widget properties

Here's my 25p's worth: Ever since widgets 'appeared' I have thought of them as second class citizens insofar as: 1. They are 'bits of stuff' where experts (the LiveCode team and so on) have done the heavy lifting for those of us who haven't got the skill, motivation or time to work out how

Re: Widget properties

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

Re: widget properties

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

Re: Widget properties

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

Re: Widget properties

> 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

Re: widget properties

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

Re: Widget properties

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

Re: Widget properties

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

Re: Widget properties

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

Re: Widget properties

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

Re: widget properties

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

Re: Widget properties

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

Re: Widget properties

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.

Re: Widget properties

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

Re: Widget properties

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 <

Re: Widget properties

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

Re: Widget properties

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,

Re: Widget properties

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

Re: Widget properties

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

Re: Widget Properties

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

Re: Widget Properties

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

Re: Widget Properties

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

Re: Widget Properties

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

Re: Widget Properties

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

Re: Widget Properties

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

Re: Widget Properties

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

Re: Widget Properties

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

Re: Widget Properties

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

Re: widget properties

+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

Re: widget properties

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

Re: widget properties

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

Re: widget properties

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

Re: widget properties

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

Re: widget properties

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

Re: widget properties

> 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

Re: widget properties

> 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

Re: widget properties

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 <

Re: widget properties

> 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

Re: widget properties

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

Re: widget properties

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

Re: widget properties

> 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

Re: widget properties

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

Re: widget properties

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

Re: widget properties

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.

Re: widget properties

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

Re: widget properties

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

Re: widget properties

@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

Re: widget properties

> 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

Re: widget properties

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

Re: widget properties

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

Re: widget properties

> 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

Re: widget properties

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

Re: widget properties

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

Re: widget properties

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

Re: widget properties

> 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

Re: widget properties

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

Re: widget properties

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

Re: Widget properties

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

Re: Widget Properties

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

Re: Widget Properties

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

Re: Widget Properties

> 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

Re: Widget Properties

> 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

Re: Widget Properties

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

Re: Widget Properties

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

Re: Widget Properties

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

Re: Widget Properties

On Sun, Oct 11, 2015 at 2:08 AM, Mark Waddingham 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. >

Re: Widget Properties

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 <

Re: Widget Properties

> 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

Re: Widget Properties

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

Re: Widget Properties

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