Re: Groups in the message path: Trapping Mouseup

[Paul Dupuis via use-livecode]

So if I have a button X with a mouseDown handler in a Group Y also with 
a mouseDown handler and in my card script (or stack script) also have a 
mouseDown handler


If I click on button X and I only want button X to handle the mouseDown, 
I do not 'pass mouseDown' in the button X mouseDown handler


If I click on button X and I also want another mouseDown handler in the 
message path - in addition to the one in button X - to do something in 
response, then I need to 'pass mouseDown' in the button script. In this 
example, a pass mouseDown in the button mouseDown handler passes the 
message to the group that contains the button. If that group's mouseDown 
handler also does a pass mouseDown, then the card or stack gets the 
mouseDown as well. If they do not pass the message its stops there.


Richard Gaskin, at one point, had a really excellent diagram of the 
LiveCode message hierarchy. If he sees this post and still has it 
perhaps he could post a link to it.



On 12/10/2019 2:39 PM, Sannyasin Brahmanathaswami via use-livecode wrote:

So then to trap "the target" in the stack script, require putting
   pass mousedown (or mouseWhatever)
in all the background groups (all of which contain their our MouseDown)

Correct?

remember the use case:
we do not want and script in *any* button or top object that receives a click or touch.  
The card becomes a pure "view" object.

@paul

If you have groups where you need to pass a mouseDown (or mosueWhatever)
mesage to the card or stack, just add a behavior to the group for a
script that contain handlers like

on mouseDown
   pass mouseDown
end mouseDown

on mouseUp
   pass mouseUp
end mouseUp

Although if there is no handler for the mouse event it should pass to
the card and then the stack and then any library or backscripts and then
the engine.

___
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: Groups in the message path: Trapping Mouseup

[Paul Dupuis via use-livecode]

I use groups in use cases where I want a on mouseDown script in the 
group to respond to any mouse click anywhere in the rect of the group, 
so, no, groups should not ONLY respond to mouse messages passed though 
object contained in the group



If you have groups where you need to pass a mouseDown (or mosueWhatever) 
mesage to the card or stack, just add a behavior to the group for a 
script that contain handlers like


on mouseDown
  pass mouseDown
end mouseDown

on mouseUp
  pass mouseUp
end mouseUp

Although if there is no handler for the mouse event it should pass to 
the card and then the stack and then any library or backscripts and then 
the engine.


 On 12/9/2019 9:30 AM, Sannyasin Brahmanathaswami via use-livecode wrote:

In this use case,

- the button "starWidget"  is a "standalone" button on an independent layer on 
the card  and not a part of any group
-- @Jacque... the groups that are trapping the mouseup I are background groups 
using on various card.
  
Mark Weider says "A background group will definitely get the message before the stack

script does. Also any script being used as a behavior."

BR: is this "really" expected behavior? gosh, I hope not! "Encapsulation"would 
mean

-- background groups: "encapsulated" only receive mouse/touch events from objects that 
are contain in "itself" --  group
-- behaviors: "encapsulated": only receive mouse events for the object or group 
the behavior is assigned to.

Isn't this a bug?  Otherwise, "We have chaos on the Highway 666, total car wreck on 
the Message Path"

___
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: Script Editor disassociates - a lossy LC IDE bug

[Paul Dupuis via use-livecode]

Windows 10 for me


On 12/5/2019 8:11 PM, Tom Glod via use-livecode wrote:

Are you all on Mac?  This does not ring a bell.

On Thu, Dec 5, 2019 at 8:02 PM Paul Dupuis via use-livecode <
use-livecode@lists.runrev.com> wrote:


On 12/5/2019 6:38 PM, Bob Sneidar via use-livecode wrote:

On Dec 5, 2019, at 15:04 , Paul Dupuis via use-livecode <

use-livecode@lists.runrev.com> wrote:

On 12/5/2019 5:42 PM, Curry Kenworthy via use-livecode wrote:

Wondering if this bug has already been reported?

I've seen a wonderful LC 9 IDE bug: sometimes the Script Editor window

seems to disassociate from the object being edited. Thus after this bug is
triggered, any typed script changes may not really be applied and saved,
although they are shown as applied. Next LC session, those changes are
gone; the stack code is still as it was prior to the bug being triggered
and prior to editing the script.

An alternate form is that the script changes actually are applied, but

in a bad way: first the script disassociates completely and is empty, then
the empty script is saved, overwriting the previous script. Nice! (I think
this is my favorite variation; if we're going to cause loss of work/code,
might as well do it boldly and not beat around the bush.)

I suspect this happens more on Mac than Windows, but since I don't

have a recipe, not sure. I've seen this happen to other people rather than
on my own machine. On LC 905 for sure, and probably on 950 also.

If Script Editor disassociation does happen, I advise immediate but

careful no-save quit or force quit, and pray that you're already in the
habit of backing up beforehand. Copy and paste the current script text to
an external text editor if necessary. Of course this particular bug just
might be able to defeat the safety of stack backups too in some situations,
but hey, that's why it's an extra-fabulous bug!

So, in addition to being a bit crashy and glitchy, the 9 IDE is a bit

work-lossy. That could turn off both new and old users if they are the
humor-deficient type to frown on losing some work. But shucks, ain't no
thang! Only features features features (and new side projects) matter! Glad
we all agree on that.

Any reports or recipes on this issue? I'll post a report if there is

none. Thanks

I saw a similar error in earlier versions of LC9 where the script I was

editing was for a different object that what was indicate the Project
Browser. So the Project Browser was showing (highlighting) Object A but
actually thought it was on Object B.

It occurred fairly intermittently. I never developed a recipe and I

have not see this in the most recent releases (9.0.5 and 9.5.1)

Ditto. Hasn't happened for a while though.

Bob S



Of course, I am not saying that the bug isn't still in the current
releases, just that I have not noticed it in the current releases ;-)


___
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: Script Editor disassociates - a lossy LC IDE bug

[Paul Dupuis via use-livecode]

On 12/5/2019 6:38 PM, Bob Sneidar via use-livecode wrote:



On Dec 5, 2019, at 15:04 , Paul Dupuis via use-livecode 
 wrote:

On 12/5/2019 5:42 PM, Curry Kenworthy via use-livecode wrote:

Wondering if this bug has already been reported?

I've seen a wonderful LC 9 IDE bug: sometimes the Script Editor window seems to 
disassociate from the object being edited. Thus after this bug is triggered, 
any typed script changes may not really be applied and saved, although they are 
shown as applied. Next LC session, those changes are gone; the stack code is 
still as it was prior to the bug being triggered and prior to editing the 
script.

An alternate form is that the script changes actually are applied, but in a bad 
way: first the script disassociates completely and is empty, then the empty 
script is saved, overwriting the previous script. Nice! (I think this is my 
favorite variation; if we're going to cause loss of work/code, might as well do 
it boldly and not beat around the bush.)

I suspect this happens more on Mac than Windows, but since I don't have a 
recipe, not sure. I've seen this happen to other people rather than on my own 
machine. On LC 905 for sure, and probably on 950 also.

If Script Editor disassociation does happen, I advise immediate but careful 
no-save quit or force quit, and pray that you're already in the habit of 
backing up beforehand. Copy and paste the current script text to an external 
text editor if necessary. Of course this particular bug just might be able to 
defeat the safety of stack backups too in some situations, but hey, that's why 
it's an extra-fabulous bug!

So, in addition to being a bit crashy and glitchy, the 9 IDE is a bit 
work-lossy. That could turn off both new and old users if they are the 
humor-deficient type to frown on losing some work. But shucks, ain't no thang! 
Only features features features (and new side projects) matter! Glad we all 
agree on that.

Any reports or recipes on this issue? I'll post a report if there is none. 
Thanks


I saw a similar error in earlier versions of LC9 where the script I was editing 
was for a different object that what was indicate the Project Browser. So the 
Project Browser was showing (highlighting) Object A but actually thought it was 
on Object B.

It occurred fairly intermittently. I never developed a recipe and I have not 
see this in the most recent releases (9.0.5 and 9.5.1)


Ditto. Hasn't happened for a while though.

Bob S




Of course, I am not saying that the bug isn't still in the current 
releases, just that I have not noticed it in the current releases ;-)



___
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: Script Editor disassociates - a lossy LC IDE bug

[Paul Dupuis via use-livecode]

On 12/5/2019 5:42 PM, Curry Kenworthy via use-livecode wrote:


Wondering if this bug has already been reported?

I've seen a wonderful LC 9 IDE bug: sometimes the Script Editor window 
seems to disassociate from the object being edited. Thus after this 
bug is triggered, any typed script changes may not really be applied 
and saved, although they are shown as applied. Next LC session, those 
changes are gone; the stack code is still as it was prior to the bug 
being triggered and prior to editing the script.


An alternate form is that the script changes actually are applied, but 
in a bad way: first the script disassociates completely and is empty, 
then the empty script is saved, overwriting the previous script. Nice! 
(I think this is my favorite variation; if we're going to cause loss 
of work/code, might as well do it boldly and not beat around the bush.)


I suspect this happens more on Mac than Windows, but since I don't 
have a recipe, not sure. I've seen this happen to other people rather 
than on my own machine. On LC 905 for sure, and probably on 950 also.


If Script Editor disassociation does happen, I advise immediate but 
careful no-save quit or force quit, and pray that you're already in 
the habit of backing up beforehand. Copy and paste the current script 
text to an external text editor if necessary. Of course this 
particular bug just might be able to defeat the safety of stack 
backups too in some situations, but hey, that's why it's an 
extra-fabulous bug!


So, in addition to being a bit crashy and glitchy, the 9 IDE is a bit 
work-lossy. That could turn off both new and old users if they are the 
humor-deficient type to frown on losing some work. But shucks, ain't 
no thang! Only features features features (and new side projects) 
matter! Glad we all agree on that.


Any reports or recipes on this issue? I'll post a report if there is 
none. Thanks




I saw a similar error in earlier versions of LC9 where the script I was 
editing was for a different object that what was indicate the Project 
Browser. So the Project Browser was showing (highlighting) Object A but 
actually thought it was on Object B.


It occurred fairly intermittently. I never developed a recipe and I have 
not see this in the most recent releases (9.0.5 and 9.5.1)


___
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: Achilles Heel of Livecode

[Paul Dupuis via use-livecode]

I really am too old-fashion.

I see "apps" that have fancy animated effects and spin pretty GIFs while 
doing some task to let me know that the task is being done


... and all I can think is: If they dropped ALL the cute animation crap 
and spent the CPU cycles on doing the task I wanted done, it would get 
done in HALF the time!


I should probably go back to using a command line interface.



___
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: Adding `the caller` to LiveCode Script

[Paul Dupuis via use-livecode]

I'd like to see the 'the caller' added as well.

Mind you, I'd like to see a *lot* more of the player object bugs fixed 
and more of the LCS statements that are still not Unicode aware made 
Unicode aware first, but the "the caller" would probably 3rd on my list. 
Digging through the executionContexts is a pain even when possible and 
there are lots of places in my code where being able to fidn the caller 
would be helpful.



On 11/26/2019 10:59 AM, Trevor DeVore via use-livecode wrote:

About 15 years ago Dar Scott added a feature request to have a function
that returns the long ID of the caller's caller's object:

https://quality.livecode.com/show_bug.cgi?id=1954

Two years ago LiveCode Builder added `the caller` which does just that, but
only in LCB. If anyone is looking for a contribution to make to the engine
I am throwing this out there as something to consider: Add `the caller` to
LCS.

Why is this useful?

When writing handlers that send callback messages it is sometimes desirable
to send the message to the object that called the handler. For example,
let's say I have a library that makes REST calls to a server API. This
calls are asynchronous so a handler in the library will need to notify the
caller that the request is finished. If a handler from the library was
called  from a card then I might want the callback to be sent to the card.
If a handler was called from a group then I might want the callback to be
sent to the group.

The current solution is to pass the long id of the object you want the
callback sent to as a parameter to the library handlers. For example:

restAPIGetObjects tId, the long id of me # callback will sent to me

