Re: LC 8 Property Inspector

[Mark Waddingham]

On 2015-10-14 15:59, Geoff Canyon wrote:
I've never found this to be the case. I have never had someone report a 
bug

to me because some other tool interfered with Navigator, or because
Navigator tripped up someone else's tool.


I wasn't saying Navigator ever caused a problem, I was more talking 
about how to construct an environment which minimises the chance of such 
a negative interaction *and* ensures the toolmakers don't have to do 
more work than necessary to actually write their tool.


I think Navigator is useful. I've used it in place of everything except 
the

script editor and the dictionary for over ten years.


Indeed - it is a nice compact tool - I've played with it over the years 
(at least the version which is currently in plugins) particularly when 
checking that we haven't broken anything in the engine :)


Again, unless I'm misunderstanding you, this isn't accurate -- 
Navigator

happily co-exists with every tool I know.


As I said above, I wasn't talking about specific tools, nor any specific 
problems at the moment.


I just want to make sure we make tool writing as easy and painless as 
possible - my thoughts on doing this are that we build a well 
maintained, well documented and simple API which all tools sit on. Any 
'hairy details' can sit below the API (just as the engine hides many 
hairy details of cross-platform development from script), and anything 
sitting on top the API can be assured of the environment which it runs 
in.


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

[Mark Waddingham]

On 2015-10-14 16:29, Geoff Canyon wrote:
I wasn't defending Navigator specifically, just pointing out that, in 
my
experience, the current framework allows for reasonably clean 
development

of tools.


But there *is* a framework :)

We've learnt a lot from trying to write new components in the existing 
IDE and it has not been easy in many cases - hence the determination we 
have of trying to drag the current IDE through into the modern era by 
re-underpinning it.


Through doing so, we'll hopefully get to a state that all components in 
the IDE are essentially optional and replaceable, and will all run on a 
common foundation (which would sit just above the IDE engine).


If you needed a sha1Digest function you'd probably not go off and write 
your own in LiveCode Script (unless it was something you were *really* 
interested in doing), you'd use the engine one.


I'd like a similar thing to be true at the IDE level. Ideally, there'd 
be a good set of IDE APIs which you'd be able to use when you need to do 
a certain thing in a tool - rather than having to go off and write your 
own (unless that is your specific interest of course!).


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

[Peter Haworth]

New version of lcStackBrowser coming out this week with Widget support.
Not super difficult but did involve some searching around to figure out how
to get the properties of a widget.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 

On Wed, Oct 14, 2015 at 8:28 AM, Mark Wieder  wrote:

> On 10/14/2015 07:28 AM, Geoff Canyon wrote:
>
> Yay, then hopefully I won't have to update Navigator much/at all.
>>
>
> You shouldn't have much trouble with it. Aside from spotty documentation,
> I added Extension/Widget support to PowerTools fairly easily.
>
>
> --
>  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: LC 8 Property Inspector

[Mark Wieder]

On 10/14/2015 07:28 AM, Geoff Canyon wrote:


Yay, then hopefully I won't have to update Navigator much/at all.


You shouldn't have much trouble with it. Aside from spotty 
documentation, I added Extension/Widget support to PowerTools fairly easily.


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

[Mark Waddingham]

On 2015-10-14 17:23, Mark Wieder wrote:

Exactly. And that's, for the most part, how PowerTools works as well.
The hard part of tool coexistence is when you have to cooperate with
frontscript handlers that may or may not do the right thing before you
have a chance to handle messages. Duelling frontscripts gets ugly.


Sounds like a good reason to have a well-written (and well documented 
*cough*) IDE API that allows you to subscribe for the critical 
notifications your tool needs to function correctly to me ;)


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

On 10/14/2015 07:40 AM, Mark Waddingham wrote:


If you needed a sha1Digest function you'd probably not go off and write
your own in LiveCode Script (unless it was something you were *really*
interested in doing), you'd use the engine one.


Given the recent demonstration of a poc sha1 collision, I'd like a 
sha2Digest function, but again, I'd use the functionality from the 
openssl library rather than foolishly crating my own.


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

[Mark Waddingham]

On 2015-10-14 17:19, Mark Wieder wrote:

Given the recent demonstration of a poc sha1 collision, I'd like a
sha2Digest function, but again, I'd use the functionality from the
openssl library rather than foolishly crating my own.


Slightly Off-Topic... But...

I wrote up a spec a while ago about digest functions in LC. There's a PR 
for the spec here:


https://github.com/livecode/livecode/pull/1897

Please feel free to read and add any comments on the syntax etc. and 
reasonings that are there.


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

[Mark Wieder]

On 10/14/2015 06:49 AM, Geoff Canyon wrote:


No. The IDE already provides messages that things have changed, and all
Navigator has to do is get its name on the list of message receivers. After
that Navigator just responds to the update requests it receives. It doesn't
have its own code for monitoring changes, and it is self-contained as
Richard says.


Exactly. And that's, for the most part, how PowerTools works as well.
The hard part of tool coexistence is when you have to cooperate with 
frontscript handlers that may or may not do the right thing before you 
have a chance to handle messages. Duelling frontscripts gets ugly.


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

[Geoff Canyon]

On Wed, Oct 14, 2015 at 10:13 AM, Mark Waddingham  wrote:

> [Widgets] aren't groups of underlying objects - they are black-boxes like
> the engine controls. Indeed, they are a mechanism for (essentially) writing
> engine controls incredibly easily and accessibly (relative to doing so in
> C++, at least) and they plug into LiveCode Script just like all the
> existing ones.


Yay, then hopefully I won't have to update Navigator much/at all.
___
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

[Geoff Canyon]

On Wed, Oct 14, 2015 at 10:21 AM, Mark Waddingham  wrote:

>
> Again, unless I'm misunderstanding you, this isn't accurate -- Navigator
>> happily co-exists with every tool I know.
>>
>
> As I said above, I wasn't talking about specific tools, nor any specific
> problems at the moment.


I wasn't defending Navigator specifically, just pointing out that, in my
experience, the current framework allows for reasonably clean development
of tools.
___
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

[Peter Haworth]

Hi Mark,
I found revIDEExtensionProperties and used it.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 

On Wed, Oct 14, 2015 at 10:45 AM, Mark Waddingham  wrote:

> For what you are doing, I suspect it is the underlying details about what
> the properties are and their 'meta' attributes which are really needed.
>
> There are functions in the LC8 IDE for getting thins information for all
> controls - using the metadata file which accompanies any widget - however,
> we really need to document them :)
>
> What approach did you take in the end?
>
> Mark.
>
> Sent from my iPhone
>
> > On 14 Oct 2015, at 18:33, Peter Haworth  wrote:
> >
> > Would be great if that were the case and maybe it will be eventually but
> > when I tried "get the keys of widget 1 of this card", I got an empty
> array.
> >
> > Widgets have their own set of properties which are defined as part of the
> > process of creating them. You get and set them as any other property but
> > lcStackbrowser needs to discover their names. They're somewhat akin to
> > custom properties in my mind but they don't show up as such in the IDE.
> >
> > Pete
> > lcSQL Software 
> > Home of lcStackBrowser  and
> > SQLiteAdmin 
> >
> > On Wed, Oct 14, 2015 at 10:07 AM, Richard Gaskin <
> ambassa...@fourthworld.com
> >> wrote:
> >
> >> Peter Haworth wrote:
> >>
> >>> New version of lcStackBrowser coming out this week with Widget support.
> >>> Not super difficult but did involve some searching around to figure out
> >>> how
> >>> to get the properties of a widget.
> >>
> >> If Widgets are a means of adding new objects to LC Script to compliment
> >> the existing ones, wouldn't "the properties" work as it always has?
> >>
> >> --
> >> 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
>
> ___
> 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: LC 8 Property Inspector

[Richard Gaskin]

Mark Wieder wrote:

The hard part of tool coexistence is when you have to cooperate with
frontscript handlers that may or may not do the right thing before you
have a chance to handle messages. Duelling frontscripts gets ugly.


A few years ago I proposed to my congressman that he introduce a bill 
mandating jail time for any LiveCode scripter who writes dev tools with 
frontScripts that don't pass system messages.


Oddly, the proposal was not taken seriously.

So it's up to us to enforce this voluntarily.

Thankfully it's just a single line of code, so we rarely see felony 
offenders.


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

[Richard Gaskin]

Peter Haworth wrote:

Typo - s/b get the properties of widget 1 of this card.

Believe me Richard, it doesn't work, as per Mark W's response.


I have no reason to doubt you. I was just hoping I'd missed some cool 
trick with the language.


I'm sure as LCB evolves it'll continue to do an ever better job of 
allowing Widgets to compliment and ultimately replace the objects we're 
used to working with in the ways we work with them.


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

[Peter Haworth]

Would be great if that were the case and maybe it will be eventually but
when I tried "get the keys of widget 1 of this card", I got an empty array.

Widgets have their own set of properties which are defined as part of the
process of creating them. You get and set them as any other property but
lcStackbrowser needs to discover their names. They're somewhat akin to
custom properties in my mind but they don't show up as such in the IDE.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 

