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

[Mark Waddingham]

Well we can certainly come up with a list of the handlers which are definitely 
part of the API used by the palettes.

I'd point out that the format on disk of the extensions folder and the metadata 
file hadn't been 'officially sanctioned' as not going to change either... Hence 
why the IDE indirects through a library with a reasonable api to manipulate 
such things.

Indeed, having to rewrite code that replicates code in the IDE because 
something has to be tweaked at a lower-level (eg manifest format, file layout) 
seems like a lot more work than potentially having to tweak the use of an IDE 
API.

Mark.

Sent from my iPhone

> On 11 Oct 2015, at 07:02, Mark Wieder  wrote:
> 
>> On 10/10/2015 05:54 PM, Mark Waddingham wrote:
>> I don't think I expressed myself very well in the bug report you filed...
>> 
>> The examples for syntax shouldn't use undocumented / ide functions - as it 
>> is misleading.
>> 
>> The ide functions as yet aren't documented but at some point will be as a 
>> 'how to write ide components' reference.
>> 
>> However, that being said, there are IDE APIs for accessing all information 
>> related to widgets so using those is the best approach for such things 
>> rather than writing bespoke code that processes their form on disk and in 
>> XML files.
>> 
>> The best thing to do is to have a look through revidelibrary and 
>> revideextensionlibrary.
> 
> OK. That puts things a bit more into perspective.
> I'm still reluctant, though, to rely on using things I've found while poking 
> around in the IDE stacks without having them officially sanctioned unless 
> there's no way around it. Thus my original bug report on that issue. I would 
> worry that the IDE stacks may get refactored and some of the functions I 
> count on have disappeared. I'm not suggesting that every handler in the IDE 
> should be in the dictionary, but I think I'll keep asking for official 
> sanction before committing function xyz to use.
> 
> 
> -- 
> 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

___
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 structure questions

[Mark Waddingham]

On 2015-10-11 08:12, Mark Wieder wrote:

On 10/10/2015 12:47 PM, Peter Haworth wrote:

Yes, I've been using them for a long time now and also wonder why they
aren't in the dictionary.  I think I might have filed a bug report 
about

that a long while ago but don;t remember for sure.


Filed 16189 and 16190.


They've never been documented because we've never put 'IDE only' 
functions in the dictionary - the latter always having been about what 
is available to an application you write in the IDE; rather than what is 
available to write a tool running in the IDE which helps to write an 
application.


I agree, however, that it is important for the tool writers that this 
kind of reference be available.


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: LC 8 Property Inspector

[Mark Waddingham]

On 2015-10-10 22:12, Richard Gaskin wrote:

Weirdest: Replace the IDE with the best of community components
---
Like the "Weirder" option above, this would be independent of the
product build, but would open the door for anyone to do whatever they
want.  Bjornke's BVGDocu could replace the Dictionary, Peter's
lcStackBrowser could replace the App and Proj browsers, your GLX2
editor could replace the Script Editor, etc.

...

It's like the thing I like most about Linux:  although people in the
Linux world enjoy arguing about darn near everything, the fact is
there's actually little to argue about since the system is so flexible
and has so many components available there's no reason why everyone
can't have exactly what they most desire.


The obvious option (which is the one we have been working towards in the 
LC8 IDE) is that the IDE becomes a 'framework'. It provides well defined 
extension points, well defined APIs for building IDE components, and a 
well defined mechanism to ensure that changes flow properly so all 
components are kept synchronized.


The IDE framework has to be the arbiter which ensures that two distinct 
IDE components (which could be written and maintained by people who 
never speak to each other) can happily co-exist with each other in an 
end-user's install.


In particular, this means that IDE components *cannot* patch random 
parts of the IDE (as they might conflict), and any points within the IDE 
which might be usefully customized (e.g. adding extra buttons to 
revMenubar) need to be explicitly exposed in a well-defined way.


Now a lot of work has been done towards this, but at the moment if you 
want to play with it you have to do a bit of digging around in the 
libraries which are emerging (revidelibrary, revideextensionlibrary 
etc.) and the revised components which use these new APIs. Admittedly we 
aren't quite there yet as it does take time to introduce good 
abstractions into code which did not have them before (well, not ones 
which were suitable for a more step-back and provide the ability for 
anyone to extend point of view at least).


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