If you aren't using password protected stacks then you can use `the
executioncontexts` to get the information you need to determine the caller.
But when a stack is password protected the necessary information isn't
included in `the executioncontexts`.

I have a recent real world example. I rewrote the REST API interface in an
application I work on to use behaviors that I attach to cards in my UI
stacks. The design allows me to segment REST calls made within a specific
object (card or group) so that callbacks and cleanup are very simple to
manage. The need to pass the long id of the caller as a parameter if I want
the callback for a specific handler to be sent to a group on the card
shouldn't be part of a handlers parameter list, however.




___
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: Identifying Un-used functions and commands

[Paul Dupuis via use-livecode]

revRefactor has a very nice "orphan Code..." feature

https://github.com/mwieder/revRefactor/tree/master/Plugin


On 11/25/2019 1:08 PM, J. Landman Gay via use-livecode wrote:
I think he wants it the other way around, identifying handlers and 
functions that aren't called by any other handler. I've done this, but 
only one at a time, by searching for the handler name across all open 
stacks. If the only occurrence is the handler itself ("on/function 
whatever", ) then it's unused.


The method here would probably be to get a list of all handlers and 
functions and then do a global search for instances of each. If 
there's one or more that isn't the handler declaration, it's used.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On November 25, 2019 11:51:14 AM dunbarx--- via use-livecode 
 wrote:



Hi.
This was posted a couple of weeks ago, no?
I suggested then that you could write a short handler that loops 
through all the scripts in all the controls on all the cards, and 
isolate words that are not preceded by either "command", "on" or 
"function". In this way you might see, for example, that "myGadget3" 
may be present in scripts here and there, but there is no "on 
myGadget3" anywhere. Then you will have found an unused handler call.

This may require tweaking. For example, LC will compile, say:
"on myGadget3"  -- spaces galore

Craig

-Original Message-
From: Bob Sneidar via use-livecode 
To: How to use LiveCode 
Cc: Bob Sneidar 
Sent: Mon, Nov 25, 2019 12:29 pm
Subject: Re: Identifying Un-used functions and commands

Since there is code in the script editor that knows the location of 
any command or function you right click on, if you found out how they 
do that, you would be well on your way to developing a way to grok 
it. Also, GLX2 has a "clairvoyance" (Auto-Complete) function that is 
handler aware. I suspect Mark Wieder developed a method for getting a 
list of all handlers in a stack that is opened. That would probably 
help too.


Bob S


On Nov 12, 2019, at 09:12 , Stephen MacLean via use-livecode 
 wrote:



Hi All,


I’m wondering if anyone has a way or code to identify any un-used 
functions and commands in a set of stacks?



Best,
Steve MacLean


___
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

AVF and DirectShow and access to media tracks and raw data

[Paul Dupuis via use-livecode]

The evolution of LiveCode from Quicktime (OSX/Win) to AVF (OSX) and 
DirectShow (Win), while necessary, lost some potentially useful features.


Under Quicktime you have several player properties to see what "tracks" 
the player file has and to turn those track on and off.


With the current Player object you have the mediaTypes property, which 
appears to provide the tracks and that's it.


What I am really looking for is library or code to extract the audio 
track from videos? And subsequently to that, get access to the raw audio 
data as a string of bytes.


I am aware of an older LC stack, AudioWaveForm, written i believe by 
Mark Smith, that parsed raw audio data via a live code script for a very 
limited set of audio formats ( I that was just uncompressed AIC or WAV 
audio files)


Has anyone built a library or L9 widget that converts audio to a wave 
form image for display? Or at least lets you get the uncompressed audio 
byte data from a variety of video and audio sources?


Baring that, does any one know of a set fo OS APIs or 3rd party open 
source library that could be wrapped by LC9's FFI interface into a 
widget or library?


___
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: Managing maximized windows on MacOS

[Paul Dupuis via use-livecode]

On 11/20/2019 3:45 AM, Giovanni via use-livecode wrote:

Hi everybody,
as already said the main problem is that there is no way to intercept the 
maximization action and to understand if the window is maximized or not.
screenrects or windowBoundingRect are not useful in this case mainly when the 
maximized window has a maxWidth or maxHeight value lower than the maximum 
width/height of the screenrect.

Moreover due to the bug #21311 (https://quality.livecode.com/show_bug.cgi?id=21311 
) it’s not possible to 
prevent the windows maximization for the resizable stacks.

So, any other hint about this topic?


As this is really an issue mainly on recent versions of macOS where 
maximize goes to full screen and then really on on the primary monitor 
as it covers things like the menu bar, I think a work-around in 
resizeStack is the way to go. in the resizeStack handler see get the 
rect of the stack - this will be the stacks new rect. If the top in the 
space normally reserved for the menu bar. It doesn't have to equal the 
rect of the primary monitor. You just eed to check the top and see if it 
is less than the height of the macOS menubar (I think 44px?  Can't 
remember off the top of my head). If top is less than 44px then the 
stack has been maximized and then you can reset the rect to the 
effective working rect of the primary screen


so something like:

on resizeStack
  lock screen
  if the screen of this stack = 1 then -- this stack is on the primary 
monitor
   if (the effective top of this stack < (item 2 of the screenRect + 
44)) then -- this stack has been maximized as its top is "above" the menubar
    set the effective rect of this stack to the effective working 
screenRect

   end if
  end if
  -- do the rest of resizeStack based on the (now) revised stack rect, 
so don't use the height or width passed as params, but get the height, 
width, or rect after this line so you have the revised rect.

  ...
  unlock screen
end resizeStack

I have not tested this - I just wrote it off the top of my head, so 
check to see if it works.


___
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: Y coordinate for a line of text

[Paul Dupuis via use-livecode]

You may want to look at the Dictionary entry for "measureText"


On 11/12/2019 1:43 AM, scott--- via use-livecode wrote:

I’m needing to know the coordinate (Y is the tricky one) for a line of text. 
I’m not do a very good job at calculating it. I think I remember a newish LC 
command or function that achieved this but I can’t locate it in the dictionary. 
Am I imagining?

--
Scott Morrow

Elementary Software
(Now with 20% less chalk dust!)
web   https://elementarysoftware.com/
email sc...@elementarysoftware.com
booth1-800-615-0867

--








___
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

Amazing how forgiving the older LC engines are...

[Paul Dupuis via use-livecode]

I just got bit by how forgiving older LC engines version are.

Migrating a stack from LC6.7.11 to LC9.5.1. There is a handle to perform 
a "select all" on a particular list field where "select all" means 
select all lines but the first. The code was essentially:


  put empty into tLineList
  repeat with i=2 to the number of lines in fld 1
    put i & cr after tLineList
  end repeat
  delete last char of tLineList
  set the hilitedLines of fld 1 to tLineList'

This throws an script execution error under LC9.0.5 or 9.5.1 when trying 
to execute  the last line, but works perfectly well under LC6.7.11 and 
earlier.


The problem, of course, is that the hilitedLines is supposed to be a 
COMMA delimited list, not a CR delimited list. Even the LC6.7.11 
Dictionary states comma delimited. And yet, LC6.7.11 and earlier happily 
allowed and handled correctly wither comma or cr delimited lists for the 
hilitedLines property.


Simple change of Cr to comma fixes the routine for LC9xx

I am not sure in what more recent LC versions this list flexibility went 
away (7? 8? 9?) but I have mixed feelings that it did go away. On one 
hand, I think the versatility of the older engine in forgiving and 
working with bad syntax was amazing. On the other had, had they been 
stricter, I would have discovered this bug long ago.






___
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: [OT] Hmmm...

[Paul Dupuis via use-livecode]

On 11/9/2019 7:03 PM, Richard Gaskin via use-livecode wrote:

Nearly 24 hours since the last post to this list.

Did everyone stop using LiveCode, or is this mailserve down again?

Just checking



I haven't run into any new engine bugs or Catalina issues in a whole 
week! So I have had nothing new to post ;-)



___
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: Indy 9.5.0. Apple can't search for malware in LC Indy?

[Paul Dupuis via use-livecode]

I am sure it is possible. I just don't have the 
PHP/HTML/Javascript/whatever skills to do that.



On 11/5/2019 12:02 PM, Phil Davis via use-livecode wrote:
On this issue, isn't it possible to let a web server detect the OS 
requesting the download? So the server can then do the picking and 
send the right version to the requestor?


Or maybe the info available to the server about the requesting OS 
isn't that detailed. Not sure. At least I'm sure I can use a single 
download link for an app's Mac and Windows installers.


Phil Davis



On 11/5/19 8:33 AM, Paul Dupuis via use-livecode wrote:
I'm not saying YOUR experience is invalid. I guess I am just saying 
we have really really really computer naive customers and Apple has 
gone and complicated things and it creates a support burden for us 
that we would not have had to expend resources addressing if Apple 
had not done this.


Apple has, and there is no going back, so it is what it is, but it is 
really really annoying! :-(




On 11/5/2019 11:23 AM, Bob Sneidar via use-livecode wrote:
But the installers for drivers and the installer you want to use are 
not different. And what else does anyone have to go on but their 
experiences, and other people's experiences? I need to tap into that 
resource! ;-)


Bob S


On Nov 5, 2019, at 08:18 , Paul Dupuis via use-livecode 
 wrote:


On 11/5/2019 10:41 AM, Bob Sneidar via use-livecode wrote:
First, your assumption that "it's one everyone is experiencing for 
any installer" is exactly that, an assumption based on your 
experiences.


The vast majority of our customers are computer novices and 
anything but the simplest of steps can cause them problems. Most do 
not know what version of macOS they run, nor how to tell what 
version they are running.


Second, I was not calling for RunRev to "fix" this. It is clearly 
Apple's inane drive for marketing a level or privacy and security 
that is mostly a gigantic lie that is the cause.


And thirdly, drivers are a bit different than research 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




___
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

Catalina & Mojave "Allow/Deny" dialogs

[Paul Dupuis via use-livecode]

Another "fun" feature of the newer macOS versions is the new Privacy 
(tab in the Security and Privacy pane of the System Preferences).


It seems that running our app generates a number of system dialogs of 
the form "[[OUR APPLICATION]] wants access to " with "OK" and "Don't 
Allow" buttons. Two of these make perfect sense.


1) Is access to the Internet, which appears to appear if and only if the 
Firewall is truned on (default in Mojave is off and in Catalina is on). 
Our app access a server file to see if there is a new version of itself.


2) [[OUR APPLICATION]] wants access to control "Finder.app". Allowing 
control will provide access to documents and data in "Finder.app", and 
to perform actions in that app." with the expected "OK" and "Don't 
Allow". This took me a while to figure out, but apparently it is cause 
by any app that uses AppleEvents. We use AppleEvents to detect if a 
document has been dropped on our app or one of our apps documents has 
been double clicked. We also respond to AppleEvent quit messages to exit 
our application. Seemingly pretty basic desktop applications tasks now 
have a vague warning message associated with them.


NOW HERE IS THE PUZZLER.

When our app is sitting there idle, we just saw one of these that says: 
"[[[OUR APPLICATION]] would like to access your Contacts" with the 
expected "OK" and "Don't Allow". Now, NOTHING in our application has 
anything to do with a person Contacts. So does anyone have ANY idea why 
this would popup?


What LiveCode statements or functions could generate this. Would access 
revMail do it? Our app can ask to send an email under certain 
situations. Does anyone have any experience with these new "Privacy" 
warnings and how best to address them?



___
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: Indy 9.5.0. Apple can't search for malware in LC Indy?

[Paul Dupuis via use-livecode]

I'm not saying YOUR experience is invalid. I guess I am just saying we 
have really really really computer naive customers and Apple has gone 
and complicated things and it creates a support burden for us that we 
would not have had to expend resources addressing if Apple had not done 
this.


Apple has, and there is no going back, so it is what it is, but it is 
really really annoying! :-(




On 11/5/2019 11:23 AM, Bob Sneidar via use-livecode wrote:

But the installers for drivers and the installer you want to use are not 
different. And what else does anyone have to go on but their experiences, and 
other people's experiences? I need to tap into that resource! ;-)

Bob S



On Nov 5, 2019, at 08:18 , Paul Dupuis via use-livecode 
 wrote:

On 11/5/2019 10:41 AM, Bob Sneidar via use-livecode wrote:
First, your assumption that "it's one everyone is experiencing for any 
installer" is exactly that, an assumption based on your experiences.

The vast majority of our customers are computer novices and anything but the 
simplest of steps can cause them problems. Most do not know what version of 
macOS they run, nor how to tell what version they are running.

Second, I was not calling for RunRev to "fix" this. It is clearly Apple's inane 
drive for marketing a level or privacy and security that is mostly a gigantic lie that is 
the cause.

And thirdly, drivers are a bit different than research 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




___
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: Indy 9.5.0. Apple can't search for malware in LC Indy?

[Paul Dupuis via use-livecode]

On 11/5/2019 10:41 AM, Bob Sneidar via use-livecode wrote:
First, your assumption that "it's one everyone is experiencing for any 
installer" is exactly that, an assumption based on your experiences.


The vast majority of our customers are computer novices and anything but 
the simplest of steps can cause them problems. Most do not know what 
version of macOS they run, nor how to tell what version they are running.


Second, I was not calling for RunRev to "fix" this. It is clearly 
Apple's inane drive for marketing a level or privacy and security that 
is mostly a gigantic lie that is the cause.


And thirdly, drivers are a bit different than research apps.



This is not limited to LC. When downloading drivers for MacOS from the Toshiba 
site, guess what you see? One link for drivers prior to a certain version of 
the OS, and another for later versions. It may be an annoyance, but it's one 
everyone is experiencing for any installer. RunRev won't be able to fix this so 
that we have one unified installer.

Bob S



On Nov 5, 2019, at 05:15 , Paul Dupuis via use-livecode 
 wrote:

One annoyance from Catalina and Notarization for me as a developer:

LiveCode 9.x.x supports macOS 10.9 (Mavericks) through 10.15 (Catalina). For 
our app built on LC9.x.x, we support those versions of macOS as well. However, 
a Notarized DMG (one way of addressing Apple's Notarization requirement) will 
only open on Sierra, High Sierra, Mojave, or Catalina (10.12-10.15). For 10.9, 
10.10, and 10.11 a Notarized DMG presents an error and will not open.

So now we have to guide out macOS customers to self-select one of two 
downloadable DMGs - one for earlier versions of macOS and a different one for 
later versions. In our case, we just do a regular signed app and signed DMG for 
10.9 through 10.14 (Mojave) and a notarized DMG (with a signed app) for 10.15 
Catalina

An, yes, no matter how "clear" we think our guidance is, we have people 
download the wrong DMG.


___
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: Indy 9.5.0. Apple can't search for malware in LC Indy?

[Paul Dupuis via use-livecode]

One annoyance from Catalina and Notarization for me as a developer:

LiveCode 9.x.x supports macOS 10.9 (Mavericks) through 10.15 (Catalina). 
For our app built on LC9.x.x, we support those versions of macOS as 
well. However, a Notarized DMG (one way of addressing Apple's 
Notarization requirement) will only open on Sierra, High Sierra, Mojave, 
or Catalina (10.12-10.15). For 10.9, 10.10, and 10.11 a Notarized DMG 
presents an error and will not open.


So now we have to guide out macOS customers to self-select one of two 
downloadable DMGs - one for earlier versions of macOS and a different 
one for later versions. In our case, we just do a regular signed app and 
signed DMG for 10.9 through 10.14 (Mojave) and a notarized DMG (with a 
signed app) for 10.15 Catalina


An, yes, no matter how "clear" we think our guidance is, we have people 
download the wrong DMG.



On 11/5/2019 5:01 AM, Tiemo Hollmann TB via use-livecode wrote:

Hello,

  


I just installed LC Indy 9.5.0. on MacOS 10.15 Catalina

  


I can't start LC Indy. My Mac tells me:

"LiveCode Indy 9.5.0 can't be opened, because Apple can't search for malware
in this app." This software has to be updated.

  


Probably this was already a question on this list, but I couldn't find the
answer, what I have to do.

  


Thank you

  


Tiemo

  

  

  


___
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: Managing maximized windows on MacOS

[Paul Dupuis via use-livecode]

I'd like to know this too. I'd love to see a way to better control 
maximizing a window. the windowBoundingRect is a little out of date.


1) It only applies to the primary monitor (any platform) and I am 
finding a lot more of our customers have multiple monitors these days 
(usually a laptop with a larger desktop monitor). However, with Catalina 
allowing iPads to be extra monitors for a macOS system, we're only 
likely to have more situations where desktop apps need to be multiple 
monitor aware


2) I am not sure it works any more on the latest versions of macOS




On 11/4/2019 1:58 PM, Giovanni via use-livecode wrote:

Hi guys,
from MacOS Mojave and on when you maximize a window (clicking on “+” button on 
windows main bar) the system maximize the window on the entire screen hiding 
all the system bars and moving the window on a different “virtual” space.

Is there a way using LC to manage this window status?
It’s possible to detect the window maximization (I.E. in a message) and manage 
the actions to activate when the window goes to this status or go back to the 
normal status?

Thank you in advance for your tips!

Regards
___
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: drag'n'drop in text fields

[Paul Dupuis via use-livecode]

On 10/29/2019 9:47 AM, Brian Milby via use-livecode wrote:

It looks like selectionChanged only reacts to explicit user events (mouse click 
or cursor moved via keyboard navigation).
I, for one, would consider user-driven pasting of text or user driven 
drag and drop to be 'explicit user events', so I would still consider 
this an engine bug rather than a documentation bug.


___
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: drag'n'drop in text fields

[Paul Dupuis via use-livecode]

On 10/28/2019 5:40 PM, Klaus major-k via use-livecode wrote:

Hi Paul.


Am 28.10.2019 um 22:34 schrieb Paul Dupuis via use-livecode 
:
...

on dragDrop
  if "files" is among the keys of the dragData then
put line 1 of the dragData["files"] -- or whatever
  end if
end dragDrop

on dragEnter
  set the dragAction to "copy"
end dragenter

thank you, also tried that, but then the pathname does not appear in the field.

I want to:
Drag'n'Drop a file into the field -> works without scripting
The pathname appears in the field and is definitively selected!

However "the selectedtext of fld xyz" is reported to be empty
so is "the selection" and "the selectedchunk" returns the insertion point
right BEFORE the file has been dropped -> char 75 to 74 of fld xyz

I want to get that pathname from inside of the field = AFTER the file has been 
dropped.

It sounds like a bug that should be reported. If there is text in a field 
(regardless of how it go there (paste, drag drop, typing, or by script) and it 
is selected, the the selection, selectedChunk,a dn all related properties 
should be set. If the text as placed in a field by any means other than script 
(paste, typing, drag drop) a textChanged message should be sent. I don't think 
textChanged is sent if a script changes the text.

YEAH, TEXTCHANGED is what I should use!
This does what I need:
--
command doit
   put the selectedtext of me
end doit

on textChanged
   send "doit" to me in 10
end textChanged

Thank you very much! :-)

However "selectionchanged" should also be triggered, not?




If there was not a selection in the field and now there is a visible 
selection (as you described) then, yes, a selectionChanged message and, 
to me, more importantly, functions like:


However "the selectedtext of fld xyz" is reported to be empty
so is "the selection" and "the selectedchunk" returns the insertion point
right BEFORE the file has been dropped -> char 75 to 74 of fld xyz

Should reflect the visible selection. If this is not the case, this 
should be reported as a bug - one that I would CC myself on since it 
could impact my 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: drag'n'drop in text fields

[Paul Dupuis via use-livecode]

On 10/28/2019 5:25 PM, Klaus major-k via use-livecode wrote:

Hi Hermann,


Am 28.10.2019 um 22:15 schrieb hh via use-livecode 
:

on dragDrop
  if "files" is among the keys of the dragData then
put line 1 of the dragData["files"] -- or whatever
  end if
end dragDrop

on dragEnter
  set the dragAction to "copy"
end dragenter

thank you, also tried that, but then the pathname does not appear in the field.

I want to:
Drag'n'Drop a file into the field -> works without scripting
The pathname appears in the field and is definitively selected!

However "the selectedtext of fld xyz" is reported to be empty
so is "the selection" and "the selectedchunk" returns the insertion point
right BEFORE the file has been dropped -> char 75 to 74 of fld xyz

I want to get that pathname from inside of the field = AFTER the file has been 
dropped.




It sounds like a bug that should be reported. If there is text in a 
field (regardless of how it go there (paste, drag drop, typing, or by 
script) and it is selected, the the selection, selectedChunk,a dn all 
related properties should be set. If the text as placed in a field by 
any means other than script (paste, typing, drag drop) a textChanged 
message should be sent. I don't think textChanged is sent if a script 
changes the text.



___
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: Weird macOS error dialog

[Paul Dupuis via use-livecode]

On 10/25/2019 8:35 PM, Richard Gaskin via use-livecode wrote:
After installing LC 9.5 on macOS "Catalina", when I run it I get a 
system alert I've never seen before:


 "LiveCode Indy 9.5.0" wants access to
 control "System Events". Allowing control
 will provide access to documents and data
 in "System Events", and to perform actions
 within that app."

What fresh hell is this?  Is this something all of our users will be 
seeing?


I'm guessing (because there's not much in that text for actually 
knowing) that this occurs with some Apple event and/or AppleScript use 
- is that correct?


Anyone know how to never see that weird thing again? (Other than just 
clicking "OK", which users will do but is never a good idea unless 
they fully understand the implications, which I don't believe is 
possible in this case given the vague wording).




I have not seen that one, but I have seen one-time permission dialogs 
for (a) Internet access and (b) writing to the user's "Documents" folder 
for a properly CODE SIGNED 9.0.5 standalone under Catalina.


I assumed it was like iOS permissions and probably LC will need to add 
to the OSX standalone setting tab a list of permissions you have to 
check off for your app, but I have not taken the time to research what 
needs to be done to prevent such warnings.


___
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: Death of eSellerate (48-hour, 50%-off) REBIRTH Sale

[Paul Dupuis via use-livecode]

On 10/23/2019 8:47 AM, Curry Kenworthy via use-livecode wrote:


Due to the untimely, or at least inconvenient, demise of an old 
electronic friend (eSellerate) as a separate entity, I have migrated 
the addon store to its parent company (Digital River) and updated the 
store links on the livecodeaddons.com web site.


To commemorate this occasion and launch the updated store, I've issued 
a REBIRTH coupon for half-price on any/all available addons.


Coupon Code: rebirth (50%)

Web Page: http://livecodeaddons.com/ (click Store)

Store URL: http://curryk.com/addon-store

Curry K. LiveCode Addons - First and best - Instant delivery!

Reginfo is shown on the order confirmation web page AND email, so 
there's no waiting; get started today.


I'll take down the Coupon Code in approx 2 days. The Reg Guide is now 
text, rather than PDF. Happy coding


Best wishes,

Curry Kenworthy

WordLib: Take charge of MS Word and OpenOffice documents
SpreadLib: "Excel-lent" spreadsheet import/export for LC
http://livecodeaddons.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


Nice deal!


___
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

AW: Signing, Notarizing, and Stapling and macOS versions

[Paul Dupuis via use-livecode]

On 10/23/2019 8:49 AM, Paul Dupuis via use-livecode wrote:

LiveCode 9xx is supported on macOS Maveriks (10.9) and up

Catalina (10.15) requires Notarized DMG or App to be allowed to open/run

I have discovered that a Notarized and Stapled DMG works on Catalina 
and Mojave (10.14), but presents an error when trying to open on El 
Capitan (10.11).


Does anyone have a definitive list of macOS versions from 10.9 and up 
by signed - notarized - stapled and what works so I don't have to 
develop one myself? I can not find thi at Apple. 10.12 is min OS to 
"staple" on and 10.13 the min to notarize, but that is form a building 
it, rather than using it.


So far I have: [Signed is "code signed only")
OS    Signed    Notarized    Stapled
10.9    Works    Untested    Fails
10.10
10.11
10.12
10.13
10.14 Works    Works    Works
10.15 Fails    Works    Works

All blanks are untested.


Here are the results for anyone interested:

macOS name    signed notarized stapled
10.9  Mavricks    OK FAIL  FAIL
10.10 Yosemite    OK FAIL  FAIL
10.11 El Capitan  OK     FAIL  FAIL
10.12 Sierra  OK OK    OK
10.13 High Sierra OK OK    OK
10.14 Mojave  OK OK    OK
10.15 Catalina    *  OK    OK

* A signed DMG opens, but any Apps in the DMG present a the notice that 
Apple can't validate the security of the app. A Notarized or Notarized 
and Staples DMG can be opened and any Signed apps (but the Apps 
themselves do not need to be Notarized) can be opened from within the DMG


What this means for anyone distributing macOS apps outside the MacApp 
store is that you probably need to offer 2 different DNG downloads for 
macOS users:
a signed (or even unsigned DMG (with your signed App in it) for 10-9 
through 10.11

and
a signed, notarized, (and optionally stapled), DMG with your code signed 
app in it for 10.12 through 10.15


OR you could do the 1st for 10.9 through 10.14 and just a separate one 
for 10.15.



___
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: RE Video Player LiveCode on Windows

[Paul Dupuis via use-livecode]

I concur with Peter's suggestion.

Using LC9.0.5 RELEASE, I have not seen crashes when editing stacks with 
player objects or changing player properties. LC9.0.5rc1 and LC9.5.0 
RELEASE have bugs that can crash the IDE while debugging.


However, in our two applications that use the player object, the player 
is generally not set to any video (filename is empty) while editing.


-- Paul

On 10/23/2019 12:43 PM, Peter Bogdanoff via use-livecode wrote:

Roland,

You might try setting filename of the player to empty before going to edit mode 
(catching the editScript message). In the past, if a player couldn’t find the 
referenced file it often causes LC to freeze or slow way down, similarly to 
what you’re reporting.

Peter Bogdanoff
ArtsInteractive



On Oct 23, 2019, at 12:28 PM, R.H. via use-livecode 
 wrote:

@ Paul Dupuis

Thank you very much, Paul, for your detailed answer. I removed my other
Codec package and installed the LAV package as recommended by you. It works
well! Great. All the videos I have in MP4, etc. are playing now. This makes
me happy.

But the other biggest problem:

My IDE starts hanging (Windows 64, Version Indy 9.05 and 9.5) when working
with the player and being in edit mode, mainly using the script editor.
This happens all the time. There is no exact recipe. After some time, I
already notice LC is slowing down (it takes long time for anything to
happen) , and soon after that all freezes, and then I have to force-quit
and restart all over again.

As long as the user mode is on and as long as the player is just playing,
it seems to be ok . Except, of course, there is a huge bug list that you
mentioned.

If anybody else has experienced hanging/freezing LiveCode using the player
in edit mode, I would then create a but report because I could not find a
similar report there. Unfortunately, there is no very clear recipe yet.

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

Signing, Notarizing, and Stapling and macOS versions

[Paul Dupuis via use-livecode]

LiveCode 9xx is supported on macOS Maveriks (10.9) and up

Catalina (10.15) requires Notarized DMG or App to be allowed to open/run

I have discovered that a Notarized and Stapled DMG works on Catalina and 
Mojave (10.14), but presents an error when trying to open on El Capitan 
(10.11).


Does anyone have a definitive list of macOS versions from 10.9 and up by 
signed - notarized - stapled and what works so I don't have to develop 
one myself? I can not find thi at Apple. 10.12 is min OS to "staple" on 
and 10.13 the min to notarize, but that is form a building it, rather 
than using it.


So far I have: [Signed is "code signed only")
OS    Signed    Notarized    Stapled
10.9    Works    Untested    Fails
10.10
10.11
10.12
10.13
10.14 Works    Works    Works
10.15 Fails    Works    Works

All blanks are untested.


___
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: Video-Player LiveCode on Windows

[Paul Dupuis via use-livecode]

LC9 uses DirectShow which Microsoft ships with a very limited number of 
formats it supports.


We recommend people install LAV Filters - a free set of additional codec 
for DirectShow that provides a format range comparable to Apple AVF


https://github.com/Nevcairiel/LAVFilters/releases/download/0.74.1/LAVFilters-0.74.1-Installer.exe

Don't let the 0.74.1 version number scare you, there are really very good.

Also be aware that there are a bunch of player object bugs:

See 
https://quality.livecode.com/buglist.cgi?query_format=advanced_id=92758_desc=player_status=UNCONFIRMED_status=PENDING_status=PENDING_AWAITING_FOLLOW_UP_status=EXPERT_REVIEW_status=CONFIRMED_status=CONFIRMED_NOT_REPRODUCED_status=IN_PROGRESS_status=IN_PROGRESS_AWAITING_FOLLOW_UP_status=AWAITING_MERGE_status=AWAITING_TEST_status=AWAITING_RELEASE_status=HIBERNATED_status=REOPENED_desc_type=allwordssubstr




On 10/21/2019 5:22 PM, R.H. via use-livecode wrote:

I am using Windows 10, 64bit, latest update. I am using an Indy license.
I am working with LC v9.5.0 Build 15503.

Until Christmas I need to develop a small application for music performers
and highly controlled playing of video and audio. I am not too experienced
with LC's video/audio player capabilities. So i tested.

Since I am almost exclusively using the MP4 format, I tried to display
videos that work on all other players (Windows Media Player, VLC, Movies &
TV, any HTML player), in LC they do not play. Everwhere else, they do.

The provided sample video of the player "C:/Program Files/RunRev/LiveCode
Indy 9.5/Resources/Sample.mpg" works. But it is an .mpg file. If nothing
else works, I have to convert all videos to MPEG?

OK. I installed a separat codec on my Windows system. MP4 partially started
to work. But most of the time, it does not. Only sound is played, but no
video. But even with installed codec that support all kinds of video and
audio formats, the LC player does not play .akp or .webm files.

In my application it is essential to loop through segments of the video
multiple times. The "loop" function cannot be used here as it can not be
defined to loop a specified number of times through a segment defined by
start-time and stop-time and be user controlled. I just tried a repeat loop
that calls the player repeatedly. First, it did not work. But then the
solution: The player first must have stopped and must have sent a stop
message that can be retrieved from the handler "on playstopped" to start
playing again. I am setting a global gVideoEnded. Then starting another
play segment loop is possible with a "wait with messages" command waiting
for the global flag set to be true. The solution worked with some small MP4
files.

But bigger video files (also smaller ones) seem to create problems. For the
first time, the video may (or may not) play, but then it may completely
stop and not play again. No other video then can be played. Even reloading
the same video file will not work then.

Often, at this point, the LC IDE stops working and I have to force-quit and
restart.

Also, from a huge number of local MT4 videos, only a small part will show
video while the sound usually plays.

To me it appears that either this new version of LC is not working with
this player on Windows the way it should, or it is a general bug with the
player, or something is wrong with me.

I am just asking if anybody experienced problems playing MP4 videos on
Windows. I am really interested to know. If it the current player is too
buggy then I have to use a Javascript player or play with ffmeg (very nice
utility). I cannot spend days or weeks trying to find out what is going
wrong. Any experiences playing video in the browser widget?

Any other experiences with playing .webm or .akp video files?

If others here have same or similar problems and there is no bug report, I
will post a bug report. I could not find recent bugs for the player object
on Windows describing this problem.

Roland
___
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: Effective rect of stacks on Windows 10

[Paul Dupuis via use-livecode]

On 10/21/2019 4:41 PM, Richard Gaskin via use-livecode wrote:

Paul Dupuis wrote:

> When the 'effective rect' of a stack was introduced to provide the
> outer boundaries of a stack, along with the effective working
> screenRects(s), I rewrote all my complicated windows management code
> (and some of your clever tricks for Windows weirdness, Richard), to
> use simple elegant code that worked awesomely on all OSX versions and
> every Windows version until I tried it under Windows 10 and ...
>
> Not one of my happier days :-(

But at least it's a simpler workaround these day.

In the olden days the border width of a window in Windows was 
user-settable, so the only way to get that (and a few other relevant 
settings) was to obtain metrics from the Windows registry.


With Win10, if I read Mark Waddingham's comment correctly, the border 
can only be 1px, so all those old registry calls can safely go away 
with just simple hard-wired arithmetic.


 True. I just wrote a Win10 specific fix like the one Panos posted in 
the bug. Still I look forward to the day I can remove that and not have 
call a hrEffectiveRect function that returns 'the effective rect' for 
every OS except Windows 10 where it does some subtraction and then 
returns a 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: Effective rect of stacks on Windows 10

[Paul Dupuis via use-livecode]

Thank your Richard and Trevor.

When the 'effective rect' of a stack was introduced to provide the outer 
boundaries of a stack, along with the effective working screenRects(s), 
I rewrote all my complicated windows management code (and some of your 
clever tricks for Windows weirdness, Richard), to use simple elegant 
code that worked awesomely on all OSX versions and every Windows version 
until I tried it under Windows 10 and ...


Not one of my happier days :-(


___
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: Effective rect of stacks on Windows 10

[Paul Dupuis via use-livecode]

On 10/21/2019 2:11 PM, Trevor DeVore via use-livecode wrote:

I am looking for input from people who are using `the effective rect of
stack` and the values it reports on Windows. I have some code that uses the
effective rect of a group to determine if the stack is still on the screen
after the user moves the stack or when restoring window positions when an
app relaunches.

On Windows 10 I just noticed that `the effective rect of stack` includes
the drop shadow that appears along the left, bottom, and right of a window
on Windows 10. For my use case including the shadows in the `effective rect
of stack` serves no value. I'm wondering if someone has a use case where it
is helpful to have the drop shadow included in `the effective rect`?

Here is how you can check behavior if you are interested:

EXPECTED RESULT: The effective rect of a stack on Windows would return the
rect of the stack that includes stack borders and title bar.

OBSERVED RESULT: The effective rect includes the drop shadow of the window
in the rect.

RECIPE:
1. Create a new stack
2. Set the topleft of the stack to 0,0
3. `put the effective rect of this stack`. The left of the rect will be a
negative value.
4. `set the effective topleft of this stack to 0,0`. The left of the stack
will be offset by the negative value from (3).


Add your name to this bug: 
https://quality.livecode.com/show_bug.cgi?id=16305


Mark Waddigham chimed in at one point that the Windows API returns the 
8px border width under Windows 10 - the 1px visible border and a 7px 
"touch area" is apparently how Microsoft views it, so LC's position is 
that this is sort of an OS vendor issue rather than their.


I disagree of course.



___
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: mnemonic working on Windows in LC 9?

[Paul Dupuis via use-livecode]

On 10/21/2019 10:49 AM, Trevor DeVore via use-livecode wrote:

Does using the mnemonic key to display a menu on Windows work for anybody
else in LC 9? I just did the following test and all I hear is a beep:

1. Launch LC 9 on Windows 10.
2. Press the ALT key. The letter represented by the mnemonic setting of
each menu in the Toolbar is underlined.
3. Press the letter of one of the menus (e.g. "F"). All I hear is a beep
when the File menu should appear.

LC905 stable under WIndows 10 - same here. Pressing ALT shows the 
underlines menu letters in the menubar, but nothing but a beep.


Please let me know the bug number when you file one, as I'd like to 
follow it.


___
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: Set font dynamically to fit text

[Paul Dupuis via use-livecode]

On 10/12/2019 8:20 PM, Sannyasin Brahmanathaswami via use-livecode wrote:

Assuming one is not putting whole pages into small fields, does any one have an 
efficient run time LC algorithm that will set the font size so that the 
formatted text will all appear in the field without needing to scroll?

BR

Satchiai Iru - Be a Witness
___
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



your essentially want a repeat loop where you reduce the textSize of 
char 1 to -1 of the field until the formattedHeight of the field is less 
than or equal to the height of the field


You probably will need a condition in the loop to prevent the textSize 
from going below 9


___
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

launch & quit

[Paul Dupuis via use-livecode]

I have a stand alone with a card with a button with a mouseUp handler

on mouseUp

  -- some stuff

  -- tApplication variable contains a path to another standalone for 
OSX or Window depending upon what platform() this standalon is running on


  launch tApplication
  put the result into tError
  if tError is not empty then
    answer error tErrormEssage
  end if
  quit
end mouseUp

On Windows, the designated application launches promptly and my app 
quits immediately.


On OSX, the designated application launches promptly and my app waits 
way too long (a minute or two) before quitting.


Standalone built for OSX and Windows on Windows under LC905

Anyone have any experience like this? Any ideas on what to do to get the 
OSX version to quit when told to quit?


___
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: Catalina

[Paul Dupuis via use-livecode]

On 10/9/2019 12:29 PM, J. Landman Gay via use-livecode wrote:
It may be too late for you, but last week I got an email from the 
company that makes my accounting software warning customers not to 
upgrade to Catalina. They said they've been working on the transition 
for a year and thought they'd finish in time but it didn't work out. 
They were quite up-front about it, said they were working hard and 
would let us know when it was ready.

Hah! We clearly use the SAME accounting software!

___
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: Catalina

[Paul Dupuis via use-livecode]

On 10/9/2019 12:02 PM, Bob Sneidar via use-livecode wrote:

It's a good point. If any commercial developers using LC (or ANY dev 
environment) are going to have issues with Catalina, it might be a good idea to 
mail blast them and warn them if your app is not going to be compatible, and 
even provide a general time frame for when they will be.


Yes, we unfortunately, already had to do that. And I hated having to 
send it out. We just could not quite make the timing. We have about a 
handful of bugs left to fix and QA and then we'll have our new release. 
I really regret not being done by Catalina, but we tried hard.


We, ourselves, use a popular Accounting software package that runs on 
OSX, who also email blasted us warning they were not quite 64 bit yet.


___
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: Catalina

[Paul Dupuis via use-livecode]

Customer (at least ours) do not understand 32 bit vs 64-bit. They will 
only know that (a) Apple says there is a new update for their computer 
and they click to update; or (b) as a member of some university or 
business, their computer is upgraded (perhaps at their request, perhaps 
as part of a planned upgrade cycle).


In either case, after they or some IT person has helped with the OS 
update, suddenly some of their software (including ours) no longer works 
(being 32-bit). They don't know why. They don't care why.


Now as for the "Well, Apple has been notifying you forever that, as a 
developer, you needed to be at 64 bits" or "But if you make your apps in 
LiveCode, just recompile with LiveCode 9"


Our apps have hundreds of thousands of line of code. In migrating them 
to LiveCode 9, at first they would not even run. In the course of 
migrating, Researchware staff has filed some 40 Livecode 9 bugs, some of 
which have no or no good workarounds, that directly impact features of 
our apps. Thankfully, most have work-arounds, but work-arounds and 
testing take time. Now for the record, LiveCode, Ltd. has been 
absolutely great in suggesting work-arounds or helping us work through 
the most serious of the bugs.


Our customers do not need 64 bits. Our very niche software does what it 
needs to do in 32 bits. Our customer have no disk space issues or memory 
issues due to both 32 and 64 bits libraries or support. Our customers 
would all be very happy to just keep using our tools as is. Hence, my 
venting is about Apple's intentionally planned obsolescence. What our 
customers want in new versions is not 64 bit, but functional 
enhancements to what our software does.


Being a small (very small), we have sunk a year of development in to 
getting to LC9 for 64 bit and making sure what we have in our app just 
works (QA testing!). We have had no resources to work on new or enhanced 
features. So our customers get an upgrade, with almost nothing new 
except 64 bit support, which also means with nothing new, we can't in 
good conscious charge an upgrade fee for it. Which means lost revenue, 
which badly hurts our small business.


Should we have migrated to LC9 sooner? Probably, but doing so would have 
meant - as it does now - only doing the migration and not new 
features/revenue. Also doing in now, we still found 40 bugs. If we did 
it a year or two ago, how many more bugs would we have found that have 
since been fixed!


That's what Catalina represents to us. I realize that many many Apple 
customers will be delighted with Catalina and I am happy for them. I 
just wish that Apple cared a bit more about not breaking what came 
before. Say what you will about Microsoft, but I still have specialty 
applications written for Windows 2000/XP that run fine under Windows 10! 
Microsoft is guilty of many many sins, but **for the most part** they 
try to keep things that once once worked still working.


___
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: Catalina

[Paul Dupuis via use-livecode]

Agree!

With all the billions of $$$ Apple has, they certainly could have 
afforded to maintain 32-bit compatibility for smaller developers who 
can't afford to make every change Apple demands, but they make more 
profits if they don't.


Sorry to any Apple fanatics. I just needed to vent my frustration at 
Apple's dictatorial development model.


On 10/8/2019 9:52 PM, hh via use-livecode wrote:

"Catalina is a girl's name of Spanish origin meaning 'pure'".
What a beautiful sounding name!

But MacOS Catalina is a pure killer. Killed my beloved LC 6/7
(I need for development of Raspi stacks) and sometimes need
for speed.

I learned LiveCode using LC 6 in 2013.
TMHO, LC 6.7.11 was the most complete LC version ever made.

May be I'll use one older machine only for using LC 6/7.
But it's kind of a burial.   :-((


___
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: Give a bug a hug

[Paul Dupuis via use-livecode]

On 10/8/2019 12:42 PM, Richard Gaskin via use-livecode wrote:

Pi Digital wrote:

> Forgive me for saying but, except the bounty idea, wasn’t this the
> whole point of it going open source - so that the community would
> fix bugs themselves!

Personally, I try to avoid making claims about other people's internal 
motivations.  Since I'm not them, such information is unknowable to 
me. I find it better to focus instead on what can be observed.


Researchware (me) backed LiveCode's open source effort not because I 
ever expected to fix any bugs myself. I viewed the investment as 
corporate insurance. Both of our two commercial applications are 
developed in LiveCode. IF (and I hope it NEVER happens), something 
happened to LiveCode AND it went out of business AND no one else picked 
up support for the language, I wanted access to the LC source to be able 
to continue to develop our apps under LC rather than be forced to try to 
port them to some other language.


Richard is right. People likely sponsored the open source effort for a 
wide variety of reasons.


___
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: Always negative

[Paul Dupuis via use-livecode]

I am not sure why LC doesn't just play a DONATE (via paypal or 
something) button on either the https://livecode.org/ page or the 
https://livecode.org/contribute/ page


It's kind of hidden, but in the footer of 
https://www.joomla.org/contribute-to-joomla.html there is a link to 
donate (https://community.joomla.org/sponsorship-campaigns.html)


Ubuntu has https://ubuntu.com/download/desktop/thank-you

Not every open source effort has a monetary contributions link, but many 
do - especially those without big corporate sponsors


If they had that link, especially if you could add a comment to your 
donation, people could donate and identify areas they'd like to see 
improvements on whether features or bug fixes.



___
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: publish and surprise

[Paul Dupuis via use-livecode]

I would love to see a publish and subscribe system in the engine for use 
in Standalone.


I've written a LCS library for for publish and subscribe within our 
commercial apps, but would toss it in an instant for a good engine 
implementation.


Beyond abstracted commands like:
revIDESubscribe "helloworld" -> subscribe 
ideMessageSendWithParameters "helloworld" -> publish  with 
, which could just be existing "send" or "dispatch"


You need a general suppress messages/unsuppress messages, which we have 
as "lock messages" and "unlock messages" already in the language.


You also need an "unsubscribe " and a "lock  
messages [for ]" / "unlock  messages [for 
]" to allow suppression/unsuppression of a specific message for 
all objects or for specific object.


We already have "the pendingMessages" and "cancel", but you would also 
want to add "the subscribers [of ]" for a list of long IDs 
of objects and their messages or filtered for a specific message 
subscribed to and "the publishers [of ]" for a similar list 
of object IDs when the messages they publish or filtered for a specific 
message.


Or perhaps I have been thinking too much about this!


On 10/2/2019 8:58 AM, Tom Glod via use-livecode wrote:

thats what i'm thiking about..its only documented in the "create a plugin"
sections.  But having this in standalones would be a bit of news.

So every message the engine sends is checked to see if there is a
subscription to that message and then all objects ( whether in the path or
not. ) that are subscribed would receive a message that this message was
triggered. That is pretty cool!

On Wed, Oct 2, 2019 at 8:53 AM Paul Dupuis via use-livecode <
use-livecode@lists.runrev.com> wrote:


On 10/1/2019 11:52 PM, Mark Wieder via use-livecode wrote:

I have finally gotten around to noticing that LC9.x builds have opened
the publish-and-subscribe mechanism to arbitrary messages. I'm not
sure when this happened and I'm really not inclined to go searching
through all those release notes, but I'm ecstatic over the surprise
discovery. This means objects can register interest in certain
messages to do something like

object1:
revIDESubscribe "helloworld"

object2:
revIDESubscribe "helloworld"

object3:
ideMessageSendWithParameters "helloworld"

and both object1 and object2 will get notifications, fully
implementing the Publish-and-Subscribe design pattern.

Thank you team.


Have you tested this is a standalone?

I thought (probably incorrectly) that revIDE... functions/commands were
only available when running in the IDE?


___
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: publish and surprise

[Paul Dupuis via use-livecode]

On 10/1/2019 11:52 PM, Mark Wieder via use-livecode wrote:
I have finally gotten around to noticing that LC9.x builds have opened 
the publish-and-subscribe mechanism to arbitrary messages. I'm not 
sure when this happened and I'm really not inclined to go searching 
through all those release notes, but I'm ecstatic over the surprise 
discovery. This means objects can register interest in certain 
messages to do something like


object1:
revIDESubscribe "helloworld"

object2:
revIDESubscribe "helloworld"

object3:
ideMessageSendWithParameters "helloworld"

and both object1 and object2 will get notifications, fully 
implementing the Publish-and-Subscribe design pattern.


Thank you team.



Have you tested this is a standalone?

I thought (probably incorrectly) that revIDE... functions/commands were 
only available when running in the IDE?



___
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: Export snapshot and errors...

[Paul Dupuis via use-livecode]

According to the Dictionary, if I am reading it correctly, in a command 
(vs function)


return empty -- sets both 'it' and 'the result' to the parameter of the 
return statement (in this case empty)
return empty for value -- sets 'it' to the parameter (empty) and clears 
'the result' indicating no error (empty)
return empty for error -- set 'the result' to the parameter (empty) and 
clears 'it' (empty) indicating no value returned from the command


So, yes, "return empty" will do, but I choose to use "return empty for 
error" to remind me that it is purposefully 'the result' that I wanted 
to clear.



On 10/1/2019 10:39 AM, Bob Sneidar via use-livecode wrote:

Is the for error necessary? I just return empty.

Bob S



On Oct 1, 2019, at 06:02 , Paul Dupuis via use-livecode 
 wrote:

command clearResult
   return empty for error
end clearResult


___
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: Export snapshot and errors...

[Paul Dupuis via use-livecode]

On 10/1/2019 8:58 AM, Paul Dupuis via use-livecode wrote:
In LC905rc1, the Dictionary entry for Export Snapshot does not appear 
to indicate how any error value is returned (for example if the file 
can not be written)


the result is not cleared after an export snapshot - i.e.

put the result into tTemp1 -- if this put "X" in tTemp1
export snapshot from this cd of stack "Images" to file tFile as PNG
put the result into tTemp2 -- the result is still "X"

So, does export snapshot return any error values. Shouldn't it? Is 
this a Documentation bug and there is some return value that is not 
documented or an Engine bug and if Export Snapshot encounters and 
error, it should return an error message in the result or empty in the 
result if successful?


Related: Anybody have a good tip to CLEAR "the result"? If you really 
want to be sure it is empty before calling something that may change it?




Answer my own question on how to clear the result with:

command clearResult
  return empty for error
end clearResult

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

[Paul Dupuis via use-livecode]

In LC905rc1, the Dictionary entry for Export Snapshot does not appear to 
indicate how any error value is returned (for example if the file can 
not be written)


the result is not cleared after an export snapshot - i.e.

put the result into tTemp1 -- if this put "X" in tTemp1
export snapshot from this cd of stack "Images" to file tFile as PNG
put the result into tTemp2 -- the result is still "X"

So, does export snapshot return any error values. Shouldn't it? Is this 
a Documentation bug and there is some return value that is not 
documented or an Engine bug and if Export Snapshot encounters and error, 
it should return an error message in the result or empty in the result 
if successful?


Related: Anybody have a good tip to CLEAR "the result"? If you really 
want to be sure it is empty before calling something that may change it?


___
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: open process

[Paul Dupuis via use-livecode]

passing information (arguments, commands, etc.) to another program using 
"open process" requires that the other program has a mechanism to listen 
to interprocess messages. Most programs designed to accept a set of 
command-line parameters do not have listeners for inter process 
communication (IPC), so the general answer to your question is you 
probably can not provide arguments via open process to the copy command.



On 9/28/2019 10:05 AM, JB via use-livecode wrote:

In a shell command I can execute a external program
using the following code:

on mouseUp
   set the defaultFolder to desktop
put “myPic.jpg" into tFILE1
put “myPic copy.jpg" into tFILE2
put shell( "./copy" && quote & tFILE1 & quote && quote & tFILE2 & quote) 
into pData
answer question pData  —will be success or failed
end mouseUp

The code above will execute a program that has two arguments which are
the source file and destination file.  It is a simple copy program.

I was reading about open process:
--open process appName [for [text|binary] {read | write | update | neither}]

I can open a process and execute the above mentioned external program
but I am not able to supply the arguments.

Is it possible using open process to execute a program with arguments
and if it is would it be better to use the shell command or open process?

I know if you use a shell command it takes control until it is done and
open process might run in the background which I do not really need
that I know of in this instance.

JB
___
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: Stacks and Sub Stacks

[Paul Dupuis via use-livecode]

On 9/27/2019 11:29 PM, Sannyasin Brahmanathaswami via use-livecode wrote:

No one answers the other question, so I will ask it here, as it goes to Message 
Hierarchy

"put gotSomeFruit() into tBanana"

where " gotSomeFruit ()" is among the functions/handlers  is found among 
"stackInUse". ie. You DO get an returned result from the function.

But, sometimes, in the Script Editor, "Get Definition" is dimmed.



Get Definition appears to work if and only if there is 2 or more 
instances of the message, function, etc. in the possible message paths. 
If there is only a single instance, such as their might be for a custom 
function like "gotSomeFruit()" then it is dimmed out.


___
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

Language convenience rant...

[Paul Dupuis via use-livecode]

Assume I have a function guessTextEncoding that returns the various 
possible encoding for a text file.


If the file is MacRoman and my app is running on OSX (Platform() = "MacOS")
I can use:
put URL ("file:") into tText
put textDecode(tText,"Native") into ... destination
OR
put textDecode(tText,"MacRoman") into ... destination

Howeever if I have a MacRoman encoded text file (moved from OSX to 
Window via USB Memory stick or however) and my app is running under Windows


put textDecode(tText,"MacRomam") into ... destination

Throws a script error as MacRoman as an encoding parameter for the 
function is, as stated in the documentation, OSX ONLY, so instead I have to


put URL ("file:") into tText
put macToIso(tText) into ... destination

And conversely the same is true with a CP1252 encoded file under Windows
put URL ("file:") into tText
put textDecode(tText,"Native") into ... destination
OR
put textDecode(tText,"CP1252") into ... destination
both are good, but for a CP1252 encoded text file under OSX...
put textDecode(tText,"CP1252") into ... destination
throws an error, and so you have to use

put URL ("file:") into tText
put isoToMac(tText) into ... destination

You would think that SINCE the engine knows the platform AND the 
isoToMac and macToIso functions exists in the engine regardless of 
platform, that LiveCode, Ltd could have made:


put textDecode(tText,"MacRomam") into ... destination WORK under Windows
AND
put textDecode(tText,"CP1252") into ... destination WORK under OSX

So that instead of a SWITCH statements or a bunch of if-the-elses based 
on the results of a guessTextEncoding(tFile) function, you could just do:


put guessTextEncoding(tFile) into tEncoding
put URL ("file:") into tText
put textDecode(tText,tEncoding) into ... destination!

Enhancement request: https://quality.livecode.com/show_bug.cgi?id=22391

___
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: Does anyone know...

[Paul Dupuis via use-livecode]

Thank you Monte!

I ask because a text document we're working with word counting and word 
searching was returning odd results for a document in Georgian, but all 
other tested other languages (far short of all languages) are correct. I 
saw that Unicode 11.0 made some changes to Georgian.


It would be nice if LC 10 (or a sooner version) could include an update 
to ICU 64.2 which covers Unicode 12.0. ICU 61.2 especially is listed as 
have addressed many bug fixes that could account for some of the Unicode 
oddness we're still seeing (a few of which have been reported to the 
Quality Center)



On 9/25/2019 8:54 PM, Monte Goulding via use-livecode wrote:

We currently use ICU 58.2 which looks to be Unicode 9.0 + some extras 
http://site.icu-project.org/download/58 
<http://site.icu-project.org/download/58>


On 26 Sep 2019, at 7:50 am, Paul Dupuis via use-livecode 
 wrote:

... how often the Unicode engine/rules are updated in LiveCode? For example, 
the standard is at 12.1 (released May 2019 to add 1 character) and the last 
major release was 12.0 (released March 2019). Does anyone know what version the 
Unicode library in LC905rc1 uses?

Perhaps a  "the unicodeVersion" property might be a nice tiny addition to the 
language?

___
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

Does anyone know...

[Paul Dupuis via use-livecode]

... how often the Unicode engine/rules are updated in LiveCode? For 
example, the standard is at 12.1 (released May 2019 to add 1 character) 
and the last major release was 12.0 (released March 2019). Does anyone 
know what version the Unicode library in LC905rc1 uses?


Perhaps a  "the unicodeVersion" property might be a nice tiny addition 
to the language?


___
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 LC905rc1 function NOT Unicode aware

[Paul Dupuis via use-livecode]

And 'open printing to PDF' is yet another part of LC905rc1 still not 
Unicode aware. https://quality.livecode.com/show_bug.cgi?id=22385


Filename/paths and PDF document property options can not be Unicode.

___
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: Guess encoding for text file...

[Paul Dupuis via use-livecode]

I am sure my routine could be optimized some for performance. My 
consideration of doing this via OSX/Windows API using LCB FFI is only 
partially about performance. I think an advantage is that the OS vendors 
(with way more resources than me) are more likely to keep the algorithms 
reflecting up to date best practices (I know some of you will laugh at 
that).  Additionally, I might hope that, at some point, LiveCode 
corporate might consider taking it over if it was an collaborative open 
source effort LCB library than a LCS script.



On 9/17/2019 6:45 PM, Curry Kenworthy via use-livecode wrote:


Paul:

> I have a LiveCode Script (LCS) routine that attempts to
> follow industry common algorithms for guessing the encoding
> of a text file.
> It's performance can be slower than I would like.

Howdy,

Even though LC 9 is exceedingly slow on some operations -(cough, 
cough, ahem, that's a topic in itself)- HOWEVER, I believe it's quite 
capable of satisfactory performance in this particular area without 
needing LCB, much less C.


Pretty sure I can optimize your legacy routine to work just fine. It 
simply wasn't designed for huge files, nor for LC 9's slow-mo loop 
speed, but that could be easily remedied with a few tweaks!


Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.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: Sorting strangeness

[Paul Dupuis via use-livecode]

Good to know. Thank you.

On 9/18/2019 11:03 AM, Mark Waddingham via use-livecode wrote:

On 2019-09-18 15:43, Paul Dupuis via use-livecode wrote:

Again, thank you Mark - this helped immensely.

In making a commercial text analytics application, we do a lot of
sorting of user entered textual data. With the move from LC6.7.11 to
LC9.0.5rc1 we discovered the sort text issue bug, but them we many
dozens of sort statements through out our code, we wanted to be sure
switching all text sorts to international was the right way to go. All
are for user facing data. The alternative was to abstract them to a
new function that used any of the work-arounds you identified for the
sort text issue.


If you are updating to use sort international (which sounds like the 
correct
thing to do in this case) then I'd still recommend abstracting to a 
command

handler which does the sorting (which will have no measurable impact on
performance). e.g.

  command sortTextListForUserDisplay @xList, pDirection
    switch pDirection
    case "ascending"
  sort xList international ascending
  break
    case "descending"
  sort xList international descending
  break
    end switch
  end sortTextListForUserDisplay

The reason here is that it means it gives you more control in the 
future. Whilst
it didn't make it into 9.5, we have been working on more general 
'collation'
support which allows you to choose (with a high degree of flexibility) 
how sorting
occurs. So if you abstract now, then it makes it easier to change 
things in the

future should you want to.

Warmest Regards,

Mark.

P.S. Indeed you might find that not all your 'sort text' instances are 
suitable
for sort international when you go through - so abstracting those with 
a similarly
richly named handler might also help code documentation as much as 
anything else.





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

[Paul Dupuis via use-livecode]

Again, thank you Mark - this helped immensely.

In making a commercial text analytics application, we do a lot of 
sorting of user entered textual data. With the move from LC6.7.11 to 
LC9.0.5rc1 we discovered the sort text issue bug, but them we many 
dozens of sort statements through out our code, we wanted to be sure 
switching all text sorts to international was the right way to go. All 
are for user facing data. The alternative was to abstract them to a new 
function that used any of the work-arounds you identified for the sort 
text issue.


Thanks again!

On 9/18/2019 2:57 AM, Mark Waddingham via use-livecode wrote:

On 2019-09-16 21:54, Paul Dupuis via use-livecode wrote:

IF sort lines of  ascending text was working correctly for lines
of mixed ASCII and Unicode, for someone sorting lines of text that can
be Native text, Unicode text (both RTL and LTR), or mixtures of both,
is it better to use SORT ... TEXT or SORT ... INTERNATIONAL? I don't
know enough about what the "international" (using the system locale
settings)  and Unicode may mean in relation to one another?


You should use 'sort international' when you are displaying a sorted list
to a user who is looking through it manually.

The ordering provided by 'sort text' is purely by unicode codepoint, 
which
has no direct relation to 'expected' order when read by a human and 
instead
is determined by technical considerations (structuring a large 21-bit 
space,
frequency of use and, most importantly, round-tripping to legacy 
encodings and

standards).

The core of the sort order provided by 'international' sorting is the
Unicode Collation Algorithm - which provides (at its code) a 
locale-independent
order for all the languages/scripts present in Unicode. e.g. Latin 
European
languages are generally expected to come before Greek which is 
expected to

come before Cyrillic.

This core order is then tailored by locale to enable account to be taken
of the individual expectations of the user of the sorted list. For 
example,
different languages have different sort orders for what you might 
consider
the 'same letters' due to using the same glyphs. For example, a 
Swedish user

would expect 'z' to sort before 'ö'; whereas a German user would expect
'ö' to sort before 'z'.

The engine uses ICU's implementation of Unicode collation, and 
supports a wide
range of locales - the locale used is read on engine startup from the 
user's

system settings.

Hope this helps,

Mark.




___
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

Guess encoding for text file...

[Paul Dupuis via use-livecode]

I started this post of the DEV-LIST. Mark Waddingham kindly responded 
and smartly suggested I should move it to the USE-LIST, so that is what 
I am doing. I have also pasted Lark's reply below my original post.


-- ORIGINAL POST 



I have a LiveCode Script (LCS) routine that attempts to follow industry 
common algorithms for guessing the encoding of a text file.


It's performance can be slower than I would like.

This has led me to wonder in a LiveCode Builder (LCB) library may be the 
route to go. Does anyone know the OSX and/or Windows APIs for guessing a 
text file's encoding?


I have done a number of google searches, but I am not a C programmer 
(not in many decades) and wading through the huge doc sets at MSDN or 
Apple is daunting.


I found reference to a windows API:

BOOL IsTextUnicode( const VOID *lpv, int iSize, LPINT lpiResult );

Which suggests to me that such APIs may exists. Does anyone who is 
better at finding OS APIs know where to find such APIs? Can you point me 
to the right online documentation?


I also found this: 
https://stackoverflow.com/questions/3825390/effective-way-to-find-any-files-encoding


Of course, it would be wonderful if the mothership delivered this. At 
one point Frasier said he would back around LC7 something.


https://quality.livecode.com/show_bug.cgi?id=14474

It seems an LCB library that uses OS APIs to return best guess for file 
encoding that match up with the textEncode/Decode functions would be a 
great addition to LC


 * "ASCII"
 * "UTF-16"
 * "UTF-16BE"
 * "UTF-16LE"
 * "UTF-32"
 * "UTF-32BE"
 * "UTF-32LE"
 * "UTF-8"
 * "CP1252"
 * "ISO-8859-1"
 * "MacRoman"

and I suppose "Binary" as the default if none of the above can be detected

- MARK'S REPLY 
On 2019-09-13 16:44, Paul Dupuis wrote:
> I have a LiveCode Script (LCS) routine that attempts to follow
> industry common algorithms for guessing the encoding of a text file.
>
> It's performance can be slower than I would like.

If you share your code perhaps we can help speed it up...

> This has led me to wonder in a LiveCode Builder (LCB) library may be
> the route to go. Does anyone know the OSX and/or Windows APIs for
> guessing a text file's encoding?
>
> I have done a number of google searches, but I am not a C programmer
> (not in many decades) and wading through the huge doc sets at MSDN or
> Apple is daunting.
>
> I found reference to a windows API:
>
> BOOL IsTextUnicode(
>   const VOID *lpv,
>   int    iSize,
>   LPINT  lpiResult
> );
>
>  Which suggests to me that such APIs may exists. Does anyone who is
> better at finding OS APIs know where to find such APIs? Can you point
> me to the right online documentation?

Libraries certainly exist: Mozilla has a 'universal charset detector 
library' for example, which appears to use various statistical 
heuristics to tell between all kinds of encodings.


The 'IsTextUnicode' API seems to just tell you whether a sequence of 
bytes is likely to be UTF-16 or not UTF-16; so probably won't be all 
that helpful if that isn't all you are wanting to distinguish between.


Do you have a list of encodings you are needing to guess between? That 
will generally influence how fast (and accurate) you can make such a 
function (its almost trivial to detect UTF-8 with a high degree of 
confidence, UTF-32 I think as well, UTF-16 is somewhat harder, and 
distinguishing between single-byte and legacy multi-byte charsets is, 
relatively speaking, very hard).


Warmest Regards,

Mark.

P.S. This might be a better discussion to have on the use-list unless 
there is a reason not to, it might be of interest to others in that 
wider group.


--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
livecode-dev mailing list
livecode-...@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/livecode-dev

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

[Paul Dupuis via use-livecode]

Mark,

Thank you, as always, for your incredible depth of knowledge of the engine!

Bug filed: https://quality.livecode.com/show_bug.cgi?id=22378 with 
sample stack and your comments.


If I can impose on you, I have one more question related to this topic:

IF sort lines of  ascending text was working correctly for lines of 
mixed ASCII and Unicode, for someone sorting lines of text that can be 
Native text, Unicode text (both RTL and LTR), or mixtures of both, is it 
better to use SORT ... TEXT or SORT ... INTERNATIONAL? I don't know 
enough about what the "international" (using the system locale 
settings)  and Unicode may mean in relation to one another?


Thank you again,

Paul Dupuis
Researchware


On 9/16/2019 2:45 PM, Mark Waddingham via use-livecode wrote:

On 2019-09-16 19:01, Paul Dupuis via use-livecode wrote:

Thanks Bob for being one of the folks on the list who always tries to
offer a solutions for people.

That said, I have solutions a plenty. My real question is for
LIVECODE, LTD or perhaps someone like Mark Waddingham who could
actually tell whether this is the expected behavior (not a BUG, but
probably should be documented) or an aberrant behavior (a BUG and
should be reported)


Its definitely a bug - sorting a field with that content works 
correctly, but sorting a variable doesn't.


After staring at the string for a while it occurred to me that the 
line which is sorting incorrectly is all ASCII - "Norwegian Norsk" - 
indeed the following causes the string to sort correctly again:


  sort  ascending text by (each & 
(numToCodepoint(0xFFEF)))


When sort is done, it first splits the input string into separate 
strings - one for each line. In this case the "Norwegian Norsk" line 
becomes a native string, whereas all the others are unicode. The above 
forces all lines on which the string is sorted to be forced to unicode 
so the bug doesn't manifest.


Poking around some more, this also seems to work correctly:

  set the caseSensitive to true
  sort  ascending text

So there appears to be a difference between the sort keys being 
generated for unicode and native strings - at least when caseSensitive 
is false.


The field case works because the field coerces all content to unicode 
(as the text APIs on all platforms take UTF-16 these days), and I 
believe there is an optimization in place if you sort a field by lines 
- it doesn't have to cut anything up, it just uses the backing string 
from each paragraph.


I have a feeling I know precisely where the problem lies, so if you 
file a bug (for once) we should be able to fix it quite rapidly.


Warmest Regards,

Mark.

P.S. Another way to get the correct result is to do this (which is 
essentially what the engine does internally if caseSensitive is true):

  set the caseSensitive to true
  sort  ascending text by toLower(each)





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

[Paul Dupuis via use-livecode]

Thanks Bob for being one of the folks on the list who always tries to 
offer a solutions for people.


That said, I have solutions a plenty. My real question is for LIVECODE, 
LTD or perhaps someone like Mark Waddingham who could actually tell 
whether this is the expected behavior (not a BUG, but probably should be 
documented) or an aberrant behavior (a BUG and should be reported)



On 9/16/2019 12:16 PM, Bob Sneidar via use-livecode wrote:

This does not answer the why, but as far as case specific, you can sort lines of 
 by word 1 of each ascending text

Bob S



On Sep 16, 2019, at 09:10 , Paul Dupuis via use-livecode 
 wrote:

Okay, here is a Monday morning puzzler for folks:

Take the following text:

Chinese 中文
Georgian ქართული
Arabic عربى
Greek Ελληνικά
Russian русский
Norwegian Norsk

"sort lines of  ascending international" produces exactly what 
is expected:

Arabic عربى
Chinese 中文
Georgian ქართული
Greek Ελληνικά
Norwegian Norsk
Russian русский

However, "sort lines of  ascending text" produces:

Arabic عربى
Chinese 中文
Georgian ქართული
Greek Ελληνικά
Russian русский
Norwegian Norsk

Now, WHY should Russian appear BEFORE Norwegian with R before N in treating it as a 
straight ASCII sort ("text")???

Try it yourself in LC9.0.5rc1. Is this a BUG? or should unpredictable results be expected 
if using a default (as "text" is the default) sort of text in LC9.0.5?


___
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 Luvv Da Buggs - Greatest Hits - "Player"

[Paul Dupuis via use-livecode]

A very entertaining way to present such a sad list :-)

Between these and the lengthy list of Unicode bugs... sigh.

On 9/16/2019 1:01 PM, Curry Kenworthy via use-livecode wrote:


Who would have thought the old player to have had so much bugs in it?

Enough per square inch to rival a rowdy case of mange?

Makes me wanna hear somebody sing the blues ♫♪

Check out how many bug tracks are included! The bugs will play all 
night, while you work around to get it right


Artist: LC Luvv Da Buggs
Album: "Player"

♫ Can't stop now - after your touch
https://quality.livecode.com/show_bug.cgi?id=22282
(Extra play after endTime sans currentTimeChanged)

♫ Throw it all away; it's just a selection
https://quality.livecode.com/show_bug.cgi?id=22283
(Selection lost when clicking timeline)

♫ Ain't gonna repeat myself
https://quality.livecode.com/show_bug.cgi?id=22284
(Play button unresponsive at endTime)

♫ Don't follow me, or someone will get hurt (me)
https://quality.livecode.com/show_bug.cgi?id=22248
(currentTimeChanged only sent to last of any players with same path)

♫ This can't be the end - gotta keep on keepin' on
https://quality.livecode.com/show_bug.cgi?id=22360
(Player with playSelection true does not stop at endTime)

♫ I ain't playin' (better stop before we get started)
https://quality.livecode.com/show_bug.cgi?id=22361
(Player jumps to duration upon reaching startTime)

♫ I can't keep going, it's still the end my friend
https://quality.livecode.com/show_bug.cgi?id=22362
(Player jumps to duration upon reaching endTime)

♫ Let's skip the beginning, baby (can't wait)
https://quality.livecode.com/show_bug.cgi?id=22363
(Player restarts past initial content)

♫ You can't see me, but I'm in control - maybe
https://quality.livecode.com/show_bug.cgi?id=22353
(Controller disappears after Mac window resize)

♫ March to my own beat (anybody got the time?)
https://quality.livecode.com/show_bug.cgi?id=22364
(Content does not match currentTime after playSelection is changed)

♫ Not made for this world - gone in a flash
https://quality.livecode.com/show_bug.cgi?id=22333
(Selection handles too fragile to survive actual use)

♫ We can't rush this (nor can we slow it down, baby)
https://quality.livecode.com/show_bug.cgi?id=22075
(playRate not working for MP3s on Windows)

♫ Hey world, look at me now
https://quality.livecode.com/show_bug.cgi?id=22105
(Player Controller Bar parts drawn on top of everything)

Yep, the player is squared away!

Best wishes,

Curry K.

___
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

Sorting strangeness

[Paul Dupuis via use-livecode]

Okay, here is a Monday morning puzzler for folks:

Take the following text:

Chinese 中文
Georgian ქართული
Arabic عربى
Greek Ελληνικά
Russian русский
Norwegian Norsk

"sort lines of  ascending international" produces exactly 
what is expected:


Arabic عربى
Chinese 中文
Georgian ქართული
Greek Ελληνικά
Norwegian Norsk
Russian русский

However, "sort lines of  ascending text" produces:

Arabic عربى
Chinese 中文
Georgian ქართული
Greek Ελληνικά
Russian русский
Norwegian Norsk

Now, WHY should Russian appear BEFORE Norwegian with R before N in 
treating it as a straight ASCII sort ("text")???


Try it yourself in LC9.0.5rc1. Is this a BUG? or should unpredictable 
results be expected if using a default (as "text" is the default) sort 
of text in LC9.0.5?



___
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: Test post: Its awfully quiet around here...

[Paul Dupuis via use-livecode]

On 9/16/2019 9:16 AM, Mark Waddingham via use-livecode wrote:

Testing...



Not trying to be snide or anything, but I've been too busy posting bugs 
to the LC quality center and trying to get our 2 commercial applications 
onto LC905 to post much unless it is related to bugs.




___
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: Merge and unicode

[Paul Dupuis via use-livecode]

Doesn't any Unicode in htmlText of a field need to be in HTML form (i.e. 
#;?


I thought htmlText turns any non ASCII into either hex encoded html or, 
where html entity names exists, uses html entity names.



On 9/9/2019 6:35 PM, J. Landman Gay via use-livecode wrote:

On 9/9/19 2:39 PM, Paul Dupuis via use-livecode wrote:

On 9/9/2019 2:13 PM, J. Landman Gay via use-livecode wrote:

On 9/9/19 1:08 PM, J. Landman Gay via use-livecode wrote:
It seems that the merge command doesn't respect unicode. Does 
anyone have a workaround? The text I'm inserting is already decoded 
to UTF16.




I misspoke, sorry. It's the metadata that doesn't respect unicode.



Can you clarify what you mean when you say the "metadata" doesn't 
respect Unicode?


I'm in the middle of a big Unicode problem and have found and 
reported a ton of bugs where Unicode is not yet everywhere. I'm 
keenly interested in any I don't know about.


Actually I just double-checked and both merge and metadata may be wrong.

I get UTF8 text from a server that is then textDecoded to UTF16, and 
an html template that I merge with parts of the UTF16 text. In the 
variable watcher, the merged template looks correct but when a field 
is set to the htmltext the result is wrong, diacriticals and curly 
quotes are question marks. My solution for that was to urlEncode the 
content before merging, and urlDecoding when extracting it for 
display. That works.


In another part of the app I use the same (UTF16) text to set the 
metadata of a line in a field. When the script gets the metadata 
later, diacriticals and curly quotes are strange characters with very 
high UTF numbers.





___
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: OT: Catalina - the end of ad hoc & in-house development?

[Paul Dupuis via use-livecode]

If I want to develop an small OSX (or Windows) app for my wife to help 
her keep track of some hobby related items, I should not have to code 
sign or notarize it for OSX or Windows or, honestly, any platform.


Every OS should provide a way that the USER is still in control of their 
OS and can tell the OS, I trust this application. Period.


Attempting to idiot proof the OS only leads to the creation of more idiots.



On 9/9/2019 2:07 PM, Matthias Rebbe via use-livecode wrote:

Although i understand anyone´s concern about Apple new requirement for 
notarization, i welcome Apple´s effort to make Mac OS X apps more secure for 
the users. I was also not very happy when i first heard that  10.14.6 will not 
start unnotarized apps right away.

But what are our options here?
Either we stop developing for Apple or we fulfill Apple´s requirements. 
Everyone has to decide for her/himself, if the extra work for this Notarization 
is worth it.

Even if there is a way to run unnotarized apps under Mojave by going to 
security control panel and allow the app to be opened, i think this is not very 
user friendly and also not not very trustworthy, regardless if it is a free or 
a commercial app.


Under  Windows developers have to purchase a CodeSigining Certificate which 
costs from 79,- to 300,- USD, depending on where you buy from and depending on 
the type of the certificate, to be able to codesign.  And if i remember right, 
also under future Windows versions it will be more difficult to run unsigned 
Apps. At least there will be a popup with a warning message, this is currently 
in Win10 the case. That is also not very trustworthy, isn´t it?



Anyway, some weeks ago i´ve posted a link to a Livecode lesson which not only 
describes the required manual steps to notarize and staple an app for 
distribution outside the Mac Appstore , but also includes an helper stack which 
does all the needed steps.

You´ll find the lesson here: 

  


Regards,
Matthias

Matthias Rebbe

free tools for Livecoders:
InstaMaker 
WinSignMaker Mac 

Am 07.09.2019 um 13:18 schrieb Peter Reid via use-livecode 
mailto:use-livecode@lists.runrev.com>>:

I've been using LiveCode as my development platform since 1999. Practically all the apps 
I've developed have been for in-house use by my family, friends and customers - all very 
low numbers of copies distributed in an informal manner. I've no interest in App Store 
distribution and the users of my apps trust me such that they do not need my apps to be 
"approved" by Apple. What's more important to them is how quickly I can release 
new apps and new versions of existing apps.

Up to and including macOS Mojave my users can run my apps with the minor 
inconvenience of having to right-click an app and approve its use, just once. 
With macOS Catalina, if I understand things, it's not so simple, instead these 
are the options:

1. Code-sign and notarise my apps – I'm not interested in this for my kind of 
apps which are essentially in-house/at home developments.

2. Using an active Internet connection, go through the right-click technique as 
now not just once, but EVERY time the app is opened.

In the past the 'Security & Privacy' General tab had a 3rd option for the 
setting 'Allow apps downloaded from:' which allowed you to install and use apps 
from any source. It seems that this is not possible with Catalina.

So with Catalina my users will need an Internet connection and will have to go 
through the right-click authorisation process every time they open one of my 
apps.

More seriously, it is becoming increasingly difficult to recommend the 
combination of the Mac plus LiveCode for app development. Up to now I've done 
all my app development on Mac+LC, even where the target platform is Windows or 
Android or Linux – I find it's simply faster, less error-prone and more 
pleasant with the Mac. However, from Catalina onwards even simple little 
utility apps, created for short-term use, will be tedious when opening or you 
have to learn about the complexity of code-signing and notarising and accept 
slower development cycles due to the need for Apple's approval!

This is quite depressing, especially since I abandoned iOS development due to 
Apple's distribution restrictions.

Back when the iPad 2 had just been released I developed for one of my customers an app 
to support health & safety audits for a national UK retail chain. The app took me 
15 days to develop in total. As a result of being able to field a team of 10-20 staff 
with iPads running my app, my customer was able to carry out 350 half-day H 
audits for 3 years. However I was unable to roll-out this app to other customers as the 
ad hoc distribution method I was using was limited to 100 iPads per year and the App 
Store was not 

Re: Merge and unicode

[Paul Dupuis via use-livecode]

On 9/9/2019 2:13 PM, J. Landman Gay via use-livecode wrote:

On 9/9/19 1:08 PM, J. Landman Gay via use-livecode wrote:
It seems that the merge command doesn't respect unicode. Does anyone 
have a workaround? The text I'm inserting is already decoded to UTF16.




I misspoke, sorry. It's the metadata that doesn't respect unicode.



Can you clarify what you mean when you say the "metadata" doesn't 
respect Unicode?


I'm in the middle of a big Unicode problem and have found and reported a 
ton of bugs where Unicode is not yet everywhere. I'm keenly interested 
in any I don't know about.


___
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: Weird behavior for modal stacks and answer dialogs

[Paul Dupuis via use-livecode]

On 9/9/2019 6:50 AM, Giovanni via use-livecode wrote:

Hi everybody,
I’m writing here to report a very strange behavior of modal stacks and answer 
dialogs on MacOS Yosemite and Sierra.
Basically the modal windows or dialogs, in these OSes simply does not work and 
this seems to happen since LC 6.7.x!
When you open a modal stack the expected behavior is that the script execution 
is interrupted and you cannot interact with the calling or other opened 
windows. While the first thing seems to happen, the second one doesn’t work: 
you can click on buttons, fields or any other control in the calling stack or 
any other stack opened.
I think that this is a very big problem mainly in porting applications from 
older versions of LC to the newest one and it’s quite strange that nobody else 
noticed this before or consider this a problem.

I already filed a bug report at https://quality.livecode.com/show_bug.cgi?id=22368 
 in which you can also find 
a demo stack to easily reproduce the behavior.

Anyone can comment on this? Are you experiencing this as a problem? Is there a 
workaround or a solution for this?

The problem seems not to be present on Mojave but I was not able to try on 
other versions on MacOS and it’s not present on Windows.




This one has been around for a while, and I thought it had been 
previously reports (but still not fixed). I seem to recall there was a 
lengthy discussion of it on the list a long time ago.


The work-around seems to be locking things down before calling an ask or 
answer dialog (lock messages, lock your menus and so on) so that no 
other user actions can start any other script.


___
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: OT: Catalina - the end of ad hoc & in-house development?

[Paul Dupuis via use-livecode]

Everyone is signing the praises of tools to jump through Apple's hoops, 
but I see no one refuting Peter's original claims that Catalina is a ste 
towards the end of ad-hoc and in-house development for the Apple 
platform and I would agree.


Apple's goal for OSX is to get to the same place as iOS, where all OSX 
apps go through the Apple store operation for a 30% cut. Eventually, you 
will not be able to distribute an OSX application yourself directly to a 
friend who runs OSX. It will go through Apple and, yes, it may be a 
"free" app, but the endlessly changing hurtles that are discussed 
frequency on this list for iOS will become the same for OSX and that 
overhead will kill off a certain number of developers who just do not 
have the time or patience or money to jump through those hoops. And 
because - those sort of small ad-hoc or in-house developers - will never 
contribute significantly to Apple's bottom line, Apple really doesn't 
care one bit about them.


My 2 cents from having been close to Apple since the Lisa was released.


___
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: Unicode is not "everywhere"...

[Paul Dupuis via use-livecode]

Mark,

1) Fine with shell remaining as is. Thanks to Dar and others, there are 
ways to execute a windows or OSX shell command that returns Unicode and 
get Unicode back. The Dictionary entries just need to be documented 
with  a caution or warning about how to handle Unicode with Shell on 
each platform. I'd be happy to change the bug to a DOC bug and update 
the dictionary if you give the go-ahead.


2) Fine with urlEncode/urlDecode remaining as it. If LC want to make a 
set of functions urlEncodeRFC/urlDecodeRFC, I am all for that, however, 
just documenting the convention that Unicode should be UTF8 encoded 
before urlEncoding and UTF8 decoded after URLDecoding in the Dictionary 
would be sufficient. I opened two documentation bugs (one for each 
dictionary entry for urlencode/decode exactly for updating the 
Dictionary with the intent to do that myself as soon as I have a chance.


3) I (Researchware, Inc.) desperately needs a fix for the detailed 
files/detailed folder - asap. Our main application depends upon it. We 
have moved the app from LC6.7.11 to LC 9.0.5rc1 and made it full Unicode 
for the international market, but the part of our app that extensively 
manages users research documents for their projects relies on "the 
detailed files" which does not work with Unicode and my work-around 
using shell (see the bug entry) is PAINFULLY slow.


So new functions 'fileInfo' and 'folderInfo' would be wonderful or 
something - anything - that can be done sooner rather than later.


Researchware (between myself and Curry whose working for us) filed about 
20+ LC bugs in the last 60 days. The wonderful thing about LC is that 
we've been able to code work-arounds for most all of those many bugs. 
I've even coded a work-around for the "detailed" files, but it's 
performance due to the multiple shell calls is very poor. Our customers 
won't stand for it for very long, hence the desperate need for a 
solution sooner rather than later.


Please, please consider moving a solution to the detailed files to a 
forthcoming release.



On 8/27/2019 8:11 AM, Mark Waddingham via use-livecode wrote:

On 2019-08-22 21:07, Paul Dupuis via use-livecode wrote:

I reported what I thought was 3 bugs in 1 report in
https://quality.livecode.com/show_bug.cgi?id=22213. I have edited that
report to focus on a single bug - that the detailed files (and
probably the detailed folders) is broken for Unicode as every Unicode
character in a file name is encoded as %3F or ?. Originally I had
though that meant that there was a problem with urlEncode and
urlDecode as per bug
https://quality.livecode.com/show_bug.cgi?id=14015 that your
references Monte. However, I now consider that urlEncode and urlDecode
are NOT broken and bug 14015 is really a Documentation bug that the
urlEncode and urlDecode Dictionary entries should be updated.



Also, the detailed files and detailed folders doesn't need an array
returned (although that would be nice). This issue is the
percent-encoding is not following the standard convention of UTF8
encoding non-ASCII characters before percent encoding. LC should
follow industry conventions in this regard.


Strictly speaking urlEncode and urlDecode are indeed not broken - they 
are just very old. They were implemented when there were no 
universally accepted industry conventions for encoding of URLs 
(particularly those containing international characters).


They cannot be changed for obvious reasons - but we could do with 
urlEncodeRFC and urlDecodeRFC which would be string->string functions 
which do what is expected today. (And also not encode some characters 
in a way which is now not the 'standard du jour').


For the same reason that urlEncode and urlDecode cannot be changed, 
the detailed files/folders cannot be changed.


My general feeling here is that 'the detailed files' and 'the detailed 
folders' should be put out to pasture as they are grossly inefficient 
and difficult to work with.


Instead new functions 'fileInfo' and 'folderInfo' could replace them. 
They would take one or two parameters, the first a filename and the 
second an optional attribute.


If no attribute is specified then an array of all known attributes for 
the platform is returned; otherwise that specific attribute is returned.


e.g. fileInfo("foo.txt", "modification time") -> returns the 
modification time of foo.txt
 fileInfo("foo.txt") -> returns an array with keys such as 
"modification time" mapping to the obvious thing


I'd probably vote for the functions returning empty if the target 
didn't exist (rather than throwing an error), for the simple reason as 
you can't check for existence of a file and get its details in an 
atomic fashion (another process could decide to delete the file you 
just asserted existed between the 'there exists' and the 'fileInfo' 
call).


Warmest Regards,

Mark.




___

Re: Unicode is not "everywhere"...

[Paul Dupuis via use-livecode]

You know, I don't know.

I have spent so much time on these bugs that my brain is burned out. 
Someone like Mark Waddingham can determine the architecturally correct 
return values and then make sure the Dictionary reflects the right way 
to use them.


At this point, I have work-arounds to shell (thanks). I just want the 
detail files/folders to be fixed as my work-around is slow.



On 8/23/2019 4:37 PM, Dar Scott Consulting via use-livecode wrote:

If shell returns text, does that mean shellCommand has to go away?


On Aug 23, 2019, at 9:05 AM, Paul Dupuis via use-livecode 
 wrote:

On 8/23/2019 10:30 AM, Dar Scott Consulting via use-livecode wrote:

SHELL()

Related:  https://quality.livecode.com/show_bug.cgi?id=22334 
<https://quality.livecode.com/show_bug.cgi?id=22334>
  
I was on the fence concerning whether shell() returns a text string or binary data. I have fallen to one side: BINARY.

I concur with the general idea of returning a 8-bit byte stream from Shell 
(i.e. binary)


Here is a summary of my position. Tomatoes are welcome.

The shell() function is on the edge of LiveCode. All I/O on the edge is binary 
and is either used that way or is text decoded. The text decoding can be part 
of the I/O operation or explicit. I see shell() this way. LiveCode has no 
control over what command line tools will do, or what the executable in 
shellCommand will do.

Some I/O operations have optional text decoding built-in. This can be added to 
shell(), but I don't think it is needed.

LEGACY: For my part, I have used shell() with an underlying assumption of 
ASCII. This assumption works OK with the ASCII subset of Latin-1, UTF-8 and 
most Windows codepages. I think most uses of shell() make this assumption plus 
the assumption that a text decoding is not needed. For this to be preserved, 
the text interpretation of a binary data should continue to be a sequence of 
single byte characters from an ASCII superset, and the default values for 
shellCommand should ensure that for each OS.

Well this is why I advocate that the encoding should be UTF-8 rather than UTF-16. (1) this 
matches shell() on OSX which returns results from the shell command UTF-8 encoded, or would you 
suggest changing OSX?; (2) UTF8 encoding means that people expecting ASCII can just work with 
the returned results as they always have. People expecting Unicode, will need to perform a 
textDecode(shell(),"UTF-8") and if the results were just ASCII, they 
they are still fine, since UTF8 decoding ASCII = ASCII.


My recommendation:
shell(x) is strictly binary data
A textDecode example is provided in dict for shell.
shellCommand is reference in dict for shell.
The "cmd.exe /u" example is provided in dict for shellCommand
Correct the default for shellCommand in dictionary.

My recommendation:
Fix Windows shell() to UTF8 encode results
Add a textDecode example to the Dictionary entry for BOTH Windows and OSX (and 
Linux, where I have no idea what Linux does)
Correct the CMD.EXE vs Command.exe reference in the Dictionary as well


Dar Scott
Mad Scientist

Paul Dupuis
Mad Wizard
:-)




On Aug 22, 2019, at 9:37 AM, Paul Dupuis via use-livecode 
 wrote:

I have filed two bug reports that are in LC905rc1 and go back to 7.0 where LC 
functions that should deal with Unicode properly do not.

These are:
https://quality.livecode.com/show_bug.cgi?id=22213 -- The "detailed files" 
function fails for any files with Unicode in the name, returning the filename with %3F 
(?) instead of the Unicode characters properly URL encoded (they should be UFT8 encoded 
and then URL encoded)
and
https://quality.livecode.com/show_bug.cgi?id=22334 -- the shell command is not 
Unicode aware in returning it's results. On OSX, the results are UTF8 encoded 
(discovered by accident) and so an extra step is needed to text decode them, 
but on Windows it is a complete failure and any Unicode results of the command 
line - SHOWN 100% correctly is executed in the command line - are returned 
NATIVE encoded, causing all Unicode characters to become question marks.

I have written work-around for both of these bugs that can be found in the bug reports. 
My work-around for the "details files" is slow, due to repeated calls to shell 
to fetch file properties one at a time.

If anyone else out there has run into these bugs in your own code and developed a faster 
work-around for the "detailed files" and would care to share, I would welcome a 
faster fix.

Of course, I'd welcome a fix from LiveCode, Ltd. to these bugs even more!

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

Re: Unicode is not "everywhere"...

[Paul Dupuis via use-livecode]

On 8/23/2019 10:30 AM, Dar Scott Consulting via use-livecode wrote:

SHELL()

Related:  https://quality.livecode.com/show_bug.cgi?id=22334 
<https://quality.livecode.com/show_bug.cgi?id=22334>
  


I was on the fence concerning whether shell() returns a text string or binary 
data. I have fallen to one side: BINARY.


I concur with the general idea of returning a 8-bit byte stream from 
Shell (i.e. binary)



Here is a summary of my position. Tomatoes are welcome.

The shell() function is on the edge of LiveCode. All I/O on the edge is binary 
and is either used that way or is text decoded. The text decoding can be part 
of the I/O operation or explicit. I see shell() this way. LiveCode has no 
control over what command line tools will do, or what the executable in 
shellCommand will do.

Some I/O operations have optional text decoding built-in. This can be added to 
shell(), but I don't think it is needed.

LEGACY: For my part, I have used shell() with an underlying assumption of 
ASCII. This assumption works OK with the ASCII subset of Latin-1, UTF-8 and 
most Windows codepages. I think most uses of shell() make this assumption plus 
the assumption that a text decoding is not needed. For this to be preserved, 
the text interpretation of a binary data should continue to be a sequence of 
single byte characters from an ASCII superset, and the default values for 
shellCommand should ensure that for each OS.


Well this is why I advocate that the encoding should be UTF-8 rather 
than UTF-16. (1) this matches shell() on OSX which returns results from 
the shell command UTF-8 encoded, or would you suggest changing OSX?; (2) 
UTF8 encoding means that people expecting ASCII can just work with the 
returned results as they always have. People expecting Unicode, will 
need to perform a textDecode(shell(),"UTF-8") and if the 
results were just ASCII, they they are still fine, since UTF8 decoding 
ASCII = ASCII.



My recommendation:
shell(x) is strictly binary data
A textDecode example is provided in dict for shell.
shellCommand is reference in dict for shell.
The "cmd.exe /u" example is provided in dict for shellCommand
Correct the default for shellCommand in dictionary.


My recommendation:
Fix Windows shell() to UTF8 encode results
Add a textDecode example to the Dictionary entry for BOTH Windows and 
OSX (and Linux, where I have no idea what Linux does)

Correct the CMD.EXE vs Command.exe reference in the Dictionary as well


Dar Scott
Mad Scientist


Paul Dupuis
Mad Wizard
:-)





On Aug 22, 2019, at 9:37 AM, Paul Dupuis via use-livecode 
 wrote:

I have filed two bug reports that are in LC905rc1 and go back to 7.0 where LC 
functions that should deal with Unicode properly do not.

These are:
https://quality.livecode.com/show_bug.cgi?id=22213 -- The "detailed files" 
function fails for any files with Unicode in the name, returning the filename with %3F 
(?) instead of the Unicode characters properly URL encoded (they should be UFT8 encoded 
and then URL encoded)
and
https://quality.livecode.com/show_bug.cgi?id=22334 -- the shell command is not 
Unicode aware in returning it's results. On OSX, the results are UTF8 encoded 
(discovered by accident) and so an extra step is needed to text decode them, 
but on Windows it is a complete failure and any Unicode results of the command 
line - SHOWN 100% correctly is executed in the command line - are returned 
NATIVE encoded, causing all Unicode characters to become question marks.

I have written work-around for both of these bugs that can be found in the bug reports. 
My work-around for the "details files" is slow, due to repeated calls to shell 
to fetch file properties one at a time.

If anyone else out there has run into these bugs in your own code and developed a faster 
work-around for the "detailed files" and would care to share, I would welcome a 
faster fix.

Of course, I'd welcome a fix from LiveCode, Ltd. to these bugs even more!

___
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: Unicode is not "everywhere"...

[Paul Dupuis via use-livecode]

Hi Dar,

Yes, this is a viable work-around for the Windows shell bug.

function newShell pCommand
  local tResult
  set the hideConsoleWindows to true
  set the shellCommand to "cmd.exe /u" --/U for UTF16 output
  put shell(pCommand) into tResult
  if the result is empty then -- no errors
    put textDecode(tFileDetails,"UTF-16") into tResult
    replace cr with cr in tResult
  end if
  return tResult
end newShell

The above can be used with any Windows shell command that is expected to 
return non-ASCII text


Thank you, I was unaware of the /U switch for CMD.EXE.

Still, I would like the "detailed files" bug fixed by LiveCode as the 
only way under Windows (that I have found) to get the equivalent data 
appears to be with the "wmic" command and that requires asking for file 
attributes one file at a time, which means multiple shell calls and that 
slows my work-around down a lot.


Example:
wmic datafile where Name="C:\\Users\\paul\\Desktop\\Unicode 
Study\\peace.docx" get Name,FileSize,CreationDate,LastModified,LastAccessed


Sorry for not responding sooner.


On 8/23/2019 9:48 AM, dsc--- via use-livecode wrote:

Paul, does this solve the problem with shell() on Windows?


On Aug 22, 2019, at 10:27 PM, dsc--- via use-livecode 
 wrote:

I tried it.

on mouseUp
   set the shellCommand to "cmd.exe /u"
   put textDecode( shell("dir"), "UTF-16" )
end mouseUp

That does seem to double up the newlines. It looks like it works otherwise.

Dar



On Aug 22, 2019, at 12:15 PM, dsc--- via use-livecode 
 wrote:

The shellCommand property for Windows is "cmd.exe", not "command.com 
" as described in the dictionary.

I wonder how setting that to "cmd.exe /u" would affect this behavior.





___
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: Unicode is not "everywhere"...

[Paul Dupuis via use-livecode]

On 8/22/2019 8:46 PM, Monte Goulding via use-livecode wrote:

Both of these are anomalies we could only resolve with new syntax I think… at 
lease the urlEncode one is. I’m not sure if the expectation of shell is it 
returns text or binary data… The workaround there would be to open process for 
UTF8 text read instead of using shell... not sure if UTF8 would be right on 
windows… possibly UTF16 there.

Regarding url encoding the anomaly bug is 
https://quality.livecode.com/show_bug.cgi?id=14015 
 so your report should be 
closed as a duplicate of it I suspect.

Probably the simplest way to resolve the detailed files/folders issue is to 
have a new parameter for the files and folders function to return an array. 
Anyone want to suggest a name for the parameter?

Cheers

Monte


I reported what I thought was 3 bugs in 1 report in 
https://quality.livecode.com/show_bug.cgi?id=22213. I have edited that 
report to focus on a single bug - that the detailed files (and probably 
the detailed folders) is broken for Unicode as every Unicode character 
in a file name is encoded as %3F or ?. Originally I had though that 
meant that there was a problem with urlEncode and urlDecode as per bug 
https://quality.livecode.com/show_bug.cgi?id=14015 that your references 
Monte. However, I now consider that urlEncode and urlDecode are NOT 
broken and bug 14015 is really a Documentation bug that the urlEncode 
and urlDecode Dictionary entries should be updated.


If you look at the Wikipedia entry for URL (or percent) encoding, it 
states that the standard practice for non-ASCII character in a URL is to 
encode them as UTF8 BEFORE percent-encoding. There fore, urlDecode and 
urlEncode are working correctly by the accepted standards. The 
Dictionary entries need updating to note that any non-ASCII text should 
be UTF8 encode before urlEncoding and UTF8 decoded after urlDecoding. 
See my DOC bugs:


https://quality.livecode.com/show_bug.cgi?id=22340
and
https://quality.livecode.com/show_bug.cgi?id=22341

I believe these replace bug 
https://quality.livecode.com/show_bug.cgi?id=14015


Also, the detailed files and detailed folders doesn't need an array 
returned (although that would be nice). This issue is the 
percent-encoding is not following the standard convention of UTF8 
encoding non-ASCII characters before percent encoding. LC should follow 
industry conventions in this regard.


___
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: Unicode is not "everywhere"...

[Paul Dupuis via use-livecode]

I just want it consistent and documented and able to return more than 
just ASCII data


Currently, OSX shell returns UTF8 which may mean that it is returning 
binary as it is returning 8-bit bytes where Unicode text has been 
encoded as UTF8


Windows returns CP1252 text, not binary and any Unicode results, which 
DOS displays as Unicode just fine, can be returned without elaborate 
work-arounds.


That by definition is a bug.

I would advocate that shell should return binary data. Text being 
returned should be UTF8 encoded, that way people expecting ASCII do nto 
need to o anything, they can just work with teh returned text. People 
expecting Unicode can use textDecode to get the UTF8 converted to LC 
native 16-bit Unicode, and people extcting binary can use the byte chunk 
to process what comes back however they want.


The current missing part is the UTF8 encoding of text being returned 
under Windows.


Also, as my platforms of concern are Windows and OSX, I have not tested 
shell() under Linux. I assume it behaves like OSX but that is an assumption.



On 8/22/2019 8:36 PM, Dar Scott Consulting via use-livecode wrote:

You can't have it both ways.

Either shell() only characters of the broadest character set, Unicode, or it 
returns binary. If it returns characters, then it will not work for binary 
responses; that will have to be documented as excluded.

If Unicode is returned then textDecode is not needed and even should not be 
used.




On Aug 22, 2019, at 2:08 PM, Richard Gaskin via use-livecode 
 wrote:

Dar Scott wrote:


If the result of shell() is run through textDecode, should then
shell() return binary data? This puts it outside the scope of
"everywhere". I like the idea, as long as simple ASCII characters
work transparently.

Isn't that the goal of UTF-8, which is why so many programming languages uses 
it as the default?

--
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: Unicode is not "everywhere"...

[Paul Dupuis via use-livecode]

On 8/22/2019 4:08 PM, Richard Gaskin via use-livecode wrote:

Dar Scott wrote:

> If the result of shell() is run through textDecode, should then
> shell() return binary data? This puts it outside the scope of
> "everywhere". I like the idea, as long as simple ASCII characters
> work transparently.

Isn't that the goal of UTF-8, which is why so many programming 
languages uses it as the default?




Richard is correct. UTF8 encoding does not change readability of ASCII 
characters.
Encoding the results from shell as UTF8 does mean that ASCII characters 
can be used in a return values without text decoding. shell() under OSX, 
at least tested under LC905rc1, actually returns UTF8 and probably no 
one using shell on OSX has noticed if you've just been working with 
ASCII characters as the output of your shell comamnd.



___
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

Unicode is not "everywhere"...

[Paul Dupuis via use-livecode]

I have filed two bug reports that are in LC905rc1 and go back to 7.0 
where LC functions that should deal with Unicode properly do not.


These are:
https://quality.livecode.com/show_bug.cgi?id=22213 -- The "detailed 
files" function fails for any files with Unicode in the name, returning 
the filename with %3F (?) instead of the Unicode characters properly URL 
encoded (they should be UFT8 encoded and then URL encoded)

and
https://quality.livecode.com/show_bug.cgi?id=22334 -- the shell command 
is not Unicode aware in returning it's results. On OSX, the results are 
UTF8 encoded (discovered by accident) and so an extra step is needed to 
text decode them, but on Windows it is a complete failure and any 
Unicode results of the command line - SHOWN 100% correctly is executed 
in the command line - are returned NATIVE encoded, causing all Unicode 
characters to become question marks.


I have written work-around for both of these bugs that can be found in 
the bug reports. My work-around for the "details files" is slow, due to 
repeated calls to shell to fetch file properties one at a time.


If anyone else out there has run into these bugs in your own code and 
developed a faster work-around for the "detailed files" and would care 
to share, I would welcome a faster fix.


Of course, I'd welcome a fix from LiveCode, Ltd. to these bugs even more!

___
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: "copy files", specialfolderpath("resources") and missing files = SHOWSTOPPER

[Paul Dupuis via use-livecode]

On 8/10/2019 5:03 AM, Klaus major-k via use-livecode wrote:

thank you, yes, I imagined something like this.
But what does get moved and why, and what can I do to make my app run?


We use a "on standaloneSaved pDestFolder" handler and then use 
revCopyFolder or revCopyFile (or whichever other of the rev file/folder 
command is appropriate) to move stuff from where it gets put to where we 
want it.


We've done this for some time both to insulate ourselves against Apple's 
habit of changing where stuff goes and regression errors in LiveCode's 
engine.



___
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: Should the scope of WholeMatches be expanded?

[Paul Dupuis via use-livecode]

On 8/8/2019 5:18 PM, Dr. Hawkins via use-livecode wrote:

On Aug 5, 2019, at 7:43 AM, Paul Dupuis via use-livecode 
 wrote:

I'd like to see wholeMatches apply to:



Gee, that would do just what I need in searches . . . and the check is already 
there, and applies in the IDE search/replace feature . . .

hmmm . . .

set the whole matches to true
repeat while wordOffset(searchText, theSearchStrng) > 0
   put replacmentText into word wordOffset(searchText, theSearchStrng) of 
theSearchString
end repeat




Except in the replacement searching I'd like to do, I am searching and 
replacing phrases bounded by white space (tab, space, non-breaking 
space, line break, etc.) so wordOffset will not work for me.


___
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: How does OSX tell what app to open when you double click a file?

[Paul Dupuis via use-livecode]

On 8/6/2019 10:10 PM, Mark Waddingham via use-livecode wrote:

On 2019-08-06 23:59, Paul Dupuis via use-livecode wrote:

For example, if you drag installed 5 apps, APP1, 2, 3, etc, that all
had a info.plist defintion for a .xyz file extension onto a virgin OSX
system out of the box and then double-clicked a .wyz file, which of
the 5 would open?


I *think* the answer to this question probably lies here:

https://developer.apple.com/library/archive/documentation/Carbon/Conceptual/LaunchServicesConcepts/LSCConcepts/LSCConcepts.html#//apple_ref/doc/uid/TP3999-CH202-TP9 



The sections on 'Application Registration' and 'Preferred 
Applications' are probably the most pertinent - although it isn't 
entirely clear how the two mechanisms co-exist: registration suggests 
the 'most recent' modification time wise app is stored against a file 
kind, but preferred applications suggests that multiple apps are 
stored but the newest CFBundleVersion wise is chosen.


Warmest Regards,

Mark.



Thank you again!

This section of that web page was exactly what I was looking for:


 Preferred Application for a Document

For individual document files (whether specified by a file-system 
reference or a URL with scheme |file|), the criteria are as follows:


1.

   If the user has specified an explicit binding for the document (or
   for the entire document type to which it belongs), the preferred
   application is the one the user has specified.

2.

   If the document has a filename extension (or if one has been
   specified as a parameter to |LSGetApplicationForInfo|), find all
   applications in the Launch Services database that claim to accept
   documents with that extension.

3.

   If the document carries a four-character file type (or if one has
   been specified as a parameter), find all applications that claim to
   accept files of that type.

4.

   If more than one application has been found as a result of steps
   2–3, apply the following criteria in the order shown:

1.

   If the document carries a four-character creator signature (or
   if one has been specified as a parameter), give preference to
   any application that claims to accept documents with that
   signature (typically the application to which the signature
   belongs).

2.

   Give preference to native OS X applications over those that run
   in the Classic emulation environment.

3.

   Give preference to applications residing on the boot volume over
   those residing on other file-system volumes.

4.

   Give preference to applications residing on a local volume over
   those residing on a remote volume.

5.

   If two or more versions of the same application have been found,
   give preference to the one with the latest version number as
   identified by |CFBundleVersion
   
<https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html#//apple_ref/doc/plist/info/CFBundleVersion>|.

If two or more candidate applications remain after all of the foregoing 
criteria have been applied, Launch Services chooses one of the remaining 
applications in an unspecified manner.



___
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

Fwd: Re: How does OSX tell what app to open when you double click a file?

[Paul Dupuis via use-livecode]

Thank you,

This article could allow me to have our OSX app check to see if it is 
the default on startup and change it IF the command line tool "duti" 
used the example was already part of OSX but is an open source that 
would need to also be installed with out app - an additional level of 
overhead I'd rather avoid. However, again thanks as this points me in a 
possible direction of ignoring HOW OSX figure it out by default and 
trying to just tell OSX which app should rule.



On 8/6/2019 4:57 PM, Bob Sneidar via use-livecode wrote:

I found this. Didn't read too deep tho'.

https://www.chainsawonatireswing.com/2012/09/19/changing-default-applications-on-a-mac-using-the-command-line-then-a-shell-script/#find-out-the-current-default-for-an-extension

Bob S


On Aug 6, 2019, at 13:36 , Paul Dupuis via use-livecode 
 wrote:


So we make an OSX desktop app in LiveCode that has several document 
types. We add these to the info.plist file in the App bundle so they 
are defined, with doc icons, extensions, types, etc.


If a user has APPv1 installed that has a plist entry for the file 
extension .myext and then installs APPv2 that also has a plist entry 
for file extension .myext. how does OSX tell what APP to open when a 
user double clicks on document.myext?



I googled and found information on setting default app for document 
types, but not how OSX handles this by default?


In window, it is the App's responsibility to check the Registry for 
its document types and, it it wants to, ask the user if they want 
those document associated with it. Or it is done by the app's 
installer on Windows


I just can't find how OSX does it.


___
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: How does OSX tell what app to open when you double click a file?

[Paul Dupuis via use-livecode]

Actually, this issue is that some of our users keep multiple versions of 
our App installed. In most cases, when the user double clicks a document 
from our app, the MOST RECENTLY INSTALLED version launches, but in some 
cases, and older version launches.


In those instances where an older version launches, the user swears that 
they have never used "Open With" or done anything (that they are aware 
of) to set the default app for our document extension to an older version.


So really, I am just trying to understand how OSX figure out how to 
determine what app to open for a document.


For example, if you drag installed 5 apps, APP1, 2, 3, etc, that all had 
a info.plist defintion for a .xyz file extension onto a virgin OSX 
system out of the box and then double-clicked a .wyz file, which of the 
5 would open?




On 8/6/2019 5:23 PM, Bob Sneidar via use-livecode wrote:

If you are simply trying to open an file with a specific app that may or may 
not be the default, what I use is launch document using the with argument. In 
my Forms Generator app this becomes necessary, because some PDF viewers may not 
be able to edit forms. So I have an interface where the user selects which app 
they want to open fillable forms with, so I can force the issue when the time 
comes.

Bob S
  


On Aug 6, 2019, at 13:57 , Bob Sneidar via use-livecode 
 wrote:

I found this. Didn't read too deep tho'.

https://www.chainsawonatireswing.com/2012/09/19/changing-default-applications-on-a-mac-using-the-command-line-then-a-shell-script/#find-out-the-current-default-for-an-extension

Bob S



On Aug 6, 2019, at 13:36 , Paul Dupuis via use-livecode 
 wrote:

So we make an OSX desktop app in LiveCode that has several document types. We 
add these to the info.plist file in the App bundle so they are defined, with 
doc icons, extensions, types, etc.

If a user has APPv1 installed that has a plist entry for the file extension 
.myext and then installs APPv2 that also has a plist entry for file extension 
.myext. how does OSX tell what APP to open when a user double clicks on 
document.myext?


I googled and found information on setting default app for document types, but 
not how OSX handles this by default?

In window, it is the App's responsibility to check the Registry for its 
document types and, it it wants to, ask the user if they want those document 
associated with it. Or it is done by the app's installer on Windows

I just can't find how OSX does it.


___
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: How does OSX tell what app to open when you double click a file?

[Paul Dupuis via use-livecode]

Thank you,

This article could allow me to have our OSX app check to see if it is 
the default on startup and change it IF the command line tool "duti" 
used the example was already part of OSX but is an open source that 
would need to also be installed with out app - an additional level of 
overhead I'd rather avoid. However, again thanks as this points me in a 
possible direction of ignoring HOW OSX figure it out by default and 
trying to just tell OSX which app should rule.



On 8/6/2019 4:57 PM, Bob Sneidar via use-livecode wrote:

I found this. Didn't read too deep tho'.

https://www.chainsawonatireswing.com/2012/09/19/changing-default-applications-on-a-mac-using-the-command-line-then-a-shell-script/#find-out-the-current-default-for-an-extension

Bob S



On Aug 6, 2019, at 13:36 , Paul Dupuis via use-livecode 
 wrote:

So we make an OSX desktop app in LiveCode that has several document types. We 
add these to the info.plist file in the App bundle so they are defined, with 
doc icons, extensions, types, etc.

If a user has APPv1 installed that has a plist entry for the file extension 
.myext and then installs APPv2 that also has a plist entry for file extension 
.myext. how does OSX tell what APP to open when a user double clicks on 
document.myext?


I googled and found information on setting default app for document types, but 
not how OSX handles this by default?

In window, it is the App's responsibility to check the Registry for its 
document types and, it it wants to, ask the user if they want those document 
associated with it. Or it is done by the app's installer on Windows

I just can't find how OSX does it.


___
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

How does OSX tell what app to open when you double click a file?

[Paul Dupuis via use-livecode]

So we make an OSX desktop app in LiveCode that has several document 
types. We add these to the info.plist file in the App bundle so they are 
defined, with doc icons, extensions, types, etc.


If a user has APPv1 installed that has a plist entry for the file 
extension .myext and then installs APPv2 that also has a plist entry for 
file extension .myext. how does OSX tell what APP to open when a user 
double clicks on document.myext?



I googled and found information on setting default app for document 
types, but not how OSX handles this by default?


In window, it is the App's responsibility to check the Registry for its 
document types and, it it wants to, ask the user if they want those 
document associated with it. Or it is done by the app's installer on Windows


I just can't find how OSX does it.

___
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

SOLVED: Help with an algorithm...

[Paul Dupuis via use-livecode]

On 8/5/2019 11:53 AM, Paul Dupuis via use-livecode wrote:
Today is not my coding day. I have a problem I should be able to 
design a solution for an am struggling. Clearly I am missing "something"


I have 2 lists (LISTNEW and LISTOLD) of the following format:

ParentA
Child 1
Child 2
etc.
ParentB
Child 1
etc.
etc.

The parents are in alphabetical sorted order, the children may not be 
in sorted order


I need to hunt through LISTOLD comparing the LISTOLD Parents to the 
LISTNEW Parents
  FOR any LISTOLD Parent present in LISTNEW, check the Children of the 
matching Parents and add any Child for the LISTOLD Parent that is not 
already under its matching LISTNEW Parent
  FOR any LISTOLD Parent NOT in LISTNEW, I can ignore the Parent and 
its Children


I can not seem to write an approach to solve this today. Does any body 
have some code so solve this they may be willing to share?




Thank you everyone who responded. Apparently, I really just needed a 
nudge, which Craig's first response provided. All replies helped though. 
Routine is now coded, tested, and working correctly.


___
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: Help with an algorithm...

[Paul Dupuis via use-livecode]

I had not considered using arrays. I have no idea why, as it provides a 
mechanism. Just not thinking well today. Thanks for the tip!



On 8/5/2019 1:40 PM, dunbarx--- via use-livecode wrote:

Hi.
This seems like a good case for arrays (pseudo):
You have to create an array for each parent. The only way i see to find those 
is to go through the list looking for lines that DO NOT start with a space. If 
you work from the bottom up, since children are always at the bottom and they 
always have spaces in front, you can find the lastMost parent.
Set the itemDel to that parent, and isolate the last item. This will be a list 
of children of that parent.
See if there is a corresponding parent in the new list, and isolate that "item" 
list of children.
Run through the children of the old list and see if they live in the new list. 
If they do, add them:The array part is something like:
put oldChildren & return & newChildren into allChildrenrepeat for each line 
tLine in allChildrenput tLine into myArray[tLine]

Delete the last item of the old list and do it again. This way the last item 
can be isolated directly.
Craig

-Original Message-
From: Paul Dupuis via use-livecode 
To: How to use LiveCode 
Cc: Paul Dupuis 
Sent: Mon, Aug 5, 2019 11:53 am
Subject: Help with an algorithm...

Today is not my coding day. I have a problem I should be able to design
a solution for an am struggling. Clearly I am missing "something"

I have 2 lists (LISTNEW and LISTOLD) of the following format:

ParentA
Child 1
Child 2
etc.
ParentB
Child 1
etc.
etc.

The parents are in alphabetical sorted order, the children may not be in
sorted order

I need to hunt through LISTOLD comparing the LISTOLD Parents to the
LISTNEW Parents
    FOR any LISTOLD Parent present in LISTNEW, check the Children of the
matching Parents and add any Child for the LISTOLD Parent that is not
already under its matching LISTNEW Parent
    FOR any LISTOLD Parent NOT in LISTNEW, I can ignore the Parent and
its Children

I can not seem to write an approach to solve this today. Does any body
have some code so solve this they may be willing to share?

___
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

Help with an algorithm...

[Paul Dupuis via use-livecode]

Today is not my coding day. I have a problem I should be able to design 
a solution for an am struggling. Clearly I am missing "something"


I have 2 lists (LISTNEW and LISTOLD) of the following format:

ParentA
Child 1
Child 2
etc.
ParentB
Child 1
etc.
etc.

The parents are in alphabetical sorted order, the children may not be in 
sorted order


I need to hunt through LISTOLD comparing the LISTOLD Parents to the 
LISTNEW Parents
  FOR any LISTOLD Parent present in LISTNEW, check the Children of the 
matching Parents and add any Child for the LISTOLD Parent that is not 
already under its matching LISTNEW Parent
  FOR any LISTOLD Parent NOT in LISTNEW, I can ignore the Parent and 
its Children


I can not seem to write an approach to solve this today. Does any body 
have some code so solve this they may be willing to share?


___
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

Should the scope of WholeMatches be expanded?

[Paul Dupuis via use-livecode]

Is it just me or would anyone else like to see the scope of the 
wholeMatches property expanded beyond just wordOffset, itemOffset, and 
lineOffset.


I'd like to see wholeMatches apply to:

Replace
Replace in field
Contains (as in if X contains Y)

With wholeMatches meaning test at white space (space,line break, tab, 
etc.) boundaries for all three of these.


Yes, I know I can do the replace using the replaceText function and regex.

I have a heavily formatted field and would LOVE to use the "new" replace 
... in field preserving styles, but I have to ensure that I only match 
and replace whole strings (bounded by white space/line breaks) and don't 
accidentally replace part of a string.


___
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: "template" stack in custom property

[Paul Dupuis via use-livecode]

On 8/2/2019 10:33 PM, ambassador--- via use-livecode wrote:
What are the advantage of instantiating the new stack from data in a 
prop rather than by cloning a substack?




That was my question too.

It is a very different way of storing a stack.

I imagine that an: open invisible stack (the cSavedStack of stack 
"someOtherStack")

would be like a open invisible URL 
in that it has to be loaded into memory, so it it is not the last line 
of the script, I would expect it should be followed by a "wait 
 with messages" to allow all the new stack messages to fire.


___
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: increasing column width of DG keeps running

[Paul Dupuis via use-livecode]

On 8/1/2019 9:23 AM, JJS via use-livecode wrote:

hi,


anyone ever had this:

Increase the column width of a DG by clicking on the increase button. 
in the property inspector, keep the mouse down until you think the 
column is wide enough.


Then it keeps running --read increasing the width-- forever, or until 
probably the max of 65000 somewhere.


Have this in all versions of LC in win10. But never made a bug report 
yet.


I can only stop this by ending LC in the task manager.

Have you seen this?



I develop under WIn10. Like Bob, I tend to type in numbers for column 
width rather than use the arrow, but I just created a new stack in 
LC905rc1, added a new DataGrid, created 2 columns and tried to resize 
the first column using the property inspector arrows. For Width, 
MinWidth and MaxWidth I could size upa nd down using the arrows without 
it continuing once I released the mouse.


I did see a bug when editing column names. Add a column. Type in the 
Column name. The click on the Column label field of the PI and types a 
label. Press tab, get an error "object does not have that property" and 
the Col # name references as the object. I think the closeField handler 
in the PI for the column name is broken.


I report the bug I found to the Quality Center as 
https://quality.livecode.com/show_bug.cgi?id=22281


___
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

ANSWER: OSX High Sierra and Mojave Double Titlebars or Menubars?

[Paul Dupuis via use-livecode]

This was a tough bug to pin down, but it is a bug in LC901 through 
905rc1 and perhaps earlier with the moveStack handler not always 
redrawing a stack whose position is adjusted by the handler under OSX 
(tested on El Capitan and High Sierra)


Test stack and recipe reproducing the problem posted to the Quality 
Center bug: https://quality.livecode.com/show_bug.cgi?id=22267



On 7/26/2019 12:27 PM, Paul Dupuis via use-livecode wrote:

https://quality.livecode.com/show_bug.cgi?id=22267

We have a screen recording showing the issue (but not what triggered 
it!) that, when I can get it form the QA person who recorded it, I 
will post to the bug report.


In a strange way it is comforting to know some one else is seeing this 
issue too.



On 7/26/2019 11:38 AM, J. Landman Gay via use-livecode wrote:
I don't see the problem either but my client does. She can't work 
with our stacks and we probably shouldn't ship if it's a widespread 
issue. Her symptoms are identical to what you describe.


Please write up a bug report and if I can get more info from her I'll 
add to it. We have a hard deadline in about 3 weeks.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On July 26, 2019 9:16:10 AM Paul Dupuis via use-livecode 
 wrote:



On 7/26/2019 12:17 AM, Trevor DeVore via use-livecode wrote:

On Thu, Jul 25, 2019 at 4:05 PM Paul Dupuis via use-livecode <
use-livecode@lists.runrev.com> wrote:


I recall a recent (last year/this year - I think) bug where under OSX
High Sierra or Mojave you could end up with double titlebars in your
windows or perhaps it was double menubars?

I have spent a big chunk of time searching the Livecode Quality 
Center

and can not find this bug.

Am I delusional, or was there such a bug and if, so can someone 
point me

to it?


This? https://quality.livecode.com/show_bug.cgi?id=20923



Yes, thank you. In LiveCode 905rc1 in Standalones on OSX High Sierra we
are seeing an odd behavior where -- something happens -- and the mouse
position in a window (or a multi-window standalone) is displaced
vertically. When you click or drag, LiveCode thinks - just in the 
window

- that the mouse is about 20-30 px above where it currently is.

If you move the mouse out of the affected window to another window, it
is fine. But if you move it back into the effected window, it is still
displaced. If you move the window (aligned by default just under the
menubar) down by the displacement amount, the displacement goes away.
Move the window back up, the displacement returns.

Restart the app and it goes away -- until it occurs again.

It is not in our code and happen in different windows at different
times. It is definitely an LiveCode bug, but we can not create/discover
a recipe for what triggers the bug. It has been suggested that it might
be related to the double titlebars bug or to a bug where the LiveCode
IDE menubar/pallete cause an similar displacement in the IDE. However,
this is in a standalone.

It's driving us batty since we can't ship our app with this bug and
can't get LiveCode to even consider fixing it until we can produce a
test stack with a recipe to reproduce it!



___
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

Purge a stack from memory

[Paul Dupuis via use-livecode]

I know this comes up again and again, is there some counterpart to 
"revLoadedStacks(application)" that can PURGE a stack from memory?


If you have a stack open, say stack "A" and you open a different stack 
file with a stack called "A", the IDE presents a message about stacks 
with the same name and what do you want to do with essentially "Cancel" 
(opening the new stack) or "Purge" (the old stack without saving) or 
"Save" (the old stack and purge)


What does the IDE do to purge a stack?

I ask as I have the following case:

I have a stack open in the IDE (Call it "A") that uses another stack 
(not a substack), call it "X" as a library stack. That stack needs to 
make a scripted change to another mainstack (call it "B") with a 
substack, also  it "X", with the same name as the library stack (yes, 
the naming could have been better, but these are old stack made by 
different people and renaming stuff would be a real pain in the butt)


I have tried:
stop using stack "X"
set the destroyStack of stack "X" to true
close stack "X"
wait 0 with messages -- give time to close and remove the stack from memory

-- then open the other stack "X"
-- and do what I need

Yet when I try this, I get the IDE message about stacks of the same name.

Any tips on how to positively, absolutely purge a stack from memory?

___
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: OSX High Sierra and Mojave Double Titlebars or Menubars?

[Paul Dupuis via use-livecode]

https://quality.livecode.com/show_bug.cgi?id=22267

We have a screen recording showing the issue (but not what triggered 
it!) that, when I can get it form the QA person who recorded it, I will 
post to the bug report.


In a strange way it is comforting to know some one else is seeing this 
issue too.



On 7/26/2019 11:38 AM, J. Landman Gay via use-livecode wrote:
I don't see the problem either but my client does. She can't work with 
our stacks and we probably shouldn't ship if it's a widespread issue. 
Her symptoms are identical to what you describe.


Please write up a bug report and if I can get more info from her I'll 
add to it. We have a hard deadline in about 3 weeks.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On July 26, 2019 9:16:10 AM Paul Dupuis via use-livecode 
 wrote:



On 7/26/2019 12:17 AM, Trevor DeVore via use-livecode wrote:

On Thu, Jul 25, 2019 at 4:05 PM Paul Dupuis via use-livecode <
use-livecode@lists.runrev.com> wrote:


I recall a recent (last year/this year - I think) bug where under OSX
High Sierra or Mojave you could end up with double titlebars in your
windows or perhaps it was double menubars?

I have spent a big chunk of time searching the Livecode Quality Center
and can not find this bug.

Am I delusional, or was there such a bug and if, so can someone 
point me

to it?


This? https://quality.livecode.com/show_bug.cgi?id=20923



Yes, thank you. In LiveCode 905rc1 in Standalones on OSX High Sierra we
are seeing an odd behavior where -- something happens -- and the mouse
position in a window (or a multi-window standalone) is displaced
vertically. When you click or drag, LiveCode thinks - just in the window
- that the mouse is about 20-30 px above where it currently is.

If you move the mouse out of the affected window to another window, it
is fine. But if you move it back into the effected window, it is still
displaced. If you move the window (aligned by default just under the
menubar) down by the displacement amount, the displacement goes away.
Move the window back up, the displacement returns.

Restart the app and it goes away -- until it occurs again.

It is not in our code and happen in different windows at different
times. It is definitely an LiveCode bug, but we can not create/discover
a recipe for what triggers the bug. It has been suggested that it might
be related to the double titlebars bug or to a bug where the LiveCode
IDE menubar/pallete cause an similar displacement in the IDE. However,
this is in a standalone.

It's driving us batty since we can't ship our app with this bug and
can't get LiveCode to even consider fixing it until we can produce a
test stack with a recipe to reproduce it!



___
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: OSX High Sierra and Mojave Double Titlebars or Menubars?

[Paul Dupuis via use-livecode]

On 7/26/2019 11:22 AM, Trevor DeVore via use-livecode wrote:

On Fri, Jul 26, 2019 at 9:14 AM Paul Dupuis via use-livecode <
use-livecode@lists.runrev.com> wrote:


Yes, thank you. In LiveCode 905rc1 in Standalones on OSX High Sierra we
are seeing an odd behavior where -- something happens -- and the mouse
position in a window (or a multi-window standalone) is displaced
vertically. When you click or drag, LiveCode thinks - just in the window
- that the mouse is about 20-30 px above where it currently is.


Do you know if the window opens up with the vertical displacement issue or
is the user interacting with the window without issue and then the vertical
displacement is somehow triggered?



The windows are open and then the problem is some how triggered. 
Sometime it happens soon after a window is open and sometime much later.




___
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: OSX High Sierra and Mojave Double Titlebars or Menubars?

[Paul Dupuis via use-livecode]

On 7/26/2019 12:17 AM, Trevor DeVore via use-livecode wrote:

On Thu, Jul 25, 2019 at 4:05 PM Paul Dupuis via use-livecode <
use-livecode@lists.runrev.com> wrote:


I recall a recent (last year/this year - I think) bug where under OSX
High Sierra or Mojave you could end up with double titlebars in your
windows or perhaps it was double menubars?

I have spent a big chunk of time searching the Livecode Quality Center
and can not find this bug.

Am I delusional, or was there such a bug and if, so can someone point me
to it?


This? https://quality.livecode.com/show_bug.cgi?id=20923



Yes, thank you. In LiveCode 905rc1 in Standalones on OSX High Sierra we 
are seeing an odd behavior where -- something happens -- and the mouse 
position in a window (or a multi-window standalone) is displaced 
vertically. When you click or drag, LiveCode thinks - just in the window 
- that the mouse is about 20-30 px above where it currently is.


If you move the mouse out of the affected window to another window, it 
is fine. But if you move it back into the effected window, it is still 
displaced. If you move the window (aligned by default just under the 
menubar) down by the displacement amount, the displacement goes away. 
Move the window back up, the displacement returns.


Restart the app and it goes away -- until it occurs again.

It is not in our code and happen in different windows at different 
times. It is definitely an LiveCode bug, but we can not create/discover 
a recipe for what triggers the bug. It has been suggested that it might 
be related to the double titlebars bug or to a bug where the LiveCode 
IDE menubar/pallete cause an similar displacement in the IDE. However, 
this is in a standalone.


It's driving us batty since we can't ship our app with this bug and 
can't get LiveCode to even consider fixing it until we can produce a 
test stack with a recipe to reproduce it!




___
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

OSX High Sierra and Mojave Double Titlebars or Menubars?

[Paul Dupuis via use-livecode]

I recall a recent (last year/this year - I think) bug where under OSX 
High Sierra or Mojave you could end up with double titlebars in your 
windows or perhaps it was double menubars?


I have spent a big chunk of time searching the Livecode Quality Center 
and can not find this bug.


Am I delusional, or was there such a bug and if, so can someone point me 
to it?



___
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

Unicode languages and text selection...

[Paul Dupuis via use-livecode]

In moving a commercial application that allows researchers to perform a 
lot of textual analysis  from LC6.7.11 to LC9.0.x, we have been trying 
to make sure we take advantage of "Unicode Everywhere".


In do in so, we test with text in as many different languages 
(representative of different glyphs/alphabets and sets of Right-To-Left 
(RTL) and LTR languages). We certainly do NOT have staff that know even 
a fraction of the languages. We craft test content using Google 
Translate. In doing this, we have discovered and reported a few long 
standing Unicode related bugs in the current release of LiveCode, some 
going back to LC7.Some examples:


https://quality.livecode.com/show_bug.cgi?id=22249
https://quality.livecode.com/show_bug.cgi?id=22213
https://quality.livecode.com/show_bug.cgi?id=22202

 I trust that all will eventually get fixed, hopefully sooner rather 
than later. We have now seen another oddity that we can not figure out 
if it is an intentional behavior of certain languages in Unicode or a bug.


 In certain languages in fields, Arabic for example, when we select 
portions of the text in a field, certain glyphs and even words seem to 
change. Not knowing the language, we can't be sure. Has anyone else seen 
this odd behavior in any language (seems to appear more in RTL 
languages) and is it a characteristic of Unicode for some languages or 
some sort of bug?


___
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: looking for 3 or 5 testers for my Notarizing stack

[Paul Dupuis via use-livecode]

On 7/22/2019 8:24 AM, Matthias Rebbe via use-livecode wrote:

To test you´ll need to be a member of Apple´s developer program, a valid 
Developer ID Application certificate, an AppleID with 2FA and a app-specific 
password.


What is "2FA"?

___
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: Best Practice with Player object to determine audio or video

[Paul Dupuis via use-livecode]

the mediaTYpes property returns tracks (and the documentation doesn't 
say whether the list is cr delimited or comma delimited, but that is a 
docs issue)


Are you saying that for example if (the mediaTypes of player X contains 
"audio" and not (the mediaTypes of player X contains "video")) is 
definitely an audio only media file? and conversely if (the mediaTypes 
contains "video") it is a video media file?
If not media file has been set for the player, what does "the 
mediaTypes" return (once again, the documentation doesn't say!)


Is this an approach you have coded and used?



On 7/11/2019 1:32 PM, Curry Kenworthy via use-livecode wrote:


Built-in "mediaTypes" property is pretty handy!

Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.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: Accessibility

[Paul Dupuis via use-livecode]

On 7/11/2019 2:41 PM, J. Landman Gay via use-livecode wrote:
Screen readers don't work in LC. How do those of you who support 
accessibility provide that? Is there anything in LC itself that 
supports the ADA act?




This comes up repeatedly on this list.

Any Desktop LC app is compatible with some OS accessibility tools, 
typically screen magnifies as they do not rely of any hooks in the App 
itself. Most all screen readers require in App API hooks. With widgets 
and FFI support, it might be possible now (LC9+) to create a library for 
one or more of the major screen readers There are also some OS provided 
screen reading tools that I have not tested with LC7, 8, or 9, but they 
did not work with LC6 as the UI controls (buttons and field primarily) 
were not OS standard controls, but LC specific.


We get about 1-3 requests per year for screen reading support for our 
app. I'd love to provide support, but the cost (at least in the past) 
develop Externals and integration, if it even had been possible, would 
have bankrupted us. JAWS seems to be the most requested.


If you look into the Widgets route and see any promise of a solution, 
please let me 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: Question about "the screen" property of stacks...

[Paul Dupuis via use-livecode]

Sorry, one more question:

I assume since 'the screen of stack' is calculated dynamically, that in 
a 'on desktopChanged' handler (triggered by a monitor being removed) 
that looking at 'the screen of stack' for a stack on the now-removed 
monitor would give you the closest remaining monitor?



On 7/11/2019 1:08 PM, Mark Waddingham via use-livecode wrote:

On 2019-07-11 17:17, Paul Dupuis via use-livecode wrote:

The screen of stack X returns the number of the monitor (the line
number for the screenRects) that the stack/window is on.



If someone from the mothership can verify, I would be happy to open a
doc bug, update the dictionary, and generate a PR for an update to the
screen property Dictionary entry to clarify these two points.


The engine compares the content rect (not effective!) of the stack to the
working area of each screen and takes the screen with which it shares the
most area (the intersection of the stack's rect and the working area rect
of the screen is a rectangle - and its the area of that which is used).

If the stack's rect has no intersection with any screen working area then
it uses the screen which has the closest center point to the window's 
center

point (by calculating the length of the line between the two points).

Ties are by display index - the primary display is always first, the rest
are in order as given by the OS to LC.

To be completely unambiguous - here is the routine the engine uses (in 
the
case asked, the p_rectangle would be the rect of the stack being 
interrogated):


const MCDisplay *MCUIDC::getnearestdisplay(const MCRectangle& 
p_rectangle)

{
MCDisplay const *t_displays;
uint4 t_display_count;
uint4 t_home;
uint4 t_max_area, t_max_distance;
uint4 t_max_area_index, t_max_distance_index;

t_display_count = MCscreen -> getdisplays(t_displays, false);

t_max_area = 0;
t_max_distance = MAXUINT4;
    t_max_distance_index = 0;
for(uint4 t_display = 0; t_display < t_display_count; ++t_display)
{
    MCRectangle t_workarea;
    t_workarea = t_displays[t_display] . workarea;

    MCRectangle t_intersection;
    uint4 t_area, t_distance;
    t_intersection = MCU_intersect_rect(p_rectangle, t_workarea);
    t_area = t_intersection . width * t_intersection . height;

    uint4 t_dx, t_dy;
    t_dx = (t_workarea . x + t_workarea . width / 2) - 
(p_rectangle . x + p_rectangle . width / 2);
    t_dy = (t_workarea . y + t_workarea . height / 2) - 
(p_rectangle . y + p_rectangle . height / 2);

    t_distance = t_dx * t_dx + t_dy * t_dy;

    if (t_area > t_max_area)
    {
    t_max_area = t_area;
    t_max_area_index = t_display;
    }

    if (t_distance < t_max_distance)
    {
    t_max_distance = t_distance;
    t_max_distance_index = t_display;
    }
}

if (t_max_area == 0)
    t_home = t_max_distance_index;
else
    t_home = t_max_area_index;

return _displays[t_home];
}

[ And yes - I just noticed that 't_max_distance' is a misnomer - it 
should really be

t_min_distance! ]

Hope this helps!

Warmest Regards,

Mark.

P.S. The reason it works without a stack being open is because it is 
an entirely

'logical' operation based on the rect of the stack not effective 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: Question about "the screen" property of stacks...

[Paul Dupuis via use-livecode]

Thank you Mark!

I will create an abbreviated summary for the Dictionary entry.

I can now see why the programmer will get a  screen number for the stack 
even if the stack is not "on" any actually monitor (use loc to screenLoc 
line calculation), which is actually very helpful. Our application has a 
preferences that allows the user to save their window placement between 
sessions and we have to address the issue that a window may have been on 
a monitor that is no longer present the next time our app starts up


We'd thought about just resetting the window to its default position, 
but seeing this, it makes more sense to me to move the window to the 
screen with the closest center.



On 7/11/2019 1:08 PM, Mark Waddingham via use-livecode wrote:

On 2019-07-11 17:17, Paul Dupuis via use-livecode wrote:

The screen of stack X returns the number of the monitor (the line
number for the screenRects) that the stack/window is on.



If someone from the mothership can verify, I would be happy to open a
doc bug, update the dictionary, and generate a PR for an update to the
screen property Dictionary entry to clarify these two points.


The engine compares the content rect (not effective!) of the stack to the
working area of each screen and takes the screen with which it shares the
most area (the intersection of the stack's rect and the working area rect
of the screen is a rectangle - and its the area of that which is used).

If the stack's rect has no intersection with any screen working area then
it uses the screen which has the closest center point to the window's 
center

point (by calculating the length of the line between the two points).

Ties are by display index - the primary display is always first, the rest
are in order as given by the OS to LC.

To be completely unambiguous - here is the routine the engine uses (in 
the
case asked, the p_rectangle would be the rect of the stack being 
interrogated):


const MCDisplay *MCUIDC::getnearestdisplay(const MCRectangle& 
p_rectangle)

{
MCDisplay const *t_displays;
uint4 t_display_count;
uint4 t_home;
uint4 t_max_area, t_max_distance;
uint4 t_max_area_index, t_max_distance_index;

t_display_count = MCscreen -> getdisplays(t_displays, false);

t_max_area = 0;
t_max_distance = MAXUINT4;
    t_max_distance_index = 0;
for(uint4 t_display = 0; t_display < t_display_count; ++t_display)
{
    MCRectangle t_workarea;
    t_workarea = t_displays[t_display] . workarea;

    MCRectangle t_intersection;
    uint4 t_area, t_distance;
    t_intersection = MCU_intersect_rect(p_rectangle, t_workarea);
    t_area = t_intersection . width * t_intersection . height;

    uint4 t_dx, t_dy;
    t_dx = (t_workarea . x + t_workarea . width / 2) - 
(p_rectangle . x + p_rectangle . width / 2);
    t_dy = (t_workarea . y + t_workarea . height / 2) - 
(p_rectangle . y + p_rectangle . height / 2);

    t_distance = t_dx * t_dx + t_dy * t_dy;

    if (t_area > t_max_area)
    {
    t_max_area = t_area;
    t_max_area_index = t_display;
    }

    if (t_distance < t_max_distance)
    {
    t_max_distance = t_distance;
    t_max_distance_index = t_display;
    }
}

if (t_max_area == 0)
    t_home = t_max_distance_index;
else
    t_home = t_max_area_index;

return _displays[t_home];
}

[ And yes - I just noticed that 't_max_distance' is a misnomer - it 
should really be

t_min_distance! ]

Hope this helps!

Warmest Regards,

Mark.

P.S. The reason it works without a stack being open is because it is 
an entirely

'logical' operation based on the rect of the stack not effective 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: Question about "the screen" property of stacks...

[Paul Dupuis via use-livecode]

But is the number accurate?

If so, I presume it is just comparing the saved loc of the stack to the 
screenRects, but what if the saved loc is not in any of the screenRects, 
then what does 'the screen of stack' return? 1 by default? or something 
else?


I could, of course, but a second monitor, and create a test stack to 
determine all this, but some one at LiveCode should know (or be able to 
tell from the code) and then, as I said, I will add it to the Dictionary 
entry.



On 7/11/2019 11:25 AM, Bob Sneidar via use-livecode wrote:

Curiously, it also returns the screen number for stacks that are not open.

Bob S



On Jul 11, 2019, at 08:17 , Paul Dupuis via use-livecode 
 wrote:

The screen of stack X returns the number of the monitor (the line number for 
the screenRects) that the stack/window is on.

How exactly is this determined? I presume it is based on the loc (location) 
property of the stack, since the window (effective rect or rect) itself can 
span multiple monitors, but the loc of a stack, being a point, must be one only 
a single monitor.

However, if someone with applicable knowledge could confirm that it would be 
appreciated. The Dictionary does not clarify how the screen is determined.

It would also help if someone could confirm that the screen value is 
meaningless until the stack/window is opened (much like that the effective rect 
is meaningless until a stack is opened)?

If someone from the mothership can verify, I would be happy to open a doc bug, 
update the dictionary, and generate a PR for an update to the screen property 
Dictionary entry to clarify these two points.


___
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

Best Practice with Player object to determine audio or video

[Paul Dupuis via use-livecode]

I'm looking for the best way (code), cross platform, to determine if the 
media a user selected for a player object is audio (only) or a video.


I am surprised there is not some inherent player property to get this 
information. I am using an approach that looks at the formattedHeight 
(with audio media that should just be the height of the controller), but 
is there some better approach. What if, for some strange reason someone 
loads a 2px high video? There isn't a way to get the controler height 
exactly and I think it is slightly different between OSX and Windows 
(and I have not checked Linux or any other platform)


This is our current code:

getProp mediaType -- returns whether a player is showing audio, video, 
or none

   put 40 into maxControllerHeight -- magic number
   --
   if word 1 of the name of the target is not "player" then return empty
   --
   if the filename of the target is empty OR there is no file (the 
filename of the target) then return "none" -- player not loaded
   if the formattedHeight of the target <= maxControllerHeight then 
return "audio" else return "video"

end mediaType

However, the "40" figure bother me because it doesn't come from LiveCode 
itself. What if with LC10, the Mothership revised the controller and its 
now 41px high and the code breaks. Anyone have a better way?


___
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