Re: widget properties

2018-02-24 Thread Mark Wieder via use-livecode

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


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


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


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


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

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

--
 Mark Wieder
 ahsoftw...@gmail.com

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


Re: widget properties

2018-02-24 Thread Richard Gaskin via use-livecode

hh wrote:

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

That is true of all objects of all properties.


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

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



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


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


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


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


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

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


Re: widget properties

2018-02-24 Thread Richard Gaskin via use-livecode

Ali Lloyd wrote:

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

So it seems, hence my question. :)


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

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


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


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


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


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


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




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

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


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

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


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

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

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


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



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


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



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

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


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

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


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


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


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

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


Re: widget properties

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

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


> The VCS-related use case for an expanded properties property still exists
> though, as far as I can tell, although 'properties' is kind of a bad name
> for it. Actually I think it might be better to add 'export' syntax for
> classic controls. The nice thing about the export syntax is that you get
> exactly the distinct pieces of information required to reconstruct the
> widget (according to the widget author's implementation). It might actually
> be a completely distinct representation of the widget state than that
> provided by a list of properties and their values (although in practice,
> it's usually a subset of the properties).
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: widget properties

2018-02-24 Thread hh via use-livecode
> Richard G. wrote:
> What's missing is support for the universal method by which we can 
> obtain property info, "the properties" function.

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

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

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

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

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

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


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


Re: widget properties

2018-02-24 Thread Ali Lloyd via use-livecode
Not much has changed since this question was last asked:
http://lists.runrev.com/pipermail/use-livecode/2015-October/219630.html

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

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

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



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

> hh wrote:
>
>  >> Richard G. wrote:
>  >> I'm suggesting the engine have an enhancement to add
>  >> the widget-specific info to the  universally-supported
>  >> "the properties" info.
>  >
>  > It would be possible to simply add all the info that the property
>  > inspector can display. But that can also easily be scripted by the
>  > user of the widget.
>  > Or use the demo-stacks of the widget's author (I usually provide
>  > these) which contain (parts of) setter and getter scripts.
>
> Exactly.  There are many workarounds available.
>
> What's missing is support for the universal method by which we can
> obtain property info, "the properties" function.
>
> Given that the engine is apparently already able to obtain that info,
> adding it to the universal mechanism for this should seem short work, no?
>
> --
>   Richard Gaskin
>   Fourth World Systems
>   Software Design and Development for the Desktop, Mobile, and the Web
>   
>   ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: widget properties

2018-02-24 Thread Richard Gaskin via use-livecode

hh wrote:

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

Exactly.  There are many workarounds available.

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


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


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

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


Re: widget properties

2018-02-24 Thread hh via use-livecode
> Richard G. wrote:
> I'm suggesting the engine have an enhancement to add the widget-specific info
> to the  universally-supported "the properties" info.

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

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

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

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


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

Re: Password Checker

2018-02-24 Thread J. Landman Gay via use-livecode

I just got around to trying this -- *very* useful, thanks for posting it.

There are no matches for any of my passwords I've tried so far. :) On 
the other hand, even "AbrahamLincoln" has 128 matches. And you have to 
insert commas to read the number returned for "qwerty".


On 2/22/18 10:50 PM, Brian Milby via use-livecode wrote:

Read this interesting article about a half billion PW database of
compromised passwords that I thought I'd share:

*https://www.troyhunt.com/ive-just-launched-pwned-passwords-version-2/
*

*on* mouseUp
*local* tSHAData, tSHAHex, tList
*put* messageDigest(the text of field "password", "SHA-1") into tSHAData
*repeat* for each byte tByte in tSHAData
   *put* format("%02X",bytetonum(tByte)) after tSHAHex
*end* *repeat*
*put* url ("https://api.pwnedpasswords.com/range/; & char 1 to 5 of
tSHAHex) into tList
*delete* char 1 to 3 of tList *-- delete the BOM*
*filter* tList with (char 6 to -1 of tSHAHex) & "*"
*set* the itemdel to ":"
*put* item 2 of tList into field "hits"
*end* mouseUp

I've written some code that uses the new v2 API.  You send the first 5
characters of the SHA1 of your password and get a list back of matches.
You can then see if the rest of the hash is in the list and get the number
of times it appears on the list.  "123123" appears 2048411 times for
example.

I'm sure that someone can tighten it up some, but just wanted to make
something in LiveCode that could use the API.

You can also download the full database of SHA1 values (8.75GB) if you
would want to use to provide a service.  Links are in the article (he
prefers that you use a torrent).

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




--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

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


Re: another mac to Windows gotcha

2018-02-24 Thread panagiotis merakos via use-livecode
Hi Tim,

I am not sure if the DirectShow player (with is the API used by the LC
player on Windows) supports negative playrate:

https://msdn.microsoft.com/en-us/library/windows/desktop/dd377591(v=vs.85).aspx

There is also a bug report about it:

http://quality.livecode.com/show_bug.cgi?id=19129

Best,
Panos
-- 

On Sat, Feb 24, 2018 at 3:32 PM, Tim Selander via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hi Peter,
>
> Tried
> if pkeyname is "j" then
> set the playrate of player videoplayer to -1
> start player videplayer
> end if
>
> Results in a pause in playback as long as I am holding ctrl-j, as soon as
> that's released, forward play resumes.
>
> Thanks.
>
> Tim
>
>
>
> On 2018.02.25 0:26, Peter Bogdanoff via use-livecode wrote:
>
>> Tim,
>>
>> Try both commands in order: set playRate, then start.
>>
>> Peter Bogdanoff
>>
>> On Feb 24, 2018, at 10:16 AM, Tim Selander via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
>>>
>>> Hi Paul,
>>>
>>> Using 9.0 dp11 community. After sending the post, I found in the
>>> dictionary that for windows, commandkeydown message. After changing my
>>> script from controlkeydown to commandkeydown, it worked. Sort of.
>>>
>>> My next problem is that on the LC/osx I use:
>>>   if pkeyname is "j" then set the playrate of player videoplayer to -1
>>>   if pkeyname is "k" then set the playrate of player videoplayer to 0
>>>   if pkeyname is "l" then set the playrate of player videoplayer to 1
>>>
>>> to start, stop or reverse the player from the keyboard. This worked
>>> great in LC/osx, but is not working in win7/LC.
>>>
>>> I changed the lines to
>>>   if pkeyname is "k" then stop player videoplayer
>>>   if pkeyname is "l" then start player videoplayer
>>>
>>> and that works in win7/lc. But can't figure out how to send a play in
>>> reverse command from the keyboard yet.
>>>
>>> Tim Selander
>>> Tokyo, Japan
>>>
>>>
>>> On 2018.02.24 23:44, Paul Dupuis via use-livecode wrote:
 controlKeyDown is absolutely available on Windows. See the dictionary
 entry in LC8.1.9 for example. What version of LiveCode are you using?


 On 2/24/2018 9:04 AM, Tim Selander via use-livecode wrote:
> Hi,
>
> Trying my first little LC app on Windows. I wrote an app on osx and am
> now trying to get it to work in a Win7 machine.
>
> On the mac app, I use ctrl-J, ctrl-K, and ctrl-L to control the video
> player. JKL is pretty standard video player control in video editing
> software.
>
> On the mac app, the card script 'listens' for controlkeydown, and if
> the other key is J K or L, sends the appropriate go, stop, reverse
> command to the player.
>
> Have just discovered controlkeydown is not available on windows. Is
> there an equivalent? What would the windows guy and gals here use?
>
> Thanks,
>
> Tim Selander
> Tokyo, Japan
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>

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


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


Re: widget properties

2018-02-24 Thread Richard Gaskin via use-livecode

Brian Milby wrote:

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

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


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

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


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


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


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


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

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


Re: widget properties

2018-02-24 Thread Brian Milby via use-livecode
Now I’m really confused:

put the properties of widget id 1004 into tA

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

> > Brian M. wrote:
>> > One other thing that could be done is to extend the export to include
>> > everything that the engine knows about the widget (i.e. add the
>> > properties array to it).
>>
>> The widget author can already do that by defining a list of persistent
>> properties. Why should the engine override that?
>
>
> I see this as a unification rather than override.  When a stack is saved
> it asks each widget what it wants to save but also includes other
> properties too (rect, layer, id, ...).
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: widget properties

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


I see this as a unification rather than override.  When a stack is saved it
asks each widget what it wants to save but also includes other properties
too (rect, layer, id, ...).
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Navigator Update

2018-02-24 Thread Geoff Canyon via use-livecode
Navigator has been updated to include:

 -- Filtering in the Stack List (both using the filter field, and the more
robust filter command).
 -- A fix for an issue where editing properties could show the editor in
HTMLtext mode, meaning that properties would be set incorrectly.
 -- A new Save All command when right-clicking on stacks, which saves the
stack itself and all the stackfile files referenced by the stack. NOTE:
this will not save any stackfiles referenced in substacks of a mainstack.
Should it?
 -- A new command Open in New Navigator when right-clicking on any set of
containers: groups, cards, or stacks -- which will open all of the
containers, each in their own copy of Navigator.
 -- I've also started work preparing to reduce the number of global
variables Navigator uses. If you check, you'll see that Navigator uses
global variables prefixed gSB, which stands for "Script Buddy," which was
Navigator's name when it was first started out *way* back when. Those
globals are going down, someday...

You can get Navigator here
. Or get it
from GitHub: Navigator's GitHub page 
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: widget properties

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

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

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

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

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


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


Re: widget properties

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

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

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

Re: widget properties

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

> When we query the properties of any object, we get an array that lets us
> understand and even reproduce that object easily.
>
> Except with widgets.
>
> When we query the properties of a widget we get only the subset of
> properties common to all widgets, but none of the properties unique to
> any given widget type.
>
> Should the widget spec be enhanced to map its unique properties to be
> included among "the properties" array?
>
> --
>   Richard Gaskin
>   Fourth World Systems
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


widget properties

2018-02-24 Thread Richard Gaskin via use-livecode
When we query the properties of any object, we get an array that lets us 
understand and even reproduce that object easily.


Except with widgets.

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


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


--
 Richard Gaskin
 Fourth World Systems

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


Re: another mac to Windows gotcha

2018-02-24 Thread Tim Selander via use-livecode

Hi Peter,

Tried
if pkeyname is "j" then
set the playrate of player videoplayer to -1
start player videplayer
end if

Results in a pause in playback as long as I am holding ctrl-j, as 
soon as that's released, forward play resumes.


Thanks.

Tim


On 2018.02.25 0:26, Peter Bogdanoff via use-livecode wrote:

Tim,

Try both commands in order: set playRate, then start.

Peter Bogdanoff


On Feb 24, 2018, at 10:16 AM, Tim Selander via use-livecode 
 wrote:

Hi Paul,

Using 9.0 dp11 community. After sending the post, I found in the dictionary 
that for windows, commandkeydown message. After changing my script from 
controlkeydown to commandkeydown, it worked. Sort of.

My next problem is that on the LC/osx I use:
  if pkeyname is "j" then set the playrate of player videoplayer to -1
  if pkeyname is "k" then set the playrate of player videoplayer to 0
  if pkeyname is "l" then set the playrate of player videoplayer to 1

to start, stop or reverse the player from the keyboard. This worked great in 
LC/osx, but is not working in win7/LC.

I changed the lines to
  if pkeyname is "k" then stop player videoplayer
  if pkeyname is "l" then start player videoplayer

and that works in win7/lc. But can't figure out how to send a play in reverse 
command from the keyboard yet.

Tim Selander
Tokyo, Japan



On 2018.02.24 23:44, Paul Dupuis via use-livecode wrote:
controlKeyDown is absolutely available on Windows. See the dictionary
entry in LC8.1.9 for example. What version of LiveCode are you using?



On 2/24/2018 9:04 AM, Tim Selander via use-livecode wrote:
Hi,

Trying my first little LC app on Windows. I wrote an app on osx and am
now trying to get it to work in a Win7 machine.

On the mac app, I use ctrl-J, ctrl-K, and ctrl-L to control the video
player. JKL is pretty standard video player control in video editing
software.

On the mac app, the card script 'listens' for controlkeydown, and if
the other key is J K or L, sends the appropriate go, stop, reverse
command to the player.

Have just discovered controlkeydown is not available on windows. Is
there an equivalent? What would the windows guy and gals here use?

Thanks,

Tim Selander
Tokyo, Japan

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




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



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


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



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


Re: another mac to Windows gotcha

2018-02-24 Thread Peter Bogdanoff via use-livecode
Tim,

Try both commands in order: set playRate, then start.

Peter Bogdanoff

> On Feb 24, 2018, at 10:16 AM, Tim Selander via use-livecode 
>  wrote:
> 
> Hi Paul,
> 
> Using 9.0 dp11 community. After sending the post, I found in the dictionary 
> that for windows, commandkeydown message. After changing my script from 
> controlkeydown to commandkeydown, it worked. Sort of.
> 
> My next problem is that on the LC/osx I use:
>  if pkeyname is "j" then set the playrate of player videoplayer to -1
>  if pkeyname is "k" then set the playrate of player videoplayer to 0
>  if pkeyname is "l" then set the playrate of player videoplayer to 1
> 
> to start, stop or reverse the player from the keyboard. This worked great in 
> LC/osx, but is not working in win7/LC.
> 
> I changed the lines to
>  if pkeyname is "k" then stop player videoplayer
>  if pkeyname is "l" then start player videoplayer
> 
> and that works in win7/lc. But can't figure out how to send a play in reverse 
> command from the keyboard yet.
> 
> Tim Selander
> Tokyo, Japan
> 
> 
>> On 2018.02.24 23:44, Paul Dupuis via use-livecode wrote:
>> controlKeyDown is absolutely available on Windows. See the dictionary
>> entry in LC8.1.9 for example. What version of LiveCode are you using?
>> 
>> 
>>> On 2/24/2018 9:04 AM, Tim Selander via use-livecode wrote:
>>> Hi,
>>> 
>>> Trying my first little LC app on Windows. I wrote an app on osx and am
>>> now trying to get it to work in a Win7 machine.
>>> 
>>> On the mac app, I use ctrl-J, ctrl-K, and ctrl-L to control the video
>>> player. JKL is pretty standard video player control in video editing
>>> software.
>>> 
>>> On the mac app, the card script 'listens' for controlkeydown, and if
>>> the other key is J K or L, sends the appropriate go, stop, reverse
>>> command to the player.
>>> 
>>> Have just discovered controlkeydown is not available on windows. Is
>>> there an equivalent? What would the windows guy and gals here use?
>>> 
>>> Thanks,
>>> 
>>> Tim Selander
>>> Tokyo, Japan
>>> 
>>> ___
>>> 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: another mac to Windows gotcha

2018-02-24 Thread Tim Selander via use-livecode

Hi Paul,

Using 9.0 dp11 community. After sending the post, I found in the 
dictionary that for windows, commandkeydown message. After 
changing my script from controlkeydown to commandkeydown, it 
worked. Sort of.


My next problem is that on the LC/osx I use:
  if pkeyname is "j" then set the playrate of player videoplayer 
to -1
  if pkeyname is "k" then set the playrate of player videoplayer 
to 0
  if pkeyname is "l" then set the playrate of player videoplayer 
to 1


to start, stop or reverse the player from the keyboard. This 
worked great in LC/osx, but is not working in win7/LC.


I changed the lines to
  if pkeyname is "k" then stop player videoplayer
  if pkeyname is "l" then start player videoplayer

and that works in win7/lc. But can't figure out how to send a 
play in reverse command from the keyboard yet.


Tim Selander
Tokyo, Japan


On 2018.02.24 23:44, Paul Dupuis via use-livecode wrote:

controlKeyDown is absolutely available on Windows. See the dictionary
entry in LC8.1.9 for example. What version of LiveCode are you using?


On 2/24/2018 9:04 AM, Tim Selander via use-livecode wrote:

Hi,

Trying my first little LC app on Windows. I wrote an app on osx and am
now trying to get it to work in a Win7 machine.

On the mac app, I use ctrl-J, ctrl-K, and ctrl-L to control the video
player. JKL is pretty standard video player control in video editing
software.

On the mac app, the card script 'listens' for controlkeydown, and if
the other key is J K or L, sends the appropriate go, stop, reverse
command to the player.

Have just discovered controlkeydown is not available on windows. Is
there an equivalent? What would the windows guy and gals here use?

Thanks,

Tim Selander
Tokyo, Japan

___
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: another mac to Windows gotcha

2018-02-24 Thread Paul Dupuis via use-livecode
controlKeyDown is absolutely available on Windows. See the dictionary
entry in LC8.1.9 for example. What version of LiveCode are you using?


On 2/24/2018 9:04 AM, Tim Selander via use-livecode wrote:
> Hi,
>
> Trying my first little LC app on Windows. I wrote an app on osx and am
> now trying to get it to work in a Win7 machine.
>
> On the mac app, I use ctrl-J, ctrl-K, and ctrl-L to control the video
> player. JKL is pretty standard video player control in video editing
> software.
>
> On the mac app, the card script 'listens' for controlkeydown, and if
> the other key is J K or L, sends the appropriate go, stop, reverse
> command to the player.
>
> Have just discovered controlkeydown is not available on windows. Is
> there an equivalent? What would the windows guy and gals here use?
>
> Thanks,
>
> Tim Selander
> Tokyo, Japan
>
> ___
> 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


another mac to Windows gotcha

2018-02-24 Thread Tim Selander via use-livecode

Hi,

Trying my first little LC app on Windows. I wrote an app on osx 
and am now trying to get it to work in a Win7 machine.


On the mac app, I use ctrl-J, ctrl-K, and ctrl-L to control the 
video player. JKL is pretty standard video player control in 
video editing software.


On the mac app, the card script 'listens' for controlkeydown, and 
if the other key is J K or L, sends the appropriate go, stop, 
reverse command to the player.


Have just discovered controlkeydown is not available on windows. 
Is there an equivalent? What would the windows guy and gals here use?


Thanks,

Tim Selander
Tokyo, Japan

___
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: playing a video in Win7?

2018-02-24 Thread Klaus major-k via use-livecode
Hi Tim,

> Am 24.02.2018 um 14:06 schrieb Tim Selander via use-livecode 
> :
> 
> Hi,
> 
> Trying to simply play an h264 video on LC 9 in a player on a Win7 machine. 
> Quicktime installed.
> I have .mov, .mp4, .mv4 videos that all play fine on Mac osx /and/ in QT on 
> the Win7 machine.
> But I can only get .wmv to play in the LC player object on Win7.
> Have to create a little in-house app for a Win7 user...  Very first time to 
> use LC on Windows.
> Any hints? Much appreciated.

if possible, install these filter (plug-ins for WMP) on the target machine, 
which will 
let you play MP4 and a lot more formats in a player object on Windows:


> Tim Selander
> Tokyo, Japan

Best

Klaus

--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
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


playing a video in Win7?

2018-02-24 Thread Tim Selander via use-livecode

Hi,

Trying to simply play an h264 video on LC 9 in a player on a Win7 
machine. Quicktime installed. I have .mov, .mp4, .mv4 videos that 
all play fine on Mac osx /and/ in QT on the Win7 machine. But I 
can only get .wmv to play in the LC player object on Win7.


Have to create a little in-house app for a Win7 user...  Very 
first time to use LC on Windows.


Any hints?

Much appreciated.

Tim Selander
Tokyo, Japan


___
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