[Mark Wieder]

On 10/10/2015 05:54 PM, Mark Waddingham wrote:

I don't think I expressed myself very well in the bug report you filed...

The examples for syntax shouldn't use undocumented / ide functions - as it is 
misleading.

The ide functions as yet aren't documented but at some point will be as a 'how 
to write ide components' reference.

However, that being said, there are IDE APIs for accessing all information 
related to widgets so using those is the best approach for such things rather 
than writing bespoke code that processes their form on disk and in XML files.

The best thing to do is to have a look through revidelibrary and 
revideextensionlibrary.


OK. That puts things a bit more into perspective.
I'm still reluctant, though, to rely on using things I've found while 
poking around in the IDE stacks without having them officially 
sanctioned unless there's no way around it. Thus my original bug report 
on that issue. I would worry that the IDE stacks may get refactored and 
some of the functions I count on have disappeared. I'm not suggesting 
that every handler in the IDE should be in the dictionary, but I think 
I'll keep asking for official sanction before committing function xyz to 
use.



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

[Mark Wieder]

On 10/10/2015 12:47 PM, Peter Haworth wrote:

Yes, I've been using them for a long time now and also wonder why they
aren't in the dictionary.  I think I might have filed a bug report about
that a long while ago but don;t remember for sure.


Filed 16189 and 16190.

--
 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 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: LC 8 Property Inspector

[Mark Wieder]

On 10/10/2015 01:12 PM, Richard Gaskin wrote:


Weirdest: Replace the IDE with the best of community components
---
Like the "Weirder" option above, this would be independent of the
product build, but would open the door for anyone to do whatever they
want.  Bjornke's BVGDocu could replace the Dictionary, Peter's
lcStackBrowser could replace the App and Proj browsers, your GLX2 editor
could replace the Script Editor, etc.

At that point the IDE becomes a very slender thing, just a tool rack on
which we hang our own tools.  And the tools within it would not only be
the best of what the community has to offer, but could also be
interchangeable.


That, I think is what Ali was implying. There is indeed movement in that 
direction in the IDE... what with publish and subscribe mechanisms and a 
palette abstraction layer... admittedly it's a long ways off yet. The 
palettes are hard-coded for now, and there's still a lot in the IDE that 
doesn't use the abstraction layer: for instance, the newTool handler 
goes directly to the "revTools" stack instead of querying for the 
palette, but I do see some light at the end of a long tunnel.


--
 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: Mouse events outside stack bounds on mobile

[Roger Eller]

If showAll works properly on other mobile devices, but "in particular"
fails on Android, it is a bug.  Workarounds are fine, but bugs still need
to be addressed.
On Oct 11, 2015 9:32 AM, "Colin Holgate"  wrote:

> I still have that here. It didn’t have any mouse actions at the time I
> looked at it.
>
> So, changing to noBorder could be worth a try. You would have the card be
> 3:4 ratio, and 9:16 devices would see the middle area, and iPad would see
> the whole width, and mouse events would all be happening inside the card
> area.
>
> > On Oct 10, 2015, at 11:30 PM, J. Landman Gay 
> wrote:
> >
> > On 10/10/2015 8:36 PM, Colin Holgate wrote:
> >> I don’t remember that stack. What is its name? Or, can you post or
> email the current version?
> >
> > "Gurudeva". I thought he posted a link to a very early version and you
> took a look. You suggested using showAll, actually. I'll see if I can send
> you a copy.
> >
> > As it turns out, a user's finger is wider than the dead spot so we may
> be okay. It's still a bug, and the visual effect is weird looking, but the
> end result may still be usable. I was testing on the iOS simulator, and the
> pointer can click into narrow spaces where a finger can't.
> >
> > --
> > 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
___
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: Paths in Mac standalone headache

[Peter M. Brigham]

On Oct 10, 2015, at 3:39 PM, Richard Gaskin wrote:

> Once we discovered that the recursion was happening not because we had 
> directory structures more than 400,000 folders deep but simply because "set 
> the directory..." was failing so we kept attempting to get the files of the 
> same directory, we stopped doing that.

OMG, under what circumstances have you needed to deal with a folder structure 
more than 400,000 deep???

-- Peter

Peter M. Brigham
pmb...@gmail.com
http://home.comcast.net/~pmbrig


___
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: Mouse events outside stack bounds on mobile

[Colin Holgate]

I still have that here. It didn’t have any mouse actions at the time I looked 
at it.

So, changing to noBorder could be worth a try. You would have the card be 3:4 
ratio, and 9:16 devices would see the middle area, and iPad would see the whole 
width, and mouse events would all be happening inside the card area.

> On Oct 10, 2015, at 11:30 PM, J. Landman Gay  wrote:
> 
> On 10/10/2015 8:36 PM, Colin Holgate wrote:
>> I don’t remember that stack. What is its name? Or, can you post or email the 
>> current version?
> 
> "Gurudeva". I thought he posted a link to a very early version and you took a 
> look. You suggested using showAll, actually. I'll see if I can send you a 
> copy.
> 
> As it turns out, a user's finger is wider than the dead spot so we may be 
> okay. It's still a bug, and the visual effect is weird looking, but the end 
> result may still be usable. I was testing on the iOS simulator, and the 
> pointer can click into narrow spaces where a finger can't.
> 
> -- 
> 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

Programming LiveCode for the Real Beginner

[Mark Schonewille]

Hi,

Currently, we're selling lots of books and on tuesday we'll be sending 
an extra batch. If you want the book to be delivered quickly, you can 
order now and have it sent within 2 days. Any book ordered before monday 
night will be shipped on tuesday.


Programming LiveCode for the Real Beginner is a book that gives you a 
quick introduction to the LiveCode language. It contains examples of 
many common situations and helps you to understand how the LiveCode 
language works. It doesn't depend on a particular version of the IDE and 
is useful for all version from Revolution 4.5 till LiveCode 8.


An e-book is not and won't be available. For more information, see the 
link in my signature.


--
Mark Schonewille
http://economy-x-talk.com

Buy the most extensive book on the
LiveCode language:
http://livecodebeginner.economy-x-talk.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 structure questions

[Mark Wieder]

On 10/11/2015 01:36 AM, Mark Waddingham wrote:


I agree, however, that it is important for the tool writers that this
kind of reference be available.


Add to that the fact that I haven't even been able to find which ide 
library those functions live in, so unless you already know about them 
(meaning that you have a copy of the v5 release notes) you will end up 
recreating them by finding the engine folder and fiddling with the path, 
hoping it doesn't change, etc.


I'm currently in the situation where the built-in Extensions folder is 
in a different place in the folder structure on OSX from where it is in 
linux, so I'm having to special-case my code depending on platform. I 
haven't looked at Windows yet, but hopefully it will fall into one of 
those two categories.


--
 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: Learning Materials

[William Prothero]

Richard:
Thanks for the info. I think a task-driven cookbook does really need to be 
community developed. There are so many emails here that ask “how do I do xyz?” 
or “xyz won’t work… why?” Compiling these, with dates and keywords, and a user 
commenting facility, would go a long way toward accomplishing this. If there 
was a web site where users could make these contributions and a reviewer of 
some sort could edit them prior to inclusion in the “master cookbook”, that 
might work. 

For me, my main frustration is getting an app onto iPhone. There is a tutorial 
on the livecode site, which helped me a lot. Later, after I forgot its details, 
I tried to make a new iOS app and got burned by the provisioning profile, which 
I tried to make generic, but LC wouldn’t accept a generic one. When I went back 
to the original tutorial, I got it working, but it took me more than a day to 
get there. So, I dread my next try at iOS. Also, getting an Apple certificate 
is another hurdle and I haven’t accomplished that yet, as I’ve been tryin got 
use AppWrapper 3 and it won’t work. Some kind of cookbook, that could be 
updated as Apple adds new hurdles and requirements, would be marvelous.

I have a “Notebook” app that has the following headings. The headings I use 
currently are shown below. There are sub-headings with specific code and for 
different applications. It is just a collection, saved from the email list over 
the last two years for my own use and not refined for mass distribution.

Array handling
Behaviors
Calling handlers, out of path hierarchy
CEF Browser 
Code signing
Color-mouse-at loc
Date
DataGrid
Debugger use and tricks
Detect if app is running and user is "on" it.
DNS mysteries
Drag and Drop
Email thru livecode server
Encryption
Fields, text display
Files and directories
Find out if some program is running
Get Mac camera image
Get Version in iOS
Graphic effects
Groups
Images
iOS mobile stuff
Learning materials links
Memory monitoring
MobGui
Mobile Copying stacks and using them as libraries
Number precision
PHP and databases
Playing sound in SA and Mobile
Playing sounds
Printing
Product version from script
Scientific notation converter
Screen scaling issues
SnapShots
Scrolling
Server stuff
Sorting
Sockets
SSH Tunneling
Ssh and secure transfer
Stacks and substacks
Text Code: Parsing Delimited 
Text-Rotating
Text to speech
Text
Time Zone Info
User function names-getting them from scripts
Video
Widgets

Best,
Bill

> On Oct 10, 2015, at 12:28 PM, Richard Gaskin  
> wrote:
> 
> William Prothero wrote:
> 
>> I said we need a dictionary focussed on tasks, not on commands,
>> but obviously we need both. I know Richard has been leading a
>> group taking this on. Richard, is this happening?
> 
> The focus of an API reference like the LiveCode Dictionary will always have 
> the language tokens as their primary index.  This can (and arguably should) 
> be augmented with tags to support searching for strings conceptually related 
> but not found in the token itself or its description.  I believe that's been 
> put into place for the future, but regrettably not available in the current 
> shipping product v7.
> 
> Task-driven documentation is traditionally the domain of things like 
> "Cookbooks".   That format allows for the exploration of related concepts in 
> a more detailed  way that would be clumsy or even distracting in a 
> Dictionary. IIRC LiveCode 1.0 had Cookbook, but I'm not sure when it was 
> dropped.
> 
> To answer your question about the Community Documentation Team, over the last 
> year the core team at LiveCode Ltd. has been migrating all documentation 
> content into Github markdown so that it can not only be more easily edited 
> but also reviewed, merged, and compiled into the product build more easily as 
> well.
> 
> Peter Brett at LiveCode Ltd. has taken on the role of stewarding community 
> engagement projects like this one, and the process of migrating the content 
> to markdown is now far enough along that my next meeting with Dr. Brett will 
> focus on conveying the dynamics of the workflow so we can get to work.
> 
> The scope defined for the moment, however, is to update existing docs.
> 
> If there's a desire for a Cookbook I would encourage the community to 
> consider establishing a wiki for that.  Indeed, there is one at wikia.com 
> which may be a good starting point:
> 
> 
> To help guide such an effort, let me ask you a question related to the 
> CreateIt course you mentioned:
> 
> You've been using LiveCode for many years, and have made some substantial 
> software with it.  At this point in your work, what topics would you find 
> most valuable?
> 
> -- 
> Richard Gaskin
> LiveCode Community Manager
> rich...@livecode.org
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage 

Re: Widget Properties

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

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

Re: Mouse events outside stack bounds on mobile

[J. Landman Gay]

On 10/11/2015 9:02 AM, Roger Eller wrote:

If showAll works properly on other mobile devices, but "in particular"
fails on Android, it is a bug.  Workarounds are fine, but bugs still need
to be addressed.


I probably wasn't clear. ShowAll works (or rather, doesn't work) the 
same way on both iOS and Android though I think it's still a bug. But 
I've hit lots of other bugs that do only affect Android, mostly with 
image redraws and visual effects which are significantly broken on 
Android, and I need to submit reports about those.


--
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: Mouse events outside stack bounds on mobile

[Richard Gaskin]

J. Landman Gay wrote:

> On 10/11/2015 9:02 AM, Roger Eller wrote:
>> If showAll works properly on other mobile devices, but "in
>> particular" fails on Android, it is a bug.  Workarounds are
>> fine, but bugs still need to be addressed.
>
> I probably wasn't clear. ShowAll works (or rather, doesn't work) the
> same way on both iOS and Android though I think it's still a bug. But
> I've hit lots of other bugs that do only affect Android, mostly with
> image redraws and visual effects which are significantly broken on
> Android, and I need to submit reports about those.

Help me understand something:  when is showAll useful?

I can appreciate the ease for quickie builds during early-stage 
development, but sooner or later the app will (hopefully) be released 
into a world in which device resolutions, sizes, and ratios can't be 
known in advance.


On the desktop we handle all possible sizes with resizeStack handlers. 
When would a developer not apply the same loving care to their mobile 
layout?


--
 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: Mouse events outside stack bounds on mobile

[Colin Holgate]

Think of any story scene based game, where what you see is not a utility app 
full of fields and buttons that could be placed using code. You would not want 
to have to create different artwork for every possible aspect ratio screen. 
Instead you have extra scenery that gets revealed on wider or taller devices.

Almost all the apps I’ve made used showall, where either there was extra 
content to the left and right of the card area (stage area as the case was, not 
being LiveCode apps), or extra content above and below the card area. Which way 
I work depends on the nature of the app. For example, in a book like app I want 
the full height of the page to always be visible, and I reveal spare background 
to the left and right (this is with landscape by the way). For graphical games 
I make it be that all devices see the full width of the scene, and on wider 
aspect ration devices the scene gets cropped at the top and bottom. The 
essential game play is within a 16:9 center part of the display, and there is 
extra background to take it up to 4:3 ratio.

Sometimes I don’t want to eat into so much of either the width or the height, 
and for those cases I have 14:9 ratio content, and use noborder. On a 4:3 
device you see the full height of the scene, and most of the width. On 16:9 
devices you see the full width of the scene, and most of the height. It’s a 
good compromise, and the safety area is the middle 14:9 part of the scene.

The advantage of all this is that you don’t have to worry about either the 
screen size or aspect ratio, LiveCode makes your content fill the screen.

I made these pages to show off the different modes. Choose one of them and then 
resize the browser window to simulate different aspect ratio devices:

http://colin.scienceninja.com/showall.html
http://colin.scienceninja.com/noborder.html
http://colin.scienceninja.com/topleftnoscale.html
http://colin.scienceninja.com/noscale.html
http://colin.scienceninja.com/exactfit.html

The red lines are iPad ratio, green is iPhone 4 ratio, and blue is iPhone 5 
ratio.



> On Oct 11, 2015, at 2:53 PM, Richard Gaskin  
> wrote:
> 
> J. Landman Gay wrote:
> 
> > On 10/11/2015 9:02 AM, Roger Eller wrote:
> >> If showAll works properly on other mobile devices, but "in
> >> particular" fails on Android, it is a bug.  Workarounds are
> >> fine, but bugs still need to be addressed.
> >
> > I probably wasn't clear. ShowAll works (or rather, doesn't work) the
> > same way on both iOS and Android though I think it's still a bug. But
> > I've hit lots of other bugs that do only affect Android, mostly with
> > image redraws and visual effects which are significantly broken on
> > Android, and I need to submit reports about those.
> 
> Help me understand something:  when is showAll useful?
> 
> I can appreciate the ease for quickie builds during early-stage development, 
> but sooner or later the app will (hopefully) be released into a world in 
> which device resolutions, sizes, and ratios can't be known in advance.
> 
> On the desktop we handle all possible sizes with resizeStack handlers. When 
> would a developer not apply the same loving care to their mobile layout?
> 
> -- 
> 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

[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

function for greatest object in list less than or equal to a value

[Dr. Hawkins]

It would be nice to have an intrinsic for this, but I just read the entire
function list . . .

I need to find the largest number in a list which is smaller than a
specified value.

e.g., for the list "1,3,4,7,9" and 5, the largest such value would be 4.

In a spreadsheet, I could use use vlookup() and specified the index as the
row to return.

In a database, could " SELECT MAX(myVar) WHERE myVar<5;", and so forth

I  had thought that FILTER could take a]b arbitrary function, but
apparently not. t It could conceivably use a rgexp, but calling a regex for
numeric comparison "ugly" would be polite

I'm not seeing anyhing better than lo better than looping through at the
moment
-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
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: Mouse events outside stack bounds on mobile

[J. Landman Gay]

On 10/11/2015 1:53 PM, Richard Gaskin wrote:


On the desktop we handle all possible sizes with resizeStack handlers.
When would a developer not apply the same loving care to their mobile
layout?


Colin is spot on. If you choose the right fullscreenMode and set up your 
layout appropriately you don't need any resizeStack handler at all. It 
works beautifully and it's all automatic. All the controls are scaled, 
placed correctly, and even the text size updates proportionally. For me, 
this is the most important improvement to mobile deployment that LC has 
done.


I think Colin was a little too reserved though, and that if carefully 
planned, even a screen full of database fields would scale just fine as 
long as you restrain the content area to the appropriate part of the 
screen. There's little difference really between the "playable area" of 
a game and the "working area" of a data card.


--
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: Learning Materials

[Michael Doub]

Would it be reasonable to ask Livecode to host a wiki site for 
documentation and examples?  I kind of like the idea of having the 
ability to add information or update when I see something that it out of 
date or unclear.


The problem is always organization and searching.   This would still 
need to be dealt with, but the wiki idea lets the community contribute 
and edit.


Sorry if this is out of context.  I am just catching back up on email.

-= Mike


On 10/11/15 1:34 PM, William Prothero wrote:

Richard:
Thanks for the info. I think a task-driven cookbook does really need to be 
community developed. There are so many emails here that ask “how do I do xyz?” 
or “xyz won’t work… why?” Compiling these, with dates and keywords, and a user 
commenting facility, would go a long way toward accomplishing this. If there 
was a web site where users could make these contributions and a reviewer of 
some sort could edit them prior to inclusion in the “master cookbook”, that 
might work.

For me, my main frustration is getting an app onto iPhone. There is a tutorial 
on the livecode site, which helped me a lot. Later, after I forgot its details, 
I tried to make a new iOS app and got burned by the provisioning profile, which 
I tried to make generic, but LC wouldn’t accept a generic one. When I went back 
to the original tutorial, I got it working, but it took me more than a day to 
get there. So, I dread my next try at iOS. Also, getting an Apple certificate 
is another hurdle and I haven’t accomplished that yet, as I’ve been tryin got 
use AppWrapper 3 and it won’t work. Some kind of cookbook, that could be 
updated as Apple adds new hurdles and requirements, would be marvelous.

I have a “Notebook” app that has the following headings. The headings I use 
currently are shown below. There are sub-headings with specific code and for 
different applications. It is just a collection, saved from the email list over 
the last two years for my own use and not refined for mass distribution.

Array handling
Behaviors
Calling handlers, out of path hierarchy
CEF Browser 
Code signing
Color-mouse-at loc
Date
DataGrid
Debugger use and tricks
Detect if app is running and user is "on" it.
DNS mysteries
Drag and Drop
Email thru livecode server
Encryption
Fields, text display
Files and directories
Find out if some program is running
Get Mac camera image
Get Version in iOS
Graphic effects
Groups
Images
iOS mobile stuff
Learning materials links
Memory monitoring
MobGui
Mobile Copying stacks and using them as libraries
Number precision
PHP and databases
Playing sound in SA and Mobile
Playing sounds
Printing
Product version from script
Scientific notation converter
Screen scaling issues
SnapShots
Scrolling
Server stuff
Sorting
Sockets
SSH Tunneling
Ssh and secure transfer
Stacks and substacks
Text Code: Parsing Delimited
Text-Rotating
Text to speech
Text
Time Zone Info
User function names-getting them from scripts
Video
Widgets

Best,
Bill


On Oct 10, 2015, at 12:28 PM, Richard Gaskin  wrote:

William Prothero wrote:


I said we need a dictionary focussed on tasks, not on commands,
but obviously we need both. I know Richard has been leading a
group taking this on. Richard, is this happening?

The focus of an API reference like the LiveCode Dictionary will always have the 
language tokens as their primary index.  This can (and arguably should) be 
augmented with tags to support searching for strings conceptually related but 
not found in the token itself or its description.  I believe that's been put 
into place for the future, but regrettably not available in the current 
shipping product v7.

Task-driven documentation is traditionally the domain of things like 
"Cookbooks".   That format allows for the exploration of related concepts in a 
more detailed  way that would be clumsy or even distracting in a Dictionary. IIRC 
LiveCode 1.0 had Cookbook, but I'm not sure when it was dropped.

To answer your question about the Community Documentation Team, over the last 
year the core team at LiveCode Ltd. has been migrating all documentation 
content into Github markdown so that it can not only be more easily edited but 
also reviewed, merged, and compiled into the product build more easily as well.

Peter Brett at LiveCode Ltd. has taken on the role of stewarding community 
engagement projects like this one, and the process of migrating the content to 
markdown is now far enough along that my next meeting with Dr. Brett will focus 
on conveying the dynamics of the workflow so we can get to work.

The scope defined for the moment, however, is to update existing docs.

If there's a desire for a Cookbook I would encourage the community to consider 
establishing a wiki for that.  Indeed, there is one at wikia.com which may be a 
good starting point:


To help guide such an effort, let me ask you a question related to the CreateIt 
course you mentioned:

You've 

[ANN] LiveCode List Processor

[Peter W A Wood]

I decided to convert a small card-based database stack to a “proper” database 
using SQLite. I immediately missed the next/previous card navigation features 
which were ideal for browsing the small database.

LiveCode chunking is great for handling lists but, as far as I can tell, is 
missing forward and backward navigation through lists. I decided to write a few 
simple functions to come up with such a mechanism. 

I suspect that there may be an existing way to navigate forwards and backwards 
through a list but I just can’t find it. I’ve put together a very simple, 
completely unoptimised start of a LiveCode list processing library. It contains 
only a handful of functions. You can find it at 
https://github.com/PeterWAWood/LiveCode-ListProcessor 
.

Perhaps you would be kind enough to let me know of existing ways to achieve 
what this small library does before I spent more time developing it?

Regards

Peter


___
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

[ANN] mergExt: BLE, Google spreadsheets, Map directions, iOS 9 & special price

[Monte Goulding]

Hi LiveCoders

Today I am releasing a huge update to mergExt Complete and announcing a special 
price available for the rest of the month.

mergBLE 1.0 - CoreBluetooth external for iOS and OS X. Use BLE between Mac and 
iOS or between iOS devices or between some of the great sensors available and 
your app. For the arduino hackers out there you will love pairing this external 
with the ReadBearLab BLE shield. Control anything from your Mac or iOS 
device!!!  (Also sold separately for $49).

mergGoogle 1.0 - This external for iOS and OS X currently implements google 
spreadsheets. (Also sold separately for $49).

mergMK 3.0 - This update to mergMK supports querying directions between 
locations.

iOS 9 support - all the mergExt externals have now been updated for iOS 9 
support.

The mergExt Complete bundle now weighs in at a hefty $1038 worth of individual 
products for only $299. Yes that’s right folks. We’ve cracked the ton!

Special Price: 3 years of access to mergExt Complete for $499. That’s a huge 
$398 saving folks. Use this link to access the special deal 
http://mergext.com/special/  The first 5 people 
taking advantage of the special price will also get an additional 6 months at 
no extra charge. Get it while it’s hot!!!

Cheers

Monte

--
M E R Goulding  
Software development services
Bespoke application development for vertical markets

mergExt  - There's an external for 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

The 1001 Things To Do With LiveCode All Time Top Ten

[Peter W A Wood]

Even though I haven’t been able to spend much time on 1001 Things To Do With 
LiveCode recently, the blog is still getting an average of 80 visitors per day. 
I thought you might like to see the all-time top 10 pages visited.

3579Create a URL shortening service by John Craig
1004Code an App store accepted game in a week by Dave Probert
864 Administer SQLite databases by Peter Haworth
587 Exercise your right brain by Andrew Walters
542 Program your watch by Roger Eller
336 Manage a database of images by Roger Eller
312 Create you own virtual instrument by René Micout
279 Build mobile games by Andre Garcia
277 Team organisation and time tracking by Roberto Trevisan
242 Build an assembly language interpreter by Andre Garcia

The more recent entries in the blog have a high percentage of commercially 
available apps written in LiveCode and few very own-use or hobby apps. The 
original purpose of the blog was to show people who had never programmed before 
what could be achieved with LiveCode and to stimulate their imagination as to 
what they could do with LiveCode.

If you have used LiveCode to write an app for your own use or for your hobby 
perhaps you would be kind enough to send me a screenshot and a short 
description. I will try to find the time to add it to 1001 Things You Can Do 
With LiveCode.

Regards

Peter

___
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: function for greatest object in list less than or equal to a value

[Peter M. Brigham]

function getMaxLessThan tList,maxVal
   repeat for each item i in tList
  if i < maxVal then put i & comma after outList
   end repeat
   return max(item 1 to -1 of outList)
end getMaxLessThan

Simple and fast.

-- Peter

Peter M. Brigham
pmb...@gmail.com
http://home.comcast.net/~pmbrig

On Oct 11, 2015, at 12:15 PM, Dr. Hawkins wrote:

> It would be nice to have an intrinsic for this, but I just read the entire
> function list . . .
> 
> I need to find the largest number in a list which is smaller than a
> specified value.
> 
> e.g., for the list "1,3,4,7,9" and 5, the largest such value would be 4.
> 
> In a spreadsheet, I could use use vlookup() and specified the index as the
> row to return.
> 
> In a database, could " SELECT MAX(myVar) WHERE myVar<5;", and so forth
> 
> I  had thought that FILTER could take a]b arbitrary function, but
> apparently not. t It could conceivably use a rgexp, but calling a regex for
> numeric comparison "ugly" would be polite
> 
> I'm not seeing anyhing better than lo better than looping through at the
> moment
> -- 
> Dr. Richard E. Hawkins, Esq.
> (702) 508-8462
> ___
> 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: function for greatest object in list less than or equal to a value

[dunbarx]

Richard,


How about this, given a comma delimited list (say "1,1,2,2,3,3,4,4,5,6,7,8,9") 
in a field 1, with a "5" as your index?



on mouseUp
  answer findItemLessThanIndex(fld 1,"5")
end mouseUp


function findItemLessThanIndex tData,tIndex
   put comma & tIndex after tData
   sort items of tData numeric
   return  item itemOffset("5",tData) -1 of tData
end findItemLessThanIndex




-Original Message-
From: Dr. Hawkins 
To: How to use LiveCode 
Sent: Sun, Oct 11, 2015 12:16 pm
Subject: function for greatest object in list less than or equal to a value


It would be nice to have an intrinsic for this, but I just read the
entire
function list . . .

I need to find the largest number in a list which
is smaller than a
specified value.

e.g., for the list "1,3,4,7,9" and 5, the
largest such value would be 4.

In a spreadsheet, I could use use vlookup()
and specified the index as the
row to return.

In a database, could " SELECT
MAX(myVar) WHERE myVar<5;", and so forth

I  had thought that FILTER could
take a]b arbitrary function, but
apparently not. t It could conceivably use a
rgexp, but calling a regex for
numeric comparison "ugly" would be polite

I'm
not seeing anyhing better than lo better than looping through at the
moment
--

Dr. Richard E. Hawkins, Esq.
(702)
508-8462
___
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: [ANN] mergExt: BLE, Google spreadsheets, Map directions, iOS 9 & special price

[Mike Kerner]

Might I just say that we've had mergGoogle running for a month or two, and
it's just another great tool that makes LC a great tool.

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

> Hi LiveCoders
>
> Today I am releasing a huge update to mergExt Complete and announcing a
> special price available for the rest of the month.
>
> mergBLE 1.0 - CoreBluetooth external for iOS and OS X. Use BLE between Mac
> and iOS or between iOS devices or between some of the great sensors
> available and your app. For the arduino hackers out there you will love
> pairing this external with the ReadBearLab BLE shield. Control anything
> from your Mac or iOS device!!!  (Also sold separately for $49).
>
> mergGoogle 1.0 - This external for iOS and OS X currently implements
> google spreadsheets. (Also sold separately for $49).
>
> mergMK 3.0 - This update to mergMK supports querying directions between
> locations.
>
> iOS 9 support - all the mergExt externals have now been updated for iOS 9
> support.
>
> The mergExt Complete bundle now weighs in at a hefty $1038 worth of
> individual products for only $299. Yes that’s right folks. We’ve cracked
> the ton!
>
> Special Price: 3 years of access to mergExt Complete for $499. That’s a
> huge $398 saving folks. Use this link to access the special deal
> http://mergext.com/special/  The first 5
> people taking advantage of the special price will also get an additional 6
> months at no extra charge. Get it while it’s hot!!!
>
> Cheers
>
> Monte
>
> --
> M E R Goulding 
> Software development services
> Bespoke application development for vertical markets
>
> mergExt  - There's an external for 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




-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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: function for greatest object in list less than or equal to a value

[J. Landman Gay]

On 10/11/2015 9:26 PM, dunb...@aol.com wrote:

function findItemLessThanIndex tData,tIndex
put comma & tIndex after tData
sort items of tData numeric
return  item itemOffset("5",tData) -1 of tData
end findItemLessThanIndex


I thought of that too, but it fails if tIndex isn't in the list. The 
example list was: "1,3,4,7,9" and the target limit was 5.


I couldn't see a way that avoids looping through all the values.

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