Re: Widget Properties

2020-04-25 Thread 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

Re: Widget Properties

2020-04-25 Thread 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

Re: Widget Properties

2020-04-24 Thread 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

Re: Widget Properties

2020-04-24 Thread 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

Re: Widget Properties

2020-04-24 Thread 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

Re: Widget Properties

2020-04-24 Thread 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

Re: Widget Properties

2020-04-24 Thread 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

Re: Widget Properties

2020-04-24 Thread 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

Re: Widget Properties

2020-04-23 Thread 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

Re: widget properties

2018-02-27 Thread 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

Re: widget properties

2018-02-26 Thread 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

Re: widget properties

2018-02-25 Thread 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

Re: widget properties

2018-02-25 Thread 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

Re: widget properties

2018-02-25 Thread 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

Re: widget properties

2018-02-25 Thread 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

Re: widget properties

2018-02-25 Thread 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

Re: widget properties

2018-02-25 Thread 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

Re: widget properties

2018-02-25 Thread 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 <

Re: widget properties

2018-02-25 Thread 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

Re: widget properties

2018-02-25 Thread 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

Re: widget properties

2018-02-25 Thread 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

Re: widget properties

2018-02-25 Thread 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

Re: widget properties

2018-02-25 Thread 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

Re: widget properties

2018-02-25 Thread 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

Re: widget properties

2018-02-24 Thread 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.

Re: widget properties

2018-02-24 Thread 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

Re: widget properties

2018-02-24 Thread 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

Re: widget properties

2018-02-24 Thread 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

Re: widget properties

2018-02-24 Thread 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

Re: widget properties

2018-02-24 Thread 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

Re: widget properties

2018-02-24 Thread 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

Re: widget properties

2018-02-24 Thread 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

Re: widget properties

2018-02-24 Thread 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

Re: widget properties

2018-02-24 Thread 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

Re: widget properties

2018-02-24 Thread 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

Re: widget properties

2018-02-24 Thread 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

Re: widget properties

2018-02-24 Thread 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

Re: widget properties

2018-02-24 Thread 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. > >

Re: Widget properties

2017-10-23 Thread 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

Re: Widget Properties

2015-10-11 Thread 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

Re: Widget Properties

2015-10-11 Thread 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

Re: Widget Properties

2015-10-11 Thread 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

Re: Widget Properties

2015-10-11 Thread 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

Re: Widget Properties

2015-10-11 Thread 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

Re: Widget Properties

2015-10-11 Thread 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

Re: Widget Properties

2015-10-11 Thread 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.

Re: Widget Properties

2015-10-11 Thread Peter Haworth
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

2015-10-11 Thread 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 <

Re: Widget Properties

2015-10-11 Thread 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

Re: Widget Properties

2015-10-10 Thread 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,

Re: Widget Properties

2015-10-10 Thread 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