On Wed, Oct 14, 2015 at 10:07 AM, Richard Gaskin  wrote:

> Peter Haworth wrote:
>
>> New version of lcStackBrowser coming out this week with Widget support.
>> Not super difficult but did involve some searching around to figure out
>> how
>> to get the properties of a widget.
>>
>
> If Widgets are a means of adding new objects to LC Script to compliment
> the existing ones, wouldn't "the properties" work as it always has?
>
> --
>  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: LC 8 Property Inspector

[Richard Gaskin]

Peter Haworth wrote:

Would be great if that were the case and maybe it will be eventually but
when I tried "get the keys of widget 1 of this card", I got an empty array.


I'm unable to do that here even with built-in objects in v7.1:

  get the keys of this stack -- throws error

  put the properties of this stack into tA; get the keys of tA -- works

Are you able to get "the keys" of built-in objects?

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC 8 Property Inspector

[Richard Gaskin]

Geoff Canyon wrote:
> I wasn't defending Navigator specifically, just pointing out that,
> in my experience, the current framework allows for reasonably clean
> development of tools.

In the case of RevNavigator even more so: your tool politely checks for 
the existence of revMenubar when it inits, and if it doesn't find one it 
inserts a slender frontScript to provide the handful of handlers it 
relies on.  This allows it to be enjoyed in the MetaCard IDE or even 
OpenCard along with the LiveCode IDE and conceivably any other, all 
fully self-contained, nimble, and (at least in my experience having used 
it in two different IDEs) error-free.


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

[Peter Haworth]

Typo - s/b get the properties of widget 1 of this card.

Believe me Richard, it doesn't work, as per Mark W's response.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 

On Wed, Oct 14, 2015 at 10:58 AM, Richard Gaskin  wrote:

> Peter Haworth wrote:
>
>> Would be great if that were the case and maybe it will be eventually but
>> when I tried "get the keys of widget 1 of this card", I got an empty
>> array.
>>
>
> I'm unable to do that here even with built-in objects in v7.1:
>
>   get the keys of this stack -- throws error
>
>   put the properties of this stack into tA; get the keys of tA -- works
>
> Are you able to get "the keys" of built-in objects?
>
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  
>  ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
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:
Tnx for the info on the ad blockers. 

Thinking for the long run, though, getting a wiki on a site without so many 
ads, in a version of Wiki that can be exported easily to another site, seems a 
good idea.

Best,
Bill

> On Oct 13, 2015, at 11:06 PM, Richard Gaskin  
> wrote:
> 
> William Prothero wrote:
> 
> > I use Safari because it synchronizes all my bookmarks between my
> > devices. I know there is a Firefox plugin that does that. I used
> > it, but there was an issue I can't remember when I upgraded to
> > Yosemite, so I switched. Firefox is a very good option, tho.
> 
> There's a JavaScript blocker for Safari too:
> 
> 
> -- 
> 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: LC 8 Property Inspector

[Richard Gaskin]

Peter Haworth wrote:

New version of lcStackBrowser coming out this week with Widget support.
Not super difficult but did involve some searching around to figure out how
to get the properties of a widget.


If Widgets are a means of adding new objects to LC Script to compliment 
the existing ones, wouldn't "the properties" work as it always has?


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

[J. Landman Gay]

It's likely you've never had interference issues with Navigator because users 
wouldn't be using more than one property inspector simultaneously. But my 
Zygodact system did interfere with the GLX framework and I had to rewrite it to 
accommodate GLX. It wasn't how I wanted things to work, but enough people were 
using GLX at the time that it was necessary. Fixing the problem required 
communication between me and the author. 

The conflict occurred because of different approaches when handling preferences 
files. Standardization would have avoided the issue. 

On October 14, 2015 8:59:51 AM CDT, Geoff Canyon  wrote:
>On Wed, Oct 14, 2015 at 4:14 AM, Mark Waddingham 
>wrote:
>> Great - how do you ensure that Mark's tools don't interfere with
>Geoff's
>> so users can use them side-by-side?
>>
>> If every toolmaker has to take into account every other toolmaker's
>'way
>> of doing things' you end up with a situation where one individual who
>wants
>> to write a tool needs to learn about everybody else's if they want to
>> distribute it for the benefit of all.
>
>
>I've never found this to be the case. I have never had someone report a
>bug
>to me because some other tool interfered with Navigator, or because
>Navigator tripped up someone else's tool.
>
-- 
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: LC 8 Property Inspector

[Mark Waddingham]

Well, as has been the subject of other threads on here and the forums, 'the 
properties' whilst well meaning has never been particularly well defined.

Monte did significant work on it a couple of years ago to make it work for 
lcVCS but that meant putting in specific code for the engine controls to ensure 
overlapping properties didn't affect the end result.

However, how to do that generally for widgets is not yet clear.

Mark.

Sent from my iPhone

> On 14 Oct 2015, at 18:07, Richard Gaskin  wrote:
> 
> Peter Haworth wrote:
>> New version of lcStackBrowser coming out this week with Widget support.
>> Not super difficult but did involve some searching around to figure out how
>> to get the properties of a widget.
> 
> If Widgets are a means of adding new objects to LC Script to compliment the 
> existing ones, wouldn't "the properties" work as it always has?
> 
> -- 
> 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: sha digest

[Richard Gaskin]

Mark Wieder wrote:


Mark Waddingham  writes:

I wrote up a spec a while ago about digest functions in LC. There's a PR
for the spec here:

https://github.com/livecode/livecode/pull/1897

Please feel free to read and add any comments on the syntax etc. and
reasonings that are there.


Looks. good.


+1

There's an sha256 I needed not long ago in Mark Smith's library, and its 
output matches what I get from other tools so it seems to be reasonably 
robust.


But given the importance of good cryptographic hashes, and that many are 
computationally intensive, I very much appreciate the thought going into 
this method for adding new ones.


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

sha digest

[Mark Wieder]

Mark Waddingham  writes:

> Slightly Off-Topic... But...

Well, you started it... 

> 
> I wrote up a spec a while ago about digest functions in LC. There's a PR 
> for the spec here:
> 
> https://github.com/livecode/livecode/pull/1897
> 
> Please feel free to read and add any comments on the syntax etc. and 
> reasonings that are there.

Looks. good. Comments added.

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

[Geoff Canyon]

On Wed, Oct 14, 2015 at 12:13 PM, Peter Haworth  wrote:

> New version of lcStackBrowser coming out this week with Widget support.
> Not super difficult but did involve some searching around to figure out how
> to get the properties of a widget.
>

Great, then my biggest problem is that I have two versions at present: one
that is function, but which has the spaghetti code from hell in it, and the
updated version, which is vastly cleaned up, but significantly buggy at
present. Picking up twelve-year-old code sucks.
___
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

[Dr. Hawkins]

On Mon, Oct 12, 2015 at 6:35 AM,  wrote:

> My gadget adds the index in a parameter to the function. if it already
> exists in the list, the addition is superfluous, but harmless.
>

But if the search list is "2, 4", and the search value is 3, doesn't this
return "3" rather than 2?


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

[Mark Waddingham]

For what you are doing, I suspect it is the underlying details about what the 
properties are and their 'meta' attributes which are really needed.

There are functions in the LC8 IDE for getting thins information for all 
controls - using the metadata file which accompanies any widget - however, we 
really need to document them :)

What approach did you take in the end?

Mark.

Sent from my iPhone

> On 14 Oct 2015, at 18:33, Peter Haworth  wrote:
> 
> Would be great if that were the case and maybe it will be eventually but
> when I tried "get the keys of widget 1 of this card", I got an empty array.
> 
> Widgets have their own set of properties which are defined as part of the
> process of creating them. You get and set them as any other property but
> lcStackbrowser needs to discover their names. They're somewhat akin to
> custom properties in my mind but they don't show up as such in the IDE.
> 
> Pete
> lcSQL Software 
> Home of lcStackBrowser  and
> SQLiteAdmin 
> 
> On Wed, Oct 14, 2015 at 10:07 AM, Richard Gaskin > wrote:
> 
>> Peter Haworth wrote:
>> 
>>> New version of lcStackBrowser coming out this week with Widget support.
>>> Not super difficult but did involve some searching around to figure out
>>> how
>>> to get the properties of a widget.
>> 
>> If Widgets are a means of adding new objects to LC Script to compliment
>> the existing ones, wouldn't "the properties" work as it always has?
>> 
>> --
>> 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

___
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

[Dr. Hawkins]

On Mon, Oct 12, 2015 at 4:24 PM, Geoff Canyon  wrote:

> function greatestLessThan pList,V
>sort items of pList descending numeric
>sort items of pList by each >= V
>return item 1 of pList
> end greatestLessThan


Something along these lines was what I'm trying to wrap my head around,
when it twisted my mind into a pretzel.

I came up with

*on* mouseUp

   *put* getNxtSmlst("2, 5, 8, 15, 22", 8)

*end* mouseUp


*function* getNxtSmlst list,floorVal



   *sort* items of list by cmpr(each,floorVal)




*end* getNxtSmlst


*function* cmpr val,flr



   *if* val < flr *then*

  *return* val -flr

   *else*

  *return* -1

   *end* *if*



*end* cmpr


But staying with pure intrinsics should be a wind, I'd think.

That one came from *wanting * to write,


sort items of theList descending by (each <= floor) * (floor-each)


--but aside from liveCode not coercing the logical to a 1/0 value (as I
thought it did--too many languages over the years!), I think it misses the
case where the value is in the list.

This is always going to have a relatively small number of entries in the
list; it would be more than unusual to have more than a couple of dozen
transitions between the "canned" paragraph text and the values merged in.
The function will be called on mouseMove, though, to pop up an field over
the merge values as the mouse passes over them.

I know that the elements of an array aren't in any particular order, but
does keys return them in numeric order if they are all numeric?  (Some
distant memory says that this is an exception.  The keys also would have
been added in numeric order.  For that matter, they could be stored on
render.  In any event, I think the algorithm can presume that the numbers
are ordered.

And I'm amazed at how much more I'm learning about other pieces of liveCode.


-- 
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: [ANN] LiveCode List Processor

[Mark Waddingham]

On 2015-10-14 06:44, Richard Gaskin wrote:

I'm not so sure.  At first I was, but after Mark and Mark explained
how common the ? convention is elsewhere I'm inclined to think that
the most important thing is that the library works as *you* want it
to, and if others learn a thing or two along the way as I did so much
the better.


I'm not so sure either.

Here's the thing - the engine has long accepted a very flexible 
'identifier' token - including (among most other things) the '?' and the 
'.' character. Under the remit of 'avoiding symbol usage in the actual 
syntax as much as possible', then this is fine.


However, the allowing of flexibility of identifiers to this extent 
limits future options and the question is whether being able to use '?' 
and '.' in handler names and variable names is *really worth* the 
curtailing of future endeavour which it represents.


With the spectre of Open Language somewhere on the horizon it becomes 
important to decide whether we should push people away from using 
non-standard identifier characters, or restrict the operators that 
people might be able to cook up in future language extensions.


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: scaleFactor strangeness

[Mark Waddingham]

On 2015-10-13 22:07, Scott Rossi wrote:

Many of us tried to do the same thing when the feature was first
announced.  Unfortunately, you can't really use it for a zoom effect, 
at
least not since I last looked into this.  As you've seen, the stack 
jumps
around as the scale is changed, and even if you reposition it 
dynamically,

the results aren't the best.


The 'scaleFactor' of a stack was implemented for a specific reason - as 
stated in the dictionary:


"Use the scaleFactor property when developing to scale down stacks that 
are larger than the available screen space."


It was neither intended as, nor designed to be used as, a general method 
for scaling stack content which is a somewhat different problem.


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: scaleFactor strangeness

[Mark Waddingham]

On 2015-10-14 00:38, Richard Gaskin wrote:

Marty Knapp wrote:

It would nice to see this developed more for sure. At this point, I'd
settle for something even quasi - elegant, just for my users to be 
able

to have a magnified view of the screen.


FWIW, for folks making productivity apps in which scaling a group
would be useful:

Can we have the scalingFactor available for the contents of groups?



This would indeed be nice (and, indeed, it has come up many times 
before) - however there are two problems.


The first is that all co-ordinates from a script point of view in the 
engine are integers, rather than floating point. This becomes important 
when you are starting to talk about transformations - for example 
scaling down an object of width 9 by a factor of 2 means the object's 
width is 4.5. So in this scenario the rect of an object within a scaled 
group would be inaccurate with how things are currently.


The second is that the current script's co-ordinate model is such that 
all co-ordinates are relative to the top-left of the current card rather 
than the owning group.


Now, the first can probably be ignored if the second is solved and 
co-ordinates are always expressed relative to the containing groups 
co-ordinate system (i.e. if you put a 10x10 button at 10,10 inside a 
group which scales things down by half, then the buttons rect would be 
10,10,20,20 but it would appear at 5,5,10,10 on the card). However, I'm 
not sure how that squares up with script's idea of what co-ordinates 
should be relative to from a script point of view - we've all got very 
used to a single flat co-ordinate system which means there's no need for 
transforming between 'co-ordinates relative to one object' to 
'co-ordinates relative to another object'.


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

[Richard Gaskin]

William Prothero wrote:

> I use Safari because it synchronizes all my bookmarks between my
> devices. I know there is a Firefox plugin that does that. I used
> it, but there was an issue I can't remember when I upgraded to
> Yosemite, so I switched. Firefox is a very good option, tho.

There's a JavaScript blocker for Safari too:


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

Programming Help Needed

[Peter Bogdanoff]

Hi all,

I have need of some programming help to optimize some script.

I have some text search results that are filtered and and mongered to display 
correctly for my application. My existing script uses text in a field as the 
source and final display for the search results. The results are also sorted by 
use of an array.

What I have now works more-or-less in LC 6, but is very slow (like 20-30 
seconds for 1,000 results) to display the modified search results in LC 7. The 
array portion of the script sorts the results and, in LC 7, is taking about 5 
seconds to do just that task. In LC6 this same process took about a total of 
4-5 seconds.

I realize that what I have done myself could be optimized to be much better and 
faster by someone better than I at this, and there seems to be a slowdown in 
LC7’s operation to be overcome.

I think that for an experienced programmer this is a 1-3 hour job. I will pay 
an hourly fee to someone who will do this as well as sign a non-desclosure.

Please contact me off-list at bogdan...@me.com 

Thanks,

Peter Bogdanoff
UCLA
___
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: scaleFactor strangeness

[Richard Gaskin]

Mark Waddingham wrote:

On 2015-10-14 00:38, Richard Gaskin wrote:

Can we have the scalingFactor available for the contents of groups?



This would indeed be nice (and, indeed, it has come up many times
before) - however there are two problems.

The first is that all co-ordinates from a script point of view in the
engine are integers, rather than floating point. This becomes important
when you are starting to talk about transformations - for example
scaling down an object of width 9 by a factor of 2 means the object's
width is 4.5. So in this scenario the rect of an object within a scaled
group would be inaccurate with how things are currently.

The second is that the current script's co-ordinate model is such that
all co-ordinates are relative to the top-left of the current card rather
than the owning group.

Now, the first can probably be ignored if the second is solved and
co-ordinates are always expressed relative to the containing groups
co-ordinate system (i.e. if you put a 10x10 button at 10,10 inside a
group which scales things down by half, then the buttons rect would be
10,10,20,20 but it would appear at 5,5,10,10 on the card). However, I'm
not sure how that squares up with script's idea of what co-ordinates
should be relative to from a script point of view - we've all got very
used to a single flat co-ordinate system which means there's no need for
transforming between 'co-ordinates relative to one object' to
'co-ordinates relative to another object'.


Maybe those could be handled as the HTML Canvas does, in which the 
coordinates you use remain the same and the scale factor takes case of 
the translation for us when rendering.





Isn't that how Skia's canvas works also?

Workable for LC?

If we need to know the on-screen physical rect of a control (as distinct 
from its logical scaled rect) perhaps "the effective rect"?


--
 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: scaleFactor strangeness

[Monte Goulding]

> On 14 Oct 2015, at 5:57 pm, Mark Waddingham  wrote:
> 
> The first is that all co-ordinates from a script point of view in the engine 
> are integers, rather than floating point. This becomes important when you are 
> starting to talk about transformations - for example scaling down an object 
> of width 9 by a factor of 2 means the object's width is 4.5. So in this 
> scenario the rect of an object within a scaled group would be inaccurate with 
> how things are currently.
> 
> The second is that the current script's co-ordinate model is such that all 
> co-ordinates are relative to the top-left of the current card rather than the 
> owning group.

Don’t both of these issues disappear if you create a stack view object instead 
of group scalefactor? Given a stack which already has a scaleFactor? Object 
rects remain relative to the stack whether the stack is presented as a window 
or in a view. From the perspective of the stack with the window it would just 
have a single view object which has a stackName and a rect.. perhaps some other 
stuff like visible etc...

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: [ANN] mergExt: BLE, Google spreadsheets, Map directions, iOS 9 & special price

[Ben Rubinstein]

Just to testify - the new mergBLE arrived right on time to save me struggling 
through the process of building my own externals, and did exactly what I needed.


In fact since I was completely unable to locate the resources for building 
externals, it meant I could stop writing a native app, and immediately become 
more productive.


Thank you Monte for your continuing work, which for me absolutely bridges the 
gap to making LC for iOS a real option. You're a LiveCode Hero.


Ben

On 12/10/2015 03:31, Monte Goulding 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

Re: Learning Materials

[Antti Ilola]

Firefox and Adblock Plus, no ads.

2015-10-14 9:06 GMT+03:00 Richard Gaskin :

> William Prothero wrote:
>
> > I use Safari because it synchronizes all my bookmarks between my
> > devices. I know there is a Firefox plugin that does that. I used
> > it, but there was an issue I can't remember when I upgraded to
> > Yosemite, so I switched. Firefox is a very good option, tho.
>
> There's a JavaScript blocker for Safari too:
> 
>
>
> --
>  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: scaleFactor strangeness

[Mark Waddingham]

On 2015-10-14 09:46, Richard Gaskin wrote:

Maybe those could be handled as the HTML Canvas does, in which the
coordinates you use remain the same and the scale factor takes case of
the translation for us when rendering.


The problem is the mixture of co-ordinate systems on a card, if you have 
a scaled button in a group and an unscaled button outside of a group - 
how do coords work in an arbitrary script potentially unrelated to 
either?


If I'm sitting at the card level and I ask the scaled button for its 
rect, and the unscaled button for its rect, what do I get in each case?


If I'm sitting at the scaled button level and I ask the unscaled button 
for its rect, what do I get?


Let's say I want the button outside of the group to sit directly over 
the (scaled) button in the group. Right now, I would do:


  set the rect of button "Outside" to the rect of button "Inside"

However, in this newly imagined world where the 'inside' button is 
actually scaled and the 'outside' button is not, there's no clear 
agreement on what the 'rects' mean - should it become a matter of 
context of script? And, if so, is that always 100% well defined?. (This 
is even without taking into account the huge mathematical error which 
accumulates when you are restricted to rects being on an integer grid, 
and trying to take into account partly scaled and unscaled 
combinations).


The main thing which we need to avoid is the case where someone writing 
a 'reusable component' has to be aware of whether said component is 
sitting in a scaled group, compared to an unscaled group. If components 
have to be aware of this to function correctly, then it makes them a 
great deal more difficult to write.



Isn't that how Skia's canvas works also?


Yes - and how the graphics library we built on top of it works, and how 
the Canvas library used by LCB works.



Workable for LC?


Pretty much every single UI system since even before MetaCard appeared 
operated in a very standard way. Child controls were relative to their 
owning group.


MetaCard, I'm sorry to say, made a significant error of judgement (with 
hindsight of course) when implementing backgrounds and groups. 
Backgrounds should have been as HyperCard - full card things - i.e. 
layers which sat underneath the card. Groups should have been like every 
other toolkit which was out there at the time - a collection of controls 
whose rects were relative to the top-left of their owner (well, more 
exactly, relative to a co-ordinate system defined by the group).


The problem is that, 20 years on, our entire community is used to the 
way things are. All code is written to that standard and seeing how to 
move things into a model which the modern world considers the standard 
way of doing things without putting a line in the sand and saying 'we 
really have to break everything if you want to use this new feature' 
has, thus far, defeated me - sorry!


(By the way, working out how it might work from a script point of view 
is one thing; then of course you have to work out how the engine code 
can actually be moved forward to allow it).


Perhaps there is something simple and obvious which I'm missing, but I'm 
honestly not sure.


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: scaleFactor strangeness

[Mark Waddingham]

On 2015-10-14 11:01, Monte Goulding wrote:

That’s what I mean and if you present it somewhere else (different
window or view) then it moves and the previous view is emptied. If you
want two instances you clone the stack.


Yes - that would be the simplest way to do things (both technically, and 
from an actual use point of view).


I'll need to ponder where we are with the various 'abstractions' in the 
engine. The main problem is that MCStack has long been a hybrid 
window-stack - really, a 'stack' and a 'window' are two distinct 
concepts and I'm not sure they aren't entirely unentangled yet (Ian has 
worked on separating things out on and off for years - during the 
process of implementing High-DPI support and things like 
fullScreenMode).


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: [ANN] mergExt: BLE, Google spreadsheets, Map directions, iOS 9 & special price

[Monte Goulding]

Thanks Ben

I’m looking forward to hearing about the things people make with mergBLE. 
Definitely lots of possibilities for the arduino fans.

Cheers

Monte

> On 14 Oct 2015, at 7:33 pm, Ben Rubinstein  wrote:
> 
> Just to testify - the new mergBLE arrived right on time to save me struggling 
> through the process of building my own externals, and did exactly what I 
> needed.
> 
> In fact since I was completely unable to locate the resources for building 
> externals, it meant I could stop writing a native app, and immediately become 
> more productive.
> 
> Thank you Monte for your continuing work, which for me absolutely bridges the 
> gap to making LC for iOS a real option. You're a LiveCode Hero.
> 
> Ben
> 
> On 12/10/2015 03:31, Monte Goulding 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 
> 
___
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-13 17:35, Richard Gaskin wrote:

It's possible to invest our time enumerating reasons why people
shouldn't enjoy crafting tools in LiveCode, but to what end?

Any IDE (or IDE "tool" or "framework" or any other subset) is just a
collections of stacks. The one thing we know about LiveCode
programmers is that they know how to program in LiveCode.  Many of
them are quite good at it.


This is where I have to disagree - an 'IDE' is *not* 'just' a collection 
of stacks. Those stacks have to work together in a consistent way, agree 
on certain conventions, protocols and 'how things should generally fit 
together'. It is a 'framework' which does this (even if it is one which 
contains no code, and just a long list of 'do's' and 'don't's).



I see no harm in encouraging people to just continue doing what
they've been enjoying for decades:  making tools to help their work
and sharing them with others.


Indeed - there is no harm at all - it is actually quite important. I 
wasn't implying that it shouldn't be encouraged...



All of the tools I've referred to - Mark Weider's, Bjornke's, Geoff's,
Peter's, and others' - exist.  Why not have more?  Why not have a
convenient launcher for them?


Great - how do you ensure that Mark's tools don't interfere with Geoff's 
so users can use them side-by-side?


If every toolmaker has to take into account every other toolmaker's 'way 
of doing things' you end up with a situation where one individual who 
wants to write a tool needs to learn about everybody else's if they want 
to distribute it for the benefit of all.



Why not have an IDE for pro devs, another for kids, and other for
educators, and others for just about anything people might want to do?


Again, let us not confuse 'IDE' with 'IDE Framework'.


It's possible to imagine a perfect circle, but in the natural world
none exists.  All systems are imperfect, influenced by subtle but
pervasive forces that ultimately alter them from their ideal form.
Anything that seems otherwise lives in the space between design specs
and shipping. :)  Even the OSes we love are riddled with kludgey
workarounds - not that we should pursue kludges, but it's no more
useful to postpone everything until a perfect system exists.


Things are never perfect, it is true - but most people's daily lives are 
governed by rules, regulations and policies to ensure that everyone can 
co-exist (reasonably?) 'happily'. (Or at least function without huge 
amount of friction at every interaction).


My main assertion here is that I don't think 'the engine' in its current 
form provides a sufficiently strict set of such things for the purposes 
of interchangeable IDE Tool writing so there needs to be a concerted 
effort to build something on top of it which is.



Ultimately you and I are describing the same goal, a modular and
lightweight IDE system in which tools are plentiful and
interchangeable, something Ken Ray and others have been advocating
since the engine acquisition in 2003.


Indeed - advocacy and implementation are two entirely separate things 
though - which is perhaps why no such widespread 'lightweight IDE 
system' has appeared (to my knowledge at least).



And there is one salient aspect: neither of us is describing an IDE
that exists today.


I cannot agree there. You may be describing an IDE which does not exist 
today - some sort of mystical entity which will just appear naturally 
out of a lot of people playing around in a sandpit. Unfortunately, I 
don't have much confidence in chaos producing anything in any 
particularly useful timeframe (the mathematician in me screams that the 
numbers just don't add up in that regard).


On the other hand, I am describing an IDE (Framework) which is currently 
in the process of being built - we are working quite hard to try and 
separate out what tools in a LiveCode IDE need to function from what is 
specific to the tools themselves. As I've already said, we are trying to 
build APIs upon which any tool written by anyone could sit and still 
work together with any other tool written on the same APIs.



All I'm offering here is encouragement for the things that led to this
thread, an acknowledgement that some folks like the App Browser and
others like the Project Browser and still others like Geoff Canyon's
Navigator and others like their own.  And the same goes for object
creation tools, and inspectors, and the rest.


What I'm offering here is more than encouragement - which means I hope 
that things might actually change :)


There are a number of people who are interested in creating IDE Tools - 
it is clear - indeed, many such tools already exist.


My offer to those who are interested in this are of things is simply 
this:


Take a look at what we are trying to do with the LC8+ IDE, dig around in 
the libraries we are creating. Play with moving your tools to those APIs 
which are gradually being chiselled out of the monolithic system which 
was there before, talk to us and 

Re: scaleFactor strangeness

[Mark Waddingham]

On 2015-10-14 10:21, Monte Goulding wrote:

Don’t both of these issues disappear if you create a stack view object
instead of group scalefactor? Given a stack which already has a
scaleFactor? Object rects remain relative to the stack whether the
stack is presented as a window or in a view. From the perspective of
the stack with the window it would just have a single view object
which has a stackName and a rect.. perhaps some other stuff like
visible etc...


Yup - if you have a 'stackview' control - then the problem goes away 
because you have a nice clear dividing line between objects in one 
co-ordinate system compared to the other.


We'd probably want some explicit syntax for working out the rect of an 
object in a stackview, from the point of view of the stack containing 
the stackview; and also some means to communicate from the embedded 
stack to the host view... However, perhaps both of these things are 
unnecessary - the stacks could just as well communicate by sharing a 
common library.


Basically, there aren't really any difficult technical problems if you 
limit stackviews to being 'the ability to display a stack in a subpart 
of another stack, rather than a window' with no more integration beyond 
that, other than them being stacks.


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: scaleFactor strangeness

[Monte Goulding]

> On 14 Oct 2015, at 7:44 pm, Mark Waddingham  wrote:
> 
> Yup - if you have a 'stackview' control - then the problem goes away because 
> you have a nice clear dividing line between objects in one co-ordinate system 
> compared to the other.
> 
> We'd probably want some explicit syntax for working out the rect of an object 
> in a stackview, from the point of view of the stack containing the stackview; 
> and also some means to communicate from the embedded stack to the host 
> view... However, perhaps both of these things are unnecessary - the stacks 
> could just as well communicate by sharing a common library.

I don’t think the communication is necessary as we can communicate in the same 
ways we currently do between stacks. Some stack object coordinate -> coordinate 
system it is presented in translation would probably already be helpful.

> Basically, there aren't really any difficult technical problems if you limit 
> stackviews to being 'the ability to display a stack in a subpart of another 
> stack, rather than a window' with no more integration beyond that, other than 
> them being stacks.

That’s what I mean and if you present it somewhere else (different window or 
view) then it moves and the previous view is emptied. If you want two instances 
you clone the stack.

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

[Geoff Canyon]

Interesting -- does/did GLX remove the update messages the IDE sends? Other
than that, I don't think there's anything Navigator needs/does that could
cause a problem, but of course I'm not really thinking about it thoroughly.
If someone complained I might, but Navigator has been mostly unsupported
for some time now.

On Wed, Oct 14, 2015 at 1:13 PM, J. Landman Gay 
wrote:

> It's likely you've never had interference issues with Navigator because
> users wouldn't be using more than one property inspector simultaneously.
> But my Zygodact system did interfere with the GLX framework and I had to
> rewrite it to accommodate GLX. It wasn't how I wanted things to work, but
> enough people were using GLX at the time that it was necessary. Fixing the
> problem required communication between me and the author.
>
> The conflict occurred because of different approaches when handling
> preferences files. Standardization would have avoided the issue.
>
> On October 14, 2015 8:59:51 AM CDT, Geoff Canyon 
> wrote:
> >On Wed, Oct 14, 2015 at 4:14 AM, Mark Waddingham 
> >wrote:
> >> Great - how do you ensure that Mark's tools don't interfere with
> >Geoff's
> >> so users can use them side-by-side?
> >>
> >> If every toolmaker has to take into account every other toolmaker's
> >'way
> >> of doing things' you end up with a situation where one individual who
> >wants
> >> to write a tool needs to learn about everybody else's if they want to
> >> distribute it for the benefit of all.
> >
> >
> >I've never found this to be the case. I have never had someone report a
> >bug
> >to me because some other tool interfered with Navigator, or because
> >Navigator tripped up someone else's tool.
> >
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: scaleFactor strangeness

[Richard Gaskin]

Mark Waddingham wrote:

On 2015-10-14 09:46, Richard Gaskin wrote:

Maybe those could be handled as the HTML Canvas does, in which the
coordinates you use remain the same and the scale factor takes case of
the translation for us when rendering.


The problem is the mixture of co-ordinate systems on a card, if you have
a scaled button in a group and an unscaled button outside of a group -
how do coords work in an arbitrary script potentially unrelated to
either?


How is that handled in HTML's Canvas?  Is the SVG Canvas any different?

I don't want to talk you out of adding the stack viewer object if that's 
easier to do (that's the one thing I miss from Gain Momenum), but given 
how HTML5 and SVG allow different scales for different objects I'd favor 
any solution that reduces learning time for folks familiar with those 
popular solutions.


--
 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: From any button script, how can I reset the scrollbar of a field to the "top" ?

[Devin Asay]

> On Oct 14, 2015, at 6:43 AM, Francis Nugent Dixon  wrote:
> 
> Hi from Beautiful Brittany,
> 
> This is a beginners question (except that I am not a beginner)
> I've tried everything I know to do this, but all the commands
> I tried came up with an error. Sounds stupid, don't it ?
> 
> Is there a soul to help me out ?
> 
> -Francis

Did you try ‘set the vScroll of fld “foo” to 0’?

Devin


Devin Asay
Office of Digital Humanities
Brigham Young University

___
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: Forcing string comparisons, or When is "0" not 0?

[Dr. Hawkins]

On Wed, Oct 14, 2015 at 1:19 PM, Devin Asay  wrote:

> Shouldn’t there be a way to force a string comparison? I know LC tries to
> be all helpful about casting numerals as numbers, but what if I want to
> know if it’s the exact string?
>

if (space & field "Display" ) = (space & someValue) then  . . .


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

[Richard Gaskin]

 William Prothero wrote:
> Richard:
> Tnx for the info on the ad blockers.
>
> Thinking for the long run, though, getting a wiki on a site without
> so many ads, in a version of Wiki that can be exported easily to
> another site, seems a good idea.

Agreed.  Feel free to discuss it with the Max, the current wiki owner. 
He's welcome to write me anytime - he's been very helpful in the 
community, esp. in the forums.


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

[Geoff Canyon]

On Wed, Oct 14, 2015 at 2:05 PM, Richard Gaskin 
wrote:

> Geoff Canyon wrote:
> > I wasn't defending Navigator specifically, just pointing out that,
> > in my experience, the current framework allows for reasonably clean
> > development of tools.
>
> In the case of RevNavigator even more so: your tool politely checks for
> the existence of revMenubar when it inits, and if it doesn't find one it
> inserts a slender frontScript to provide the handful of handlers it relies
> on.  This allows it to be enjoyed in the MetaCard IDE or even OpenCard
> along with the LiveCode IDE and conceivably any other, all fully
> self-contained, nimble, and (at least in my experience having used it in
> two different IDEs) error-free.


Wow, check me out. I hope I haven't broken that behavior with my recent
round of updates. I'll check.

gc
___
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: I have cc’d this to Max.

Max: Your Wiki site looks really great and could become a very valuable 
community documentation resource. What we’re thinking, in this thread, is that 
as a long term investment it would be more optimum to host the wiki on a site 
that has no (or much less) advertising and has a facility for exporting the 
wiki to other servers if needed in the future. After all, we hope Livecode 
lives on after we all exit the scene.

Richard Gaskin has offered to host the wiki on his server, with a unique domain 
at no cost to us. I think this could become an incredible resource. The thread 
on this topic has some ideas about various levels of documentation, running 
from simple command documents to  “how to” segments on doing specific tasks in 
livecode, to links to the Livecode lessons site for more complete app building 
cookbook type resources.

If you are interested, please contact Richard Gaskin and see if this appeals to 
you, or is even possible from the Wikia site.

Your wiki site has wonderful potential. Here’s hoping it gets lots of community 
input.

Best,
Bill Prothero

William A. Prothero
http://es.earthednet.org/

___
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: Forcing string comparisons, or When is "0" not 0?

[Paul Dupuis]

if fld "Display" contains "." then

of if you're just concerned with it ending with "."

if fld "Display ends with "." then


___
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

[J. Landman Gay]

On 10/14/2015 1:54 PM, Geoff Canyon wrote:

Interesting -- does/did GLX remove the update messages the IDE sends?


I don't know but I doubt it. The problem in my case was that Zygodact's 
Registration dialog needs to store info in a prefs stack, and is 
intended to be opened before the mainstack is displayed. My method was 
to open the prefs stack, store the info, and remove it on the assumption 
that Zygodact should not interfere with the developer's instructions 
about whether the prefs should be in RAM or not. If their script opens a 
prefs file later, no problem. If not, prefs won't hang around.


GLX has startup handlers that also work with prefs, and GLX leaves the 
stack open. When Zygodact closed it soon afterward, GLX errored.


There were two ways to solve it. GLX could have checked the openstacks 
and reopened it if necessary, or Zygodact could have just left the file 
open. It was easier for me to leave it open, which hasn't seemed to 
interfere really with anything else the developer did with it except 
that there's a possibly unwanted stack in RAM.


But the point is, there was interference that required me to know what 
another tool (or framework in this case) was doing.


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

Forcing string comparisons, or When is "0" not 0?

[Devin Asay]

In a simple calculator exercise I’m doing with my class I need to know whether 
the string in a field is "0" vs. "0.” (The latter can occur when the user 
enters zero + dot into the calculator display field.) If it’s just “0” the next 
next number key press should replace the contents of the display field; if it’s 
“0.” the next number key should be placed *after* the display field. But if the 
contents of fld “display” is “0.”, all of the following evaluate as TRUE:

   fld “display” = “0.” # as expected
   fld “display" = 0 # makes sense, because right side of comparison is a number
   fld “display” = “0” # seems like this ought to be comparing string to string
   char 1 to 2 of fld “display” is “0” # Really?!
 
Shouldn’t there be a way to force a string comparison? I know LC tries to be 
all helpful about casting numerals as numbers, but what if I want to know if 
it’s the exact string?

I guess I could do this dance:

  if char 1 of fld “display” is “0” and char 2 of fld “display” is NOT “0” then…

It’s seems to complicated for such a simple thing, especially for explaining to 
novice programmers. Maybe I’m missing something obvious.

Devin


Devin Asay
Office of Digital Humanities
Brigham Young University

___
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

[Geoff Canyon]

Ah, okay, I do none of that.

gc

On Wed, Oct 14, 2015 at 4:42 PM, J. Landman Gay 
wrote:

> On 10/14/2015 1:54 PM, Geoff Canyon wrote:
>
>> Interesting -- does/did GLX remove the update messages the IDE sends?
>>
>
> I don't know but I doubt it. The problem in my case was that Zygodact's
> Registration dialog needs to store info in a prefs stack, and is intended
> to be opened before the mainstack is displayed. My method was to open the
> prefs stack, store the info, and remove it on the assumption that Zygodact
> should not interfere with the developer's instructions about whether the
> prefs should be in RAM or not. If their script opens a prefs file later, no
> problem. If not, prefs won't hang around.
>
> GLX has startup handlers that also work with prefs, and GLX leaves the
> stack open. When Zygodact closed it soon afterward, GLX errored.
>
> There were two ways to solve it. GLX could have checked the openstacks and
> reopened it if necessary, or Zygodact could have just left the file open.
> It was easier for me to leave it open, which hasn't seemed to interfere
> really with anything else the developer did with it except that there's a
> possibly unwanted stack in RAM.
>
> But the point is, there was interference that required me to know what
> another tool (or framework in this case) was doing.
>
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Forcing string comparisons, or When is "0" not 0?

[Devin Asay]

> On Oct 14, 2015, at 2:39 PM, Paul Dupuis  wrote:
> 
> if fld "Display" contains "." then
> 
> of if you're just concerned with it ending with "."
> 
> if fld "Display ends with ".” then

Yeah, that works, but then I end up with a mess like this:

  if fld “display” = 0 AND NOT fld “display” ends with “.” then … 

But this may be what I have to go with. That’s at least *sort of* 
comprehensible to a newbie.

I'll have to explain to them that “LiveCode tries its hardest to make something 
into a number if there is any chance at all that it could be a number, so we 
have to do an extra check to make sure it’s not this specific type of numeric 
expression that happens to end with a dot.”
:-/

Devin

Devin Asay
Office of Digital Humanities
Brigham Young University

___
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

[Craig Newman]

Hi.

The param "3" would be added to the list. The sorted list would be:
"2,3,4". When the itemOffset finds the "3", the item just before it would be 
"2". That is how it works. To find the item just before itemOffset does.

This is faster than any of the "repeat for each..." variants I have seen here. 
The reason, as I stated earlier as an uninformed opinion, is that the low-level 
"sort" routine beats the high-level "repeat" routine. 

Craig

Sent from my iPhone

> On Oct 14, 2015, at 2:25 PM, Dr. Hawkins  wrote:
> 
>> On Mon, Oct 12, 2015 at 6:35 AM,  wrote:
>> 
>> My gadget adds the index in a parameter to the function. if it already
>> exists in the list, the addition is superfluous, but harmless.
> 
> But if the search list is "2, 4", and the search value is 3, doesn't this
> return "3" rather than 2?
> 
> 
> -- 
> 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: scaleFactor strangeness

[Mark Waddingham]

The HTML5 canvas doesn't have that problem - canvas is just a render target you 
can use 2d vector drawing commands on - it doesn't have any notion of objects.

SVG and HTML's object model has always been children's coords are relative to 
the parent so you have to think about coordinate systems when you code 
(assuming you are using transforms of any kind and are passing points between 
related objects and are actually scripting anything that relies on coords).

The problem is that (ignoring coords being integers in LC at the moment - which 
is also a problem) all current scripts that exist assume coords are relative to 
the card - and I'm not sure there's a way to bridge those two things in a 
transparent / easy way.

It is the scripting part that is the potential issue, rather than the rendering 
part.

LiveCode's message path encourages you to factor out common code into 
ancestors, and as such might receive coordinates from any descendent - and this 
would complicate scripting in any such situation if transforms were involved 
somewhere between the origin of the coordinate and where that coordinate is 
handled.

Then again, perhaps that is okay - it's a necessary tax on the scripter for 
using that feature.

Hmm.

Mark.



Sent from my iPhone

> On 14 Oct 2015, at 21:12, Richard Gaskin  wrote:
> 
> Mark Waddingham wrote:
>>> On 2015-10-14 09:46, Richard Gaskin wrote:
>>> Maybe those could be handled as the HTML Canvas does, in which the
>>> coordinates you use remain the same and the scale factor takes case of
>>> the translation for us when rendering.
>> 
>> The problem is the mixture of co-ordinate systems on a card, if you have
>> a scaled button in a group and an unscaled button outside of a group -
>> how do coords work in an arbitrary script potentially unrelated to
>> either?
> 
> How is that handled in HTML's Canvas?  Is the SVG Canvas any different?
> 
> I don't want to talk you out of adding the stack viewer object if that's 
> easier to do (that's the one thing I miss from Gain Momenum), but given how 
> HTML5 and SVG allow different scales for different objects I'd favor any 
> solution that reduces learning time for folks familiar with those popular 
> solutions.
> 
> -- 
> 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: Forcing string comparisons, or When is "0" not 0?

[Devin Asay]

> On Oct 14, 2015, at 2:40 PM, Dr. Hawkins  wrote:
> 
> On Wed, Oct 14, 2015 at 1:19 PM, Devin Asay  wrote:
> 
>> Shouldn’t there be a way to force a string comparison? I know LC tries to
>> be all helpful about casting numerals as numbers, but what if I want to
>> know if it’s the exact string?
>> 
> 
> if (space & field "Display" ) = (space & someValue) then  . . .

Believe it or not, when field “display” contains “0.”, the following evaluates 
to TRUE:

  if (space & fld “display”) = (space & “0”) then … # TRUE!

And even:

  if (space & fld "display" & space) = (space & "0" & space) then … # TRUE 
AGAIN!

It’s the space that’s the problem. Any other character seems to do the trick:

  if ("!" & fld "display") = ("!" & "0”) then … # FALSE

Try explaining that to newbies. “Oh, I’m just coercing LiveCode to cast the 
field contents as a string instead of a number.”

Blank stares and crickets… :)

Devin


Devin Asay
Office of Digital Humanities
Brigham Young University

___
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: scaleFactor strangeness

[Monte Goulding]

> On 14 Oct 2015, at 8:07 pm, Mark Waddingham  wrote:
> 
> I'll need to ponder where we are with the various 'abstractions' in the 
> engine. The main problem is that MCStack has long been a hybrid window-stack 
> - really, a 'stack' and a 'window' are two distinct concepts and I'm not sure 
> they aren't entirely unentangled yet (Ian has worked on separating things out 
> on and off for years - during the process of implementing High-DPI support 
> and things like fullScreenMode).

Yeah, Im sure there would be lots to do. I think there’s lots of places that 
assume a stack is either open and has a window or not open or if it doesn’t 
have a window it needs one etc. Still an interesting idea and seemingly 
relatively feasible compared to messing with groups.
___
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: LC8 lineOffset

[Peter Haworth]

I'd have to recreate the issue since I'm not using the workaround I just
posted.  But Mark posted several stacks that illustrate the problem to the
bug report.
Pete

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 

On Wed, Oct 14, 2015 at 5:30 PM, Charles Warwick <
char...@techstrategies.com.au> wrote:

>
> Do either of you have a sample stack you can send me that exhibits this
> problem?
>
> I went to look at this a while back, but couldn't replicate it and there
> wasn't a sample stack in the bug report for me to try.
>
>
> --
> Sent from my iPhone
>
> On 15 Oct 2015 at 09:28:18 AEST, Mark Talluto 
> wrote:
>
> > > On Oct 14, 2015, at 4:05 PM, Peter Haworth  wrote:
> > >
> > > Has anyone run into problems using lineOffset in LC8?  I'm seeing it
> return
> > > an incorrect line number in some cases.
> > >
> > > I'm wondering if it could have something to do with the data I'm
> searching,
> > > since some lines have the characters \n embedded in them
> > >
> >
> >
> > It may be related to bug:
> http://quality.runrev.com/show_bug.cgi?id=15512 <
> http://quality.runrev.com/show_bug.cgi?id=15512>
> >
> >
> > Best regards,
> >
> > Mark Talluto
> > canelasoftware.com 
> > CassiaDB: The rapid development, free local storage database, made for
> LiveCode developers: livecloud.io 
> >
> >
> >
> >
> >
> > ___
> > 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: LC8 lineOffset

[Charles Warwick]

I can't see a sample stack in the bug report (unless I'm reading it wrong). 
There are some additional attachments but it looks like the actual sample stack 
was emailed direct to LC.


--
Sent from my iPhone

On 15 Oct 2015 at 10:59:30 AEST, Peter Haworth  wrote:

> I'd have to recreate the issue since I'm not using the workaround I just
> posted.  But Mark posted several stacks that illustrate the problem to the
> bug report.
> Pete
> 
> Pete
> lcSQL Software 
> Home of lcStackBrowser  and
> SQLiteAdmin 
> 
> On Wed, Oct 14, 2015 at 5:30 PM, Charles Warwick <
> char...@techstrategies.com.au> wrote:
> 
> >
> > Do either of you have a sample stack you can send me that exhibits this
> > problem?
> >
> > I went to look at this a while back, but couldn't replicate it and there
> > wasn't a sample stack in the bug report for me to try.
> >
> >
> > --
> > Sent from my iPhone
> >
> > On 15 Oct 2015 at 09:28:18 AEST, Mark Talluto 
> > wrote:
> >
> > > > On Oct 14, 2015, at 4:05 PM, Peter Haworth  wrote:
> > > >
> > > > Has anyone run into problems using lineOffset in LC8?  I'm seeing it
> > return
> > > > an incorrect line number in some cases.
> > > >
> > > > I'm wondering if it could have something to do with the data I'm
> > searching,
> > > > since some lines have the characters \n embedded in them
> > > >
> > >
> > >
> > > It may be related to bug:
> > http://quality.runrev.com/show_bug.cgi?id=15512 <
> > http://quality.runrev.com/show_bug.cgi?id=15512>
> > >
> > >
> > > Best regards,
> > >
> > > Mark Talluto
> > > canelasoftware.com 
> > > CassiaDB: The rapid development, free local storage database, made for
> > LiveCode developers: livecloud.io 
> > >
> > >
> > >
> > >
> > >
> > > ___
> > > use-livecode mailing list
> > > use-livecode@lists.runrev.com
> > > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> >
> > ___
> > use-livecode mailing list
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

LC8 lineOffset

[Peter Haworth]

Has anyone run into problems using lineOffset in LC8?  I'm seeing it return
an incorrect line number in some cases.

I'm wondering if it could have something to do with the data I'm searching,
since some lines have the characters \n embedded in them

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: Forcing string comparisons, or When is "0" not 0?

[Dr. Hawkins]

On Wed, Oct 14, 2015 at 2:10 PM, Devin Asay  wrote:

> I'll have to explain to them that “LiveCode tries its hardest to make
> something into a number if there is any chance at all that it could be a
> number, so we have to do an extra check to make sure it’s not this specific
> type of numeric expression that happens to end with a dot.”


Now if you can find a way to coerce logicals to number with intrinsics,
I'll be *real* interested . . .


-- 
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: Forcing string comparisons, or When is "0" not 0?

[Randy Hengst]

Rather than write the IF statement with AND NOT I’ve just written separate IF 
statements… first, check the field for the “.” first… then in a separate “if” 
statement check the rest of your math… that seems pretty easy for a novice to 
understand. It also provided a way to show that when the if statement wasn’t 
met, nothing happened… 

I’d even write it like this:

  if char -1 of field "display" = "." then 
  delete char -1 of field "display"
   else
  -- do nothing
   end if



be well,
randy

Randy Hengst
www.classroomFocusedSoftware.com


> On Oct 14, 2015, at 4:10 PM, Devin Asay  wrote:
> 
> 
>> On Oct 14, 2015, at 2:39 PM, Paul Dupuis  wrote:
>> 
>> if fld "Display" contains "." then
>> 
>> of if you're just concerned with it ending with "."
>> 
>> if fld "Display ends with ".” then
> 
> Yeah, that works, but then I end up with a mess like this:
> 
>  if fld “display” = 0 AND NOT fld “display” ends with “.” then … 
> 
> But this may be what I have to go with. That’s at least *sort of* 
> comprehensible to a newbie.
> 
> I'll have to explain to them that “LiveCode tries its hardest to make 
> something into a number if there is any chance at all that it could be a 
> number, so we have to do an extra check to make sure it’s not this specific 
> type of numeric expression that happens to end with a dot.”
> :-/
> 
> Devin
> 
> Devin Asay
> Office of Digital Humanities
> Brigham Young University
> 
> ___
> 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: LC8 lineOffset

[Mark Talluto]

> On Oct 14, 2015, at 4:05 PM, Peter Haworth  wrote:
> 
> Has anyone run into problems using lineOffset in LC8?  I'm seeing it return
> an incorrect line number in some cases.
> 
> I'm wondering if it could have something to do with the data I'm searching,
> since some lines have the characters \n embedded in them
> 


It may be related to bug:  http://quality.runrev.com/show_bug.cgi?id=15512 



Best regards,

Mark Talluto
canelasoftware.com 
CassiaDB: The rapid development, free local storage database, made for LiveCode 
developers: livecloud.io 





___
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: LC8 lineOffset

[Charles Warwick]

Do either of you have a sample stack you can send me that exhibits this problem?

I went to look at this a while back, but couldn't replicate it and there wasn't 
a sample stack in the bug report for me to try.


--
Sent from my iPhone

On 15 Oct 2015 at 09:28:18 AEST, Mark Talluto  wrote:

> > On Oct 14, 2015, at 4:05 PM, Peter Haworth  wrote:
> > 
> > Has anyone run into problems using lineOffset in LC8?  I'm seeing it return
> > an incorrect line number in some cases.
> > 
> > I'm wondering if it could have something to do with the data I'm searching,
> > since some lines have the characters \n embedded in them
> > 
> 
> 
> It may be related to bug:  http://quality.runrev.com/show_bug.cgi?id=15512 
> 
> 
> 
> Best regards,
> 
> Mark Talluto
> canelasoftware.com 
> CassiaDB: The rapid development, free local storage database, made for 
> LiveCode developers: livecloud.io 
> 
> 
> 
> 
> 
> ___
> 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: LC8 lineOffset

[Peter Haworth]

Thanks Mark, I think it's the same bug, except on OSX.  I'm using the
linestoskip parameter of lineOffset as you were.  I'm using lineOffset in a
loop to return lines between a start and end line number.  I've worked
around the problem by deleting the lines after I've finished using them, so
the start line number is always 1.  For some reason it manages to get the
correct offset for the end line number that way.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 

On Wed, Oct 14, 2015 at 4:28 PM, Mark Talluto 
wrote:

> > On Oct 14, 2015, at 4:05 PM, Peter Haworth  wrote:
> >
> > Has anyone run into problems using lineOffset in LC8?  I'm seeing it
> return
> > an incorrect line number in some cases.
> >
> > I'm wondering if it could have something to do with the data I'm
> searching,
> > since some lines have the characters \n embedded in them
> >
>
>
> It may be related to bug:  http://quality.runrev.com/show_bug.cgi?id=15512
> 
>
>
> Best regards,
>
> Mark Talluto
> canelasoftware.com 
> CassiaDB: The rapid development, free local storage database, made for
> LiveCode developers: livecloud.io 
>
>
>
>
>
> ___
> 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: scaleFactor strangeness

[Dr. Hawkins]

On Tue, Oct 13, 2015 at 3:38 PM, Richard Gaskin 
wrote:

> Can we have the scalingFactor available for the contents of groups?
> 
>

That's probably the biggest single thing I cold wish for right now.  I'd
even call it a critical need . . .

I have scaling sort of working.  Not quite as well from drag-resizing, but
I have cmd-plus & -minus doing resizing--but I haven't been able to figure
out the math, so it does on walkabout as I hit these.

As far as retrofitting to the older language, as someone (Richard?)
mentioned, it could be done by

  set the groupTop of field myField to 100

and so forth.

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

From any button script, how can I reset the scrollbar of a field to the "top" ?

[Francis Nugent Dixon]

Hi from Beautiful Brittany,

This is a beginners question (except that I am not a beginner)
I've tried everything I know to do this, but all the commands
I tried came up with an error. Sounds stupid, don't it ?

Is there a soul to help me out ?

-Francis

___
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: From any button script, how can I reset the scrollbar of a field to the "top" ?

[David Williams]

Hi Francis,

The scrolled amount of a field is defined by the vscroll (vertical) and  
hscroll (horizontal) properties, so to set the scrollbar back to the top,  
do this:


set the vscroll of field "myField" to 0

-David

On Wed, 14 Oct 2015 13:43:37 +0100, Francis Nugent Dixon  
 wrote:



Hi from Beautiful Brittany,

This is a beginners question (except that I am not a beginner)
I've tried everything I know to do this, but all the commands
I tried came up with an error. Sounds stupid, don't it ?

Is there a soul to help me out ?

-Francis

___
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



--
Using Opera's mail client: http://www.opera.com/mail/

___
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

[Geoff Canyon]

On Thu, Oct 8, 2015 at 5:20 PM, Richard Gaskin 
wrote:

> Ken Ray and I discussed having one of the theoretical collapsible headers
> being Favorites, so anyone who finds themselves using a certain subset of
> props frequently can include them there while still keeping the logical
> groupings it would ship with by default.


I hadn't been paying attention to this thread, but then Mark and Richard
mentioned me, so here I am.

My latest update to Navigator (which I haven't officially updated for some
time) does two things:

1. It collects recently-accessed properties at the top of the list.
2. It lets the developer specify a list of properties to always show at the
top of the list.

Both of the above are determined individually by object type. That said,
Navigator doesn't support custom interfaces for any property types other
than booleans, which you can click to set/unset, and 2- and 4-item lists,
which it allows you to just type in and hit return to set.

Further, I haven't even begun to look at widgets, but if they're
implemented as a group of underlying objects, then Navigator doesn't (yet)
handle that intelligently at all.

*That* said, the above frequently-used-properties item took a couple hours
to implement and wasn't difficult.

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

[Geoff Canyon]

On Thu, Oct 8, 2015 at 9:07 PM, Peter Haworth  wrote:

> The properties array of an object does not include properties which can be
> derived from other properties.  That change was made a few releases back
> and no method of invoking the prior behavior (perhaps "the effective
> properties") was provided.
>
> Also, the propertynames list is missing some entries and includes some
> entries that seem more like keywords than properties, e.g. "abbrev".
>

This is why I implemented a preference for properties-to-add-to-the-list in
Navigator. That way it doesn't matter if the propertynames doesn't include
the blork property -- I can add it to the list before releasing a new
version of Navigator, or if I miss something, a developer can add it
themselves.
___
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

[Geoff Canyon]

On Tue, Oct 13, 2015 at 3:16 AM, Mark Waddingham  wrote:

>
> Tools can be entirely self-contained and fully interchangeable, even
>> open at the same time, using nothing more than what the engine has
>> provided for years.
>>
>
> Really? Are you sure that is true?
>
> So you would have every 'application browser' type tool implement its own
> code for monitoring for changes in the user stacks, and for collecting all
> the data about the objects in user stacks?
>
> You would have every 'tools palette' type tool implement its own code to
> go digging around on disk for all extensions, listing, enumerating and
> providing an ability to create them?
>

No. The IDE already provides messages that things have changed, and all
Navigator has to do is get its name on the list of message receivers. After
that Navigator just responds to the update requests it receives. It doesn't
have its own code for monitoring changes, and it is self-contained as
Richard says.
___
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

[Richard Gaskin]

J. Landman Gay wrote:
> It's likely you've never had interference issues with Navigator
> because users wouldn't be using more than one property inspector
> simultaneously. But my Zygodact system did interfere with the GLX
> framework and I had to rewrite it to accommodate GLX. It wasn't how
> I wanted things to work, but enough people were using GLX at the
> time that it was necessary. Fixing the problem required communication
> between me and the author.
>
> The conflict occurred because of different approaches when handling
> preferences files. Standardization would have avoided the issue.

It would be interesting to learn more about the details of that 
conflict, informative for both the IDE team and skunkworks projects alike.


It may be a question of scope, since as you noted that GLX isn't a 
discrete tool but a framework.  Ideally even frameworks should coexist, 
at least when of different types, since things like GLX are for apps and 
an IDE's being for the tools run alongside the app during development.


This is one reason why, although I'm aware of the difference between a 
plugin and a framework (I've been making both for decades), I don't 
often distinguish them in discussions of the opportunities and 
challenges of either:  the underlying issues with regard to components 
playing nice together are similar, varying mostly in scope but not so 
much in their nature.


Indeed. the more I think about your specific circumstance the more I 
realize that what you're describing reinforces my point that dependence 
on presumptions of a single monolithic framework can sometimes introduce 
as many issues as they seek to address:


Even if there were one single modular framework for IDE tools, what 
occurred in your circumstance is quite different, a conflict between 
*application* frameworks which each assume themselves to be the only 
such thing in play.


We hope that the LC world would have many app frameworks over time, just 
as one expects to find for any popular language like JavaScript or Python.


And like frameworks in other languages, they're not always mix-and-match.

Standardizing some core elements like prefs handling may be useful for 
all app framework developers to discuss and explore solutions for (Andre 
once proposed a stdLib for LiveCode for exactly that reason), but 
anything app frameworks do would be independent of any IDE frameworks 
used alongside them.


There are many ways to resolve such conflicts, one of them being lengthy 
discussions of all possible circumstances and an expensive effort to 
craft a single one-size-fits-all solution to accommodate every app 
developer's need.


But I find I learn a lot just watching how things organically evolve, as 
they did here:  a conflict was discovered, a script change affordably 
implemented, and both toolkits now live happily together with minimal 
effort.


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

[Richmond]

On 14/10/15 11:14, Mark Waddingham wrote:




However, LC8 will be better than LC7, and subsequent LC versions will 
be better still. The more people who get involved to help us reach the 
goal of a lightweight IDE Framework, the more quickly it will happen 
and the better it will be.





That sounds a bit dogmatic.

I can imagine some people not being entirely convinced about certain 
aspects of LiveCode 8: for instance, they might

feel that things have suddenly become rather unnecessarily over-complicated.

-

I don't really understand all that stuff about IDEs and frameworks but I 
do understand why birds have wings and people don't:


Genetically there is not that much different between birds and people; 
what there is in common is what we might choose
to call (at the risk of offending all sorts of people) "God's Universal 
LEGO kit", or the Basic DNA set.


If one were clever enough one could have women giving birth to babies 
with wings by making sure that while those babies
were developing in the womb the switches for wings were turned on, and 
the switches for arms and fingers were turned off.


The fact that I have red hair and white skin, and that my best friend 
has black hair and dark brown skin is a simple illustration

of this principle.

NOW:  I can imagine a stack that resides in the plug-ins folder of a 
LiveCode installation [lets' call it stack "X"]
that, when the end-user starts up LiveCode sets all sorts of "switches" 
to suppress parts of RunRev's IDE and

activate equivalent-but-different parts developed by someone else.

In fact I made a very crude stack that bungs a button on the revMenuBar 
stack and turns both the revMenuBar and the revTools
stacks black about a week ago: this could be regarded as an indication 
of the direction in which IDE hacks should be moving:
AND, before you rush to thank me, don't, as that was not my clever idea 
- I just implemented somebody else's clever idea.


I did understand that bit about different parts of the IDE chatting to 
each other, and any set of switches
would have to take that into account. A baby with wings but no sternum 
to anchor them to would die as

soon as it tried to stretch its wings.

Richmond.

___
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

[Geoff Canyon]

On Wed, Oct 14, 2015 at 4:14 AM, Mark Waddingham  wrote:

> On 2015-10-13 17:35, Richard Gaskin wrote:
>
>>



> I see no harm in encouraging people to just continue doing what
>> they've been enjoying for decades:  making tools to help their work
>> and sharing them with others.
>>
>
> Indeed - there is no harm at all - it is actually quite important. I
> wasn't implying that it shouldn't be encouraged...
>
> All of the tools I've referred to - Mark Weider's, Bjornke's, Geoff's,
>> Peter's, and others' - exist.  Why not have more?  Why not have a
>> convenient launcher for them?
>>
>
> Great - how do you ensure that Mark's tools don't interfere with Geoff's
> so users can use them side-by-side?
>
> If every toolmaker has to take into account every other toolmaker's 'way
> of doing things' you end up with a situation where one individual who wants
> to write a tool needs to learn about everybody else's if they want to
> distribute it for the benefit of all.


I've never found this to be the case. I have never had someone report a bug
to me because some other tool interfered with Navigator, or because
Navigator tripped up someone else's tool.


> Indeed - advocacy and implementation are two entirely separate things
> though - which is perhaps why no such widespread 'lightweight IDE system'
> has appeared (to my knowledge at least).
>
> And there is one salient aspect: neither of us is describing an IDE
>> that exists today.
>>
>
> I cannot agree there. You may be describing an IDE which does not exist
> today - some sort of mystical entity which will just appear naturally out
> of a lot of people playing around in a sandpit. Unfortunately, I don't have
> much confidence in chaos producing anything in any particularly useful
> timeframe (the mathematician in me screams that the numbers just don't add
> up in that regard).
>

I think Navigator is useful. I've used it in place of everything except the
script editor and the dictionary for over ten years.

Let a thousand flowers bloom.
>>
>
> Indeed - a thousand flowers blooming can be a truly breathtaking sight.
>
> However, it is much less amazing if those thousand flowers are dotted
> around the world individually, not being able to be brought together
> because they cannot co-exist within the same climate, or in the same soil.


Again, unless I'm misunderstanding you, this isn't accurate -- Navigator
happily co-exists with every tool I know.
___
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-14 15:37, Geoff Canyon wrote:

Further, I haven't even begun to look at widgets, but if they're
implemented as a group of underlying objects, then Navigator doesn't 
(yet)

handle that intelligently at all.


They aren't groups of underlying objects - they are black-boxes like the 
engine controls. Indeed, they are a mechanism for (essentially) writing 
engine controls incredibly easily and accessibly (relative to doing so 
in C++, at least) and they plug into LiveCode Script just like all the 
existing ones.


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

Export snapshot and native controls

[Ludovic THEBAULT]

Hello,

Livecode 6.77

When i create a snapshot with this script :

export snapshot from rectangle theRect of this cd to file…

I’ve the correct snapshot but all natives controls are gone !

And if i use this script :

export snapshot from rectangle theRect to file…

I’ve only the natives controls on a black background…

Any ideas ?

Thanks



___
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