Re: Unicode mysteries

[Neville Smythe via use-livecode]

> 
>> Which should correspond to codepoints
>>   1F3F4 E0067 E0062 E0073 E0063 E0074 E007F
>> And indeed if I manually build a UTF-16 string with these code points
>> it does display as the flag of Scotland. So the lesson is that the
>> reported chunks are not to be naively trusted  --- tho not exactly a
>> bug given the documentation warning.
> 
> Well this would be a bug! If you try codepoint 1..14 - then you will see 
> that they alternate between a codepoint and zero - the codepoints appear 
> to correspond to the relevant surrogate pair codeunits. i.e. codepoint 
> is misinterpreting the index as a codeunit index, rather than a 
> codepoint index :|
> 
> If you file a bug then I suspect this can be fixed quite quickly (famous 
> last words of course!).


Thanks Mark, I will file a bug report.

I don’t *really* need the actual font the system uses to display unsupported 
codepoints. I was thinking of using it as a lazy way to find out which single 
codepoints are supported rather than having to parse the cmap tables in the 
font file. As a way of learning about unicode I was trying to writing an LC 
version of the character map/PopChar utilities; a project doomed to failure 
because it’s just too hard to find out which multi-codepoint glyphs are 
supported by a font. This is a question frequently asked on forums, but it 
seems there is no answer other than reverse engineering the morx table in the 
fontfile, which is way too complex to be worth the effort. There is a published 
list for Emoji fonts but that would not be possible for general ligatures or 
glyph variations presumably.

Any comment on the LC behaviour of treating the Rainbow flag (which is a 
multi-codepoint glyph composed of three characters)
as 3 separate text characters, requiring 3 backspace operations to delete it in 
a field, rather than a single backspace as works in TextEdit?  [The first 
backspace eliminates the rainbow flag glyph but leaves the white flag showing; 
the second backspace eliminates the invisible join codepoint, so to the user 
seems to do nothing; the third backspaced finally eliminates the last glyph.]  
Is this a design choice or a bug?

Bob: I am looking at the Digest, where nonstandard characters (even, 
annoyingly, quotes) are replaced by question marks, which makes code snippets 
very hard to read. Is there a setting I should change to fix this?

Neville
___
use-livecode mailing list
use-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 mysteries

[Neville Smythe via use-livecode]

I have filed a bug report  bug_22561 
  re the misreporting of 
codepoints for unicode characters.

I am pretty convinced the treatment of the Rainbow flag emoji as three separate 
characters should be treated as incorrect behaviour and therefore a bug, I 
think the problem is that the vertical join codepoint 200D is not being treated 
as a codepoint within a character rather than starting a new character (while 
the glyph variation codepoints FE00-FE0F and the Variation Selectors E01xx are 
correctly interpreted).

 It is interesting to  see how the “transgender flag”, which is a new emoji not 
yet implemented in the Apple Color Emoji font but is supported by Google and 
Facebook, is displayed in various apps: in LC it appears as 4 glyphs (if the 
Gnu Unicode font is installed) but 3 separate characters; in BBedit it shows as 
2 glyphs, in Pages as 4 glyphs but in both these case as a single character 
(delete char 1 or backspace eliminates the whole thing, you cannot place a text 
insertion between the glyphs).

One final LC bug. A number of Apple Color Emoji font characters, in particular 
the digits 1,2..0 are clipped at the top when shown in text size larger than 9. 
This is true with Fixed Line Height turned off - LC doesn’t adjust the lines 
for the extra ascent for some reason, and I don’t know of any other text 
setting we have in LC to fix the problem(?) Other apps show the characters 
correctly so it is not a design flaw in the font.

Neville



___
use-livecode mailing list
use-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: Mobile Wondering

[Neville Smythe via use-livecode]

I had been wondering when the third-class status of mobile platforms in the LC 
world, particularly in relation to scrolling fields and groups, would crop up 
here.

Some time ago I looked at converting an iOS project to LC, and was appalled at 
the crude 1984-style appearance of scroll bars. I presume they look that way to 
inhibit their use, since the scrolling idiom on mobile platforms iOS is quite 
different from the desktop. But I reckon the native-scroller thingy which you 
had to use in its place seemed an awful hack:  its appearance in a different 
layer meant other objects got overwritten in a completely unacceptable way (has 
that changed?); and the separation of the testing regime from the IDE turned 
back the clock on the development process, again to 1984 when you developed on 
the Lisa, tested on the Mac. (Yes, I was there!)

So I developed a custom scrollbar which worked on both desktop and iOS. It is 
doable, with a modicum of fiddly stuff.
You need

1. An installer stack or widget. When you drag a scrollbar template onto a 
field (or group), it registers the field id with the scrollbar, snaps the 
scrollbar to fit the field dimensions with the desired vertical or horizontal 
orientation, and adjusts the thumb to match the field content. It also installs 
a backscript and frontscript in the stack.  

2. The front script captures mouse events/ drag touch gestures intended for the 
field, filters for scrolling events and diverts those to the appropriate custom 
scrollbar.  For 2-dimensional scrolling I used two separate scrollbars which 
needed some cross-mediation of gesture directions; a combined double-scrollbar 
would have been better. 

3. The backscript catches changes to the field affecting content, position or 
dimensions which need to be reflected in the scrollbars.

I had it working pretty well, to the point of a mostly complete examples / 
installer stack . You can customise all sorts of things, such as the appearance 
of the thumb and scrollbar background, whether the thumb length should reflect 
field content proportionally or not, visible-on-demand or as-needed or hidden 
thumb, the number of thumb positions - for example you could have a stepper 
with just 5 positions and a custom image as thumb - and even have left side or 
top mounted scrollbars. You could even have a desktop look and feel if you 
wanted, and why not if Apple can flout their own UI guidelines?

The  iOS project lapsed, running the maze of Apple distribution requirements 
became discouraging and I lost interest. But it can be done.

Neville
___
use-livecode mailing list
use-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: Go to card has become slow

[Neville Smythe via use-livecode]

Richard wrote 

> Bob Sneidar wrote:
> 
>> In review, I tested saving stacks on a standalone Windows Workstation,
>> a VMWARE VM on a very robust server host, a Parallels VM on a
>> workstation and my Mac. As I am saving the stack, I am watching the
>> folder the stack is in. I see the tilde version pop up and go away. On
>> Mac it?s almost instantaneous. On Windows it can be 3 to 4 seconds.
> 
> My messages don't seem to be getting through, because each time this 
> observation method of measuring write throughput comes up I post the 
> same reply, yet it keeps coming up.  Please confirm if you can see this:

Yes we see this. But as you know in 2018 I reported this slow saving of stacks 
under Windows10, using LC timing of just the save handler rather than the 
visual perception of the screen update, and it has been confirmed as a bug.  
bug 21305  The time to save 
is extreme for large stacks. It took some time for QualityControl to confirm, 
because apparently  it doesn’t seem happen on every Windows 10 installation - 
just every one  that I or my users have tried. It has not been fixed since 
2018. 

Regards

Neville
___
use-livecode mailing list
use-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: Go to card has become slow

[Neville Smythe via use-livecode]

Richard

Here is a link to the test stack for testing the speed of save stack

https://www.dropbox.com/sh/cb2r9jbohxqv6bp/AAAQ1weLLlzrKYQ21yn1apf9a?dl=0

I don’t know why the test stacks I supplied disappeared from the QC bug report.

You need the SlowSave.livecode and the data.livecode stacks. They are both 
small, but SlowSave creates a large stack with 300 cards and the lorem ipsum 
text data to build an 8 MB stack, and displays the timing for saving. On my 
MacBook Air it takes 0.13 seconds to save; on Windows 10 installations I have 
seen times from 3 seconds to 10 seconds.

In this test, the stack has just 300 cards, 1 field on each, and lots of ascii 
text (so there should be no problems converting to utf-8 before saving in the 
unlikely event that is happening, and in any case would happen on all 
platforms). I haven’t tested stacks with large numbers of controls or large 
images rather than large text data.

Other apps on Windows 10 certainly don’t display this behaviour, which  
indicates it is a LC problem not a Windows problem. Antivirus software and 
Defender were off during the test. I was under the impression that saving files 
from LC, rather than stacks, was not slower than normal, but Bob’s recently 
experience with saving data to a database may contradict that.

Some people have had trouble verifying my observations (other LC Forum users 
have confirmed). QC originally could not confirm the bug until they tried it 
“on an older PC”. However one of my users recently updated to a *very* fast HP 
box; it cut the save time down significantly but was still at least 20 times 
slower than on a typical Mac, ie almost usable. So maybe it has something to do 
with the Windows installation, though the ones I used were stock standard. I 
can’t see how fonts could be involved, for example. 

Neville
___
use-livecode mailing list
use-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: Go to card has become slow

[Neville Smythe via use-livecode]

Richard:

OK, so my impression, that LC saving a (binary) file on Windows 10 is not the 
problem, is correct, as you deduce it lies in the serialisation of the stack.

Now why would that be platform, indeed OS, dependent? Could the LC 
cache/virtual memory settings be different for Windows 10 from those for MacOS 
or Linux? But if that were the case you would expect to see a slow down in 
other parts of LC, such as perhaps script editing in the IDE, and that doesn’t 
happen, does it (!!)

Neville
___
use-livecode mailing list
use-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: Go to card has become slow

[Neville Smythe via use-livecode]

I have updated the SlowSave test stack with Richard's enhancement to also show 
the time to save the binary data (no need to use the shift button)

https://www.dropbox.com/sh/cb2r9jbohxqv6bp/AAAQ1weLLlzrKYQ21yn1apf9a?dl=0

Pleased to see everyone is seeing the problem at last, it doesn’t seem to be 
related to the particular Windows 10 installation. But 38 seconds for 8 MB!! 

Neville
___
use-livecode mailing list
use-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: Go to card has become slow

[Neville Smythe via use-livecode]

> On 11 Apr 2020, at 2:00 am, Brian Milby wrote
> 
> I just imported a 500kb image to the card, removed the text from the field,
> created 300 cards.
> 0.756 seconds normal (171MB).  1.124 from a variable. (image instead of
> text)
> 8.311 seconds normal (8.2MB).  0.047 from a variable.  (original text)
> 
> I'll need to clean this up with a better image (something I can share) and
> try on my Mac for comparison when I get off today, but this points squarely
> at the serialization of the field object being the difference.

I am intrigued by the fact that save stack (for a stack with on-disk file size 
171MB) took *less* time than saving its binary data representation. Doesn’t 
that mean that the images were already on disk, and the in-memory stack was 
very much smaller than 171 MB, containing only image references. In which case 
I’m not sure we are comparing like with like, as compared with the text version 
(unless "save stack as newStackFile" might be give more comparable info?).

My hunch is that Richard’s point about the Windows write-to-file overhead is 
still the key, not the serialisation. One would to need to compare the number 
of writes used by the engine for the two stack versions. That I do not know how 
to do , but I think the incomparable Brian could do it!

Neville
___
use-livecode mailing list
use-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: Go to card has become slow

[Neville Smythe via use-livecode]

Sorry Brian, I uploaded from the wrong folder. Here is the update test set. But 
the only difference is that you don’t need to hold down the shift key to see 
the binary save timing.

https://www.dropbox.com/sh/cb2r9jbohxqv6bp/AAAQ1weLLlzrKYQ21yn1apf9a?dl=0 


Colin, the test set here shows the timing of saving of stacks; the times for 
Windows 10 are a large multiple of Mac/Unix and we discussing possible reasons 
before updating the bug report  bug 21305 
  for Quality Control

Neville
___
use-livecode mailing list
use-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: Go to card has become slow

[Neville Smythe via use-livecode]

Mark Waddingham wrote
> There appear to be two reasons for the difference:
> 
>   1) When saving each style run (block) in a field the engine is making 
> three Win32 API calls.
> 
>   2) The saving method uses (and always has used) direct Win32 system 
> calls to manipulate files without any buffering (on other platforms we 
> wrap the standard C library stdio FILE which has its own buffer).


Wonderful Mark!

I hadn’t really flagged the fact that I was using styled test in my test set. 
Given your comment that seemed to point to styled text being the bottleneck I 
tweaked my test stack to give the option of plain text. It is available at

https://www.dropbox.com/sh/kgc7u7xpqu63hef/AAAdblOyIcx8SIuurB_QfHyHa?dl=0 


But no, it shaved only 1 second off a 7 second save for styled text (elderly 
MacPro running Windows 10 VM) So your engine modifications must be having a 
much wider effect, not just on reducing the 3 API calls for styled as opposed 
to plain text ??

I hope so because the actual problem in the production stack was large numbers 
of table fields, not styled text. I only used ordinary text fields in the 
sample stack I submitted to QC in order to simplify and isolate the problem. 
Will we get a speed-up for table fields (and DataGrids) when it rolls out?

Neville
___
use-livecode mailing list
use-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: Go to card has become slow

[Neville Smythe via use-livecode]

Mark Waddingham wrote
> Each paragraph has at least one style run - even if no styles are 
> applied so this is a general thing.
> 
> Most of the text in your generated test (data) stack was unstyled anyway 
> (as it uses 'the text of' to replicate the data) so minimizing those API 
> calls should affect all stacks with a reasonable amount of field data in 
> them.

Ah, my bad. I have updated the SlowSaveWithStyle test stack.

So table fields and datagrids  will indeed be affected. Excellent!

Neville

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

DataGrid table DeleteIndex

[Neville Smythe via use-livecode]

Am I doing something wrong? 

I put a comma delimited list into tIndexes, then dispatch DeleteIndex to my 
DataGrid with tIndexes. Only the first index in my list is actually deleted. LC 
9.5.1, Mac Catalina.

[Also, If I perform another action in the same handler as the call to delete 
indexes (indices please)  which modifies the content of the datagrid, it leaves 
the datagrid in a very strange state, which can only be recovered by hitting 
the Refresh DataGrid in its Property Inspector. Something to do with the timing 
of the row deletion not having completed I suspect, but that is another matter 
and may be my code. Hmm, does DataGrid use threads??]

Neville
___
use-livecode mailing list
use-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: DataGrid table DeleteIndex

[Neville Smythe via use-livecode]

BobS wrote

> Did you try the plural form of deleteIndex(es)? 

Well you see I read the documentation. Which says “DeleteIndexes” is a synonym 
of “DeleteIndex”. So I didn’t try it (didn’t try “DeleteIndices” either). 
Thanks Bob, that does work! So the documentation is wrong. There is no separate 
entry for DeleteIndexes.

> The data grid does not use threads. Nothing in LC does.

I know LC doesn’t but I thought it just possible that DataGrid uses a C 
external which employs threads. Clutching at straws of course.

Neville


___
use-livecode mailing list
use-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 and Apple mail

[Neville Smythe via use-livecode]

Graham: before updating to Catalina definitely make a back of everything. When 
I updated I lost 35000 emails. Not just that they weren't loaded  by Mail, they 
were actually deleted from the computer. That said, that was some months ago, 
and Catalina has since solved that problem - reportedly; I have certainly had 
no problems since recent OS updates. Also it is safest to do a clean instal if 
you can rather an update from Mojave or whatever.

The experience was quite nasty. But in the process of using some LC code to 
recover my emails from a backup [BTW TimeMachine wouldn’t do the recovery 
automatically] I learnt a huge amount about mailbox structures and sqlite 
databases and found thousands of duplicate emails.

Neville

> On 18 May 2020, at 2:00 am, use-livecode-requ...@lists.runrev.com wrote:
> 
> Send use-livecode mailing list submissions to
>   use-livecode@lists.runrev.com
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   http://lists.runrev.com/mailman/listinfo/use-livecode
> or, via email, send a message with subject or body 'help' to
>   use-livecode-requ...@lists.runrev.com
> 
> You can reach the person managing the list at
>   use-livecode-ow...@lists.runrev.com
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of use-livecode digest..."
> 
> 
> you can find the archives for this list at:
> 
> http://lists.runrev.com/pipermail/use-livecode/
> 
> and search them using this link:
> 
> http://www.google.com/advanced_search?q=site:lists.runrev.com
> 
> 
> Today's Topics:
> 
>   1. Re: Apps to fight COVID-19 (Dar Scott Consulting)
>   2. Re: Sad truth about iOS apps (kee nethery)
>   3. Re: Sad truth about iOS apps (Graham Samuel)
> 
> 
> --
> 
> Message: 1
> Date: Sat, 16 May 2020 11:30:39 -0600
> From: Dar Scott Consulting 
> To: How to use LiveCode 
> Subject: Re: Apps to fight COVID-19
> Message-ID: <0e24ee6e-635f-4835-a635-14fb51258...@swcp.com>
> Content-Type: text/plain; charset=us-ascii
> 
> Covid Watch (where I'm working) is decentralized. (of course) 
> 
>> On May 14, 2020, at 10:35 AM, Mark Wieder via use-livecode 
>>  wrote:
>> 
>> Updated news: Germany steps up to the plate
>> 
>> https://www.bbc.com/news/technology-52650576
>> https://github.com/corona-warn-app/cwa-documentation
>> 
>> -- 
>> Mark Wieder
>> ahsoftw...@gmail.com
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> 
> 
> --
> 
> Message: 2
> Date: Sat, 16 May 2020 15:01:32 -0700
> From: kee nethery 
> To: How to use LiveCode 
> Subject: Re: Sad truth about iOS apps
> Message-ID: <6d75b644-1acf-4279-a960-840585638...@elloco.com>
> Content-Type: text/plain; charset=utf-8
> 
> Replaced or just deleted any 32 bit apps I had. Opened files in 32 bit apps 
> and converted them into something else, typically Text or PDF. Lots of files 
> I printed to PDF and stored the PDF versions. 
> 
> Bought some software to open MacDraw files and save them as PDF.
> 
> I had some WriteNow files that I had to move to a really old laptop, print to 
> PDF, and then move back. 
> 
> All in all, I?m pretty sure that every file I now have can be viewed under 
> Catalina. And thus, I have migrated to Catalina. It took a bunch of time, but 
> hey, have lots of time right now.
> 
> Kee
> 
>> On May 16, 2020, at 6:40 AM, Rick Harrison via use-livecode 
>>  wrote:
>> 
>> For those who upgrade to Catalina, remember you will lose any 32 bit apps
>> as Apple has forced everyone to move to 64 bit apps.
>> 
>> Good luck!
>> 
>> Rick
>> 
>>> On May 16, 2020, at 5:42 AM, Erik Beugelaar via use-livecode 
>>>  wrote:
>>> 
>>> Update: You can direclty upgrade from High Sierra to Catalina using the 
>>> macOS Catalina Patcher.
>>> Be sure that High Sierra is up-to-date and using APFS (new Apple File 
>>> System) instead of HFS+.
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> 
> 
> --
> 
> Message: 3
> Date: Sun, 17 May 2020 09:31:53 +0200
> From: Graham Samuel 
> To: How to use LiveCode 
> Subject: Re: Sad truth about iOS apps
> Message-ID: <23f7cb91-5af3-47a7-bbc7-8243fcabf...@mac.com>
> Content-Type: text/plain; charset=utf-8
> 
> There is a consistent tale (more than a rumour, I think) that Catalina can 
> mess up some people's mail messages, if you use Apple Mail. Did that affect 
> you? It?s the thing about Catalina that scares me most - after all, we?ve had 
> lots of warning about 32 bit apps

Modal stacks cpu usage

[Neville Smythe via use-livecode]

I have just noticed something curious. 

I am running LiveCode 8.1 IDE 9.6.1 on a Mac Air 2020 quad core Catalina.  

Typically LC cpu usage shows about 34%  (presumably of 1 core).  When a modal 
stack is opened it immediately ramps up to 99% ; the fan kicks in, and if left 
for a while the OS boosts the kernel_task daemon which I have been told is a 
protection device to prevent overheating. This has the effect of very markedly 
slowing down all apps as they get less cpu time.

If the stack is opened in non-modal mode, cpu usage stays around 34% . I don’t 
understand why a modal stack should be a cpu hog, indeed it seems like a bug to 
me. 

I have a suspicion the wait with messages command  may have the same effect on 
cpu performance, so it could be the culprit.





___
use-livecode mailing list
use-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: Modal stacks cpu usage

[Neville Smythe via use-livecode]

> Confirmed here on macOS 10.14.5.  The CPU load is indeed quite dramatic 
> with modal dialogs.
> 
> I also checked on Linux (Ubuntu 18.04), and LC does not exhibit the 
> problem there.


Thanks Richard for confirming, and testing on Linux. Yes I will file a bug 
report.

It occurred to me that LC shouldn’t be using as much as 34% cpu when it is just 
idling anyway, even when not running a modal stack. Testing just now shows that 
is down to around 16%; of course LC’s time share will depend on lots of OS 
factors and other running apps, but that’s still way too high for an app 
supposedly doing nothing but waiting for events. Turning off the Rinaldi 
revSmartSave plugin brings it down to between 4 and 7%, which is more 
reasonable; presumably something to do with displaying its progress bar, 
perhaps another wait side effect.

Neville Smythe
___
use-livecode mailing list
use-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: Modal stacks cpu usage

[Neville Smythe via use-livecode]

Looks like Elanor beat me to it Bug 22929 
 

Neville Smythe
___
use-livecode mailing list
use-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: Modal stacks cpu usage

[Neville Smythe via use-livecode]

Jacque wrote
> If the Project Browser is open, try closing it. On my Mac, the CPU usage 
> while idle is usually close to 0 when in the background.

Interesting. I would indeed have expected a good-citizen app doing nothing in 
the background to use less than 1% cpu: Mail, Safari. Finder, BBEdit, Keyboard 
Maestro are currently all close to 0% But I never see LC using less than 4.3% 
with no user stacks open, no palettes, no plugins, no scripts, just the IDE. 
Adding revSmartSave brings it up to 15%. The only odd thing about the process I 
can see is the unusually high number of “idle wake ups”, sometimes over 100 in 
the Activity Monitor sampling period: no other process excepting kernel_task 
has anything like this number.

Of course it’s a mug’s game — if that is a phrase in your neck of the woods— 
trying to second guess OS time-sharing parameters, but it does look like LC is 
not a very nice (pun intended) citizen at least in this configuration: Catalina 
10.15.6, Mac Air 2020 quad core, LC 9.6.1 Community! 

Neville





___
use-livecode mailing list
use-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: SSL cPanel mySql setup

[Neville Smythe via use-livecode]

Thanks to this thread for the realisation my remote db connections are not 
secure. I just checked with Dreamhost and they gave their reasons for not use 
SSL with their mySQL setup — unacceptable burden on their server and 
undesirable for web app access; so in their opinion very few shared host 
environments would enable SSL for mySQL.

So I need some middleware. LC Server would have been ideal, but Dreamhost no 
longer install it ;-(. I particularly could have used LC Server to drive 
mailman distribution list subscription/unsubscription tasks from the database 
for which I do not have a good solution at the moment.

Neville



___
use-livecode mailing list
use-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: SSL cPanel mySql setup

[Neville Smythe via use-livecode]

> On 19 Oct 2020, at 3:00 am, use-livecode-requ...@lists.runrev.com wrote:
> 
> Dreamhost never did install LC ... but several of us have made it work.
> Just get the right server executable and permissions.
> I could never get it work account wide but it rocked for individual web
> site installation.

Ah. I got the distinct impression I would need a dedicated server account on 
DreamHost, not a shared environment, to instal LC Server; for this user’s site 
that would not be worth the cost.

To quote the reply from DreamHost:
-
Unfornately we no longer support LiveCode server on our servers at this
time. Looks like current install steps require root/admin access to some
apache config files, which is not something we allow on our managed
server types. 

You could install that on a Dedicated server, or DreamCompute instance if
you wish to, but that would be something you or your developers would
want to do using root on that service. 
-
___
use-livecode mailing list
use-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: SSL cPanel mySql setup

[Neville Smythe via use-livecode]

> I'm not sure what that DH rep is going on about, because the same set of 
> LC Lessons that describe how to set it up via Apache config also include 
> one on setting it up via .htacces on shared hosts.

Many thanks Richard

I will give it a go.

I was once told by a DreamHost support guy that they didn’t use use Mailman for 
their mail distribution lists. So not too surprising.

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

Decrypt problem on Windows

[Neville Smythe via use-livecode]

I am getting a difference in the results from decryption of a variable (stored 
in a stack custom property) between Mac and Windows 10.

The script is

decrypt  using "aes-256-cbc" with password  

On the Mac this decrypts < myEncryptedStr > to its original value

On Windows it gives an empty value, with the result returning “SSL error: Bad 
encrypt”

Could this be a difference in versions between the OpenSSL library built in to  
OSX 10.15.7 and the LiveCode SSL  inclusion for Windows? Or  would a different 
cipher work on both platforms, or perhaps provision of the bit value make it 
work? Or - surely not - do I have to use different encrypted custom properties 
for each platform? 

[I had just recovered strength  from fighting the gratuitously different syntax 
that Windows uses in its implementation of cURL to hit this problem] 


Neville Smythe


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

Rer: Decrypt problem on Windows

[Neville Smythe via use-livecode]

The problem is platform-symmetric. That is, a string encrypted in LC on Windows 
will not decrypt on the Mac. Linux will not decrypt a string encrypted on the 
Mac, and presumably vice-versa.

I did toy with the idea that the encryption keys might be device dependent, 
maybe the public and private keys created by the OpenSSL library were being 
stored in the OS somewhere. But no, a string encrypted on one Mac decrypts 
correctly on a different Mac. So my guess is that the keys are being stored by 
the different platform libraries within LC but not in a place known to the 
library for another platform.

I believe this is a bug, that is to say, it is not what is intended; surely one 
should be able to store an encrypted string in an LC stack, and then any user 
with the password should be able to decrypt it. 

A workaround is to store a different encrypted string in the standalone 
compiled for each platform — but to do that you need to run LC on each 
platform, not exactly in the spirit of LC! Or not to use SSL encryption; I 
would assume all of the other ciphers available in OpenSSL would behave the 
same way.

BTW thanks Mark for the suggestion about htppie, it does look cleaner and 
easier than curl. The disadvantage in my case is it would need to be installed 
in each user’s system.

Neville Smythe



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

Rer: Decrypt problem on Windows solved

[Neville Smythe via use-livecode]

> Could you try to textEncode the encrypted data before saving it in the
> custom property, and then, in the other platform, textDecode it before
> decrypting it?

Many thanks Panos, yes, that fixed the problem.

It never occurred to me that reading binary data from the custom properties of 
a stack should be treated with same caveat as downloading from an external 
source. Todays “learnings” (horrible newly fashionable word).

Neville Smythe



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

Secure connection to server

[Neville Smythe via use-livecode]

A little while ago in this forum we were alerted to the fact that LC direct 
connection to a remote database not using SSL was a security hole. This also 
applies to managing Mailman lists on a remote server.

After a steep (re-)learning curve with the various technologies, I now have a 
working method in place for both mysql and Mailman connections, using php as 
middleware and posting via curl in a shell script. But it is sooo slooow.

Direct connection downloaded an sql query in a fraction of a second. It now 
takes over a second. This is acceptable (barely) for an isolated call,  but I 
sometimes need to make a sequence of posts. As I understand it, the slowness is 
due to the time required to establish the secure connection, not an LC problem. 
For example establishing an ssh connection in Terminal is even slower; but once 
established an ssh session is super fast. Similarly curl will reuse 
authentication credentials within a shell session, so I aggregate as many calls 
as I can with a single shell script before using shell(myscript), and this 
definitely helps.

What I would like to do however is use LC server as the middleware: I could 
then process the required data on the server side; I could not contemplate 
using php to do this. I suspect the LC post command uses curl under the hood, 
but I also suspect each post call would create its own session. I don’t think 
it is possible to establish a single session to talk sequentially to lcserver; 
if so this would be too slow. Am I correct? 

Actually I guess I could  just use my present method using curl and shell() 
instead of post, but addressed to an .lc script instead of .php?

Or is there a whole better way to do what I want? 

Neville Smythe



___
use-livecode mailing list
use-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: Secure connection to server

[Neville Smythe via use-livecode]

I have now moved all my code from php to LiveCode server as the middle-ware.

Firstly it appears that the LiveCode post operation does reuse authentication 
credentials to an https connection as long as calls are made within a single 
script. In my case the first call typically takes slightly more than 1 second, 
subsequent calls in the same script take under half a second.

This is still not adequate to conduct a conversation with the remote database, 
as was possible when connecting directly, but at least in my case I can get 
away with just two calls from clients to server: first “tell me the current 
status of all this stuff”, second “please update the db using this stuff”. It 
means packing and unpacking “stuff” into large files at each end, but LC is so 
easy and efficient at text processing that was not difficult. Indeed as usual 
with refactoring, I found a number of code improvements.

The remaining really slow operation involves managing the mail distribution 
lists. DreamHost is still using Mailman 2.x, so that the only way to get the 
current list of subscribers is to scrape the admin web pages. There is a well 
known subscriberlist.py python script to do this but it is painfully slow. When 
used directly (insecurely) from the client, this took 10 seconds or so to 
gather 175 subscribers. Transferring this to the server side with lc 
authentication in-between, it now takes 14 to 15 seconds; I’m not sure why it 
is more that 2 seconds slower but it is what it is. I have rewritten this as an 
lc script, which shaves a couple of seconds off; to be fair the python script 
is doing rather more than my lc script as it is much more generic. And on the 
other hand I can understand what my script is doing, whereas the python script 
is rather opaque (to me).

So overall I am very happy with LC server. And I have a new toy to play with 
for the New Year.

Neville

> On 16 Dec 2020, at 11:32 am, Neville Smythe  
> wrote:
> 
> A little while ago in this forum we were alerted to the fact that LC direct 
> connection to a remote database not using SSL was a security hole. This also 
> applies to managing Mailman lists on a remote server.
> 
> After a steep (re-)learning curve with the various technologies, I now have a 
> working method in place for both mysql and Mailman connections, using php as 
> middleware and posting via curl in a shell script. But it is sooo slooow.
> 
> Direct connection downloaded an sql query in a fraction of a second. It now 
> takes over a second. This is acceptable (barely) for an isolated call,  but I 
> sometimes need to make a sequence of posts. As I understand it, the slowness 
> is due to the time required to establish the secure connection, not an LC 
> problem. For example establishing an ssh connection in Terminal is even 
> slower; but once established an ssh session is super fast. Similarly curl 
> will reuse authentication credentials within a shell session, so I aggregate 
> as many calls as I can with a single shell script before using 
> shell(myscript), and this definitely helps.
> 
> What I would like to do however is use LC server as the middleware: I could 
> then process the required data on the server side; I could not contemplate 
> using php to do this. I suspect the LC post command uses curl under the hood, 
> but I also suspect each post call would create its own session. I don’t think 
> it is possible to establish a single session to talk sequentially to 
> lcserver; if so this would be too slow. Am I correct? 
> 
> Actually I guess I could  just use my present method using curl and shell() 
> instead of post, but addressed to an .lc script instead of .php?
> 
> Or is there a whole better way to do what I want? 
> 
> Neville Smythe
> 
> 


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

POST does not work under lock messages

[Neville Smythe via use-livecode]

It took me a while to figure this one out. I have a number of scripts which 
POST to LiveCode Server .lc scripts. All were working fine except one which 
always returned the output from whatever POST had last been executed. Evidently 
the previous form request was being resubmitted. Turns out I had a lock 
messages command before calling POST. 

Seems to me that shouldna oughta happen —either it’s a bug, or it should be 
documented 

(I think there is a documented warning about DataGrids needing Lock messages 
off? And wasn’t there a discussion a while back about Lock messages needing 
levels? The current documentation for Lock messages says it blocks “setProp 
triggers, getProp and certain other messages” where “certain”  is left 
undefined.)

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

POST data size bug

[Neville Smythe via use-livecode]

I seem to have hit another bug in POSTing data to LiveCoder Server (Community 
9.6.2) 

If the data being posted has 139000 characters the POST succeeds and I get a 
response back from my LC script in about 2.5 seconds. If I try to send about 
14 characters I get a time out error.

I presume the problem is in LC server, not in the internet library in my client.

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

POST data size bug

[Neville Smythe via use-livecode]

Ah. My bad 

I just discovered

libURLSetExpect100


Neville

___
use-livecode mailing list
use-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: POST command does not work if Lock messages is set

[Neville Smythe via use-livecode]

For anyone wishing to follow this bug, it has been confirmed by QC at 

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


As for my other fake news problem with data size and POST, please forget I ever 
misspoke.
LiveCode Server is rather a steep learning curve with not a lot of examples out 
there, but I love it already.

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

Call lc from php?

[Neville Smythe via use-livecode]

Quick question: is it possible to execute a .lc server script from within php 
(eg from an index.php page)?

This other way is documented, but on a cursory perusal I couldn’t see how to do 
it, and I’ve forgotten more about php than I remember. 

Maybe using a shell command within the php, but is there a way set up php to 
automatically recognise .lc? Php.ini??

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

Call lc from php?

[Neville Smythe via use-livecode]

A slightly less cursory investigation informs me that



works, as I should;d have known.


Neville

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

revCopyFolder in LC Server

[Neville Smythe via use-livecode]

I get a “Can’t find handler (revCopyFolder)” error in LC Server from a script 
line
revCopyFolder tTemplateDir,tDirPath

The script works up to that line. Is there a problem with using revCopyFolder 
in LCServer?

Neville

___
use-livecode mailing list
use-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: revCopyFolder in LC Server

[Neville Smythe via use-livecode]

Thanks Matthias. I would not have guessed that from the Documentation which 
simply says that revCopyHandler is available for “desktop,server”.

I was thinking I would just use a one-line shell call to replace the handler … 
but I suppose I should install the whole shebang

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

Resources folder on mac, and the good old days

[Neville Smythe via use-livecode]

> you may already know this, but this will not work in a standalone!
> We will surely not have write permissions in that folder!
> 
> As a workaround I would probably use -> specialfolderpath("temporary")
> Or even write the text to -> the tempname
> 


I find this discussions strange - I had the impression most users here were Mac 
developers and knew this stuff.

There is no problem writing to the resources folder. That’s the logical place 
to put the user-changeable stack files for a standalone, making the auxiliary 
files invisible to external fiddling by the user,  which a Good Thing (although 
that does make the app look different on Windows or Linux).

As for the Good Old Days of free distribution to other Mac (desktop) users, 
they haven’t gone. Apple is making it harder for the uninitiated to find out 
how to open “unsafe” files, but they don't keep it a secret. And while recent 
rumours abound  about unnotarized apps not working at all on some future MacOS, 
it does seem unlikely that will actually happen, and if they do that’s time for 
us all to reboot to Linux.

Neville



___
use-livecode mailing list
use-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: Resources folder on mac, and the good old days

[Neville Smythe via use-livecode]

> On 30 Mar 2021, at 12:44 am, use-livecode-requ...@lists.runrev.com wrote:
> 
> Unfortunately this has never been true on macOS X.
> 
> The Resources folder (which is in the macOS app bundle) should be 
> treated as read-only…

Mark Waddingham chides me for saying it is OK to write to the Resources folder 
in the app bundle on a Mac. Mark is, as ever absolutely correct. The correct 
place for application support files is the Library/Applications Support folder, 
and this has been the AppleGuideline for a very long time (although I am not 
quite so sure about that *always* being the case..) I was wrong, naughty, and I 
promise… Mea culpa, mea maxima culpa. I strongly advise against this awful 
filthy and degrading practice.

Except m’lud (he said in a very small voice), may I offer some admittedly 
post-hoc and flimsy excuses.

1. The app in which I do this originates from the days before the Application 
Support folder existed (I am pretty sure) and has grown like Topsy ever since. 
It worked then, it still works now. With one big caveat: this is ad hoc 
software, distributed to a small group of users (Colin: by all the usual 
methods - server, email, DropBox… they all work to deliver a working app 
without my having to renew my lapsed Apple Developer registration.) If I were 
to commercialise the app and so notarise it, I would expect writing to the 
Resources folder *not* to work, probably notarising keeps a checksum of the 
whole app bundle not just the executable. Maybe this distinction between ad hoc 
and notarised software is part of the confusion of this very confused thread, 
to which I have regrettably added more confusion.

2. It is a great convenience to my Mac users to be able to move their copy of 
the app to another machine, or give it to a friend, without having to worry 
about finding and transferring auxiliary files (unlike my linux users, who I 
must advise to keep everything together in one directory).

3. There is no need for Installer code, or more problematic, and with a whiff 
of sulphur to sensitive old-hand Mac user noses, an Uninstaller. Again if I 
were to commercialise the app, these would come with the territory of license 
files etc.

4. If my user wants to get at the auxiliary files, it is easy enough to explain 
the arcane process of opening up the Contents of the bundle. Explaining how to 
access the Library is only slightly more arcane, but I really don’t want the 
uninitiated venturing into that dark scary and very dangerous place .

So, readers, don’t do it. But keep it to yourself if you do. And it probably 
won’t work in MacOS 17.6.

Finally on the problem of opening unsafe/unnotarised apps in recent MacOS, I am 
afraid the discussion here has clearly only increased the confusion of the 
original forum user. Surely best to refer to the definitive source, the Apple 
Support documents which you can get by googling “How to open an unsafe app in 
Big Sur” (or Catalina, or Mojave). The instructions from Apple are clear and 
straightforward, unlike some tech forums which start off by talking about using 
the terminal to turn off Gatekeeper. 

Neville



___
use-livecode mailing list
use-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: Resources folder on mac, and the good old days

[Neville Smythe via use-livecode]

Interesting, and clever!

But how do they do that? Since the app can’t be running at the time it is moved 
to the trash, the code can’t be in the app itself. Which means they must 
install *another piece of code*, probably a daemon, which is running all the 
time; which would be necessary anyway for a security watchdog of course. Then 
does this but of code  uninstall itself? Possible I guess, the daemon file 
itself is not open when it is running so it could be moved to the trash and the 
daemon wasn’t killed it would just stop running the next time you reboot.

Of course for an LC standalone to use such an uninstall strategy you would need 
and Installer; and I don’t think it is really appropriate to have an ordinary 
app to have a daemon running all the time.

> On 31 Mar 2021, at 9:42 pm, Keith Martin  wrote:
> 
> 
>> On Mar 29, 2021, at 11:22 PM, Neville Smythe via use-livecode 
>>  wrote:
>> 
>> 3. There is no need for Installer code, or more problematic, and with a 
>> whiff of sulphur to sensitive old-hand Mac user noses, an Uninstaller
> 
> Hah! Yes, uninstallers should ideally never be required. I'm testing a 
> selection of macOS security tools at the moment (for a magazine, not just for 
> fun!) and I really like how – to give the most recent example – Avira Free 
> Security and Avira Prime (with help from the OS of course) will ask, when the 
> app is moved to the trash, if they should take their system extensions with 
> them. Polite, civilised, Mac-like. 😎
> 
> Keith
> Keith Martin
> 360 media specialist http://PanoramaPhotographer.com 
> <http://panoramaphotographer.com/>
> Contact and info http://thatkeith.com <http://thatkeith.com/>
> +44 (0)7909541365
> 
> 
> 
>> 

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

Property inspector opening with wrong object

[Neville Smythe via use-livecode]

Has anyone else experienced this? It is very annoying.

Sometime when I open the Property Inspector for an object it opens the 
inspector for the stack instead. I don’t know what triggers it, but once it 
starts happening it always happens; relaunching LC restores sanity for a while. 
This is on a Mac using Catalina LC 9.6.3 but it has been happening for  while 
now.

Neville Smythe
___
use-livecode mailing list
use-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: Property inspector opening with wrong object

[Neville Smythe via use-livecode]

>  By double-clicking a selected object when with the pointer tool? By 
> selecting from the ?Object? menu?
> 
> Craig

I had forgotten about opening the Inspector with double-click, I had got into 
the habit of opening from the contextual menu. The bug is not happening just 
now so I can’t check if double-click will always work correctly.
> 
> What happens if you open the object inspector, then select an object on a 
> card? It *should* change to the properties of the selected object. 
> 
> Bob S

The Inspector does change to the desired object if I then select the object, so 
it is not a complete disaster.

Clearing the preferences doesn’t help (had to do that after upgrading to 9.6.3 
because the bottom part of the script editor disappeared - did anyone ever find 
out what triggered that? - but the IP bug happened before and after clearing 
Preferences).
>> 
>>> On Aug 24, 2021, at 11:39 PM, Neville Smythe via use-livecode 
>>>  wrote:
>>> 
>>> Has anyone else experienced this? It is very annoying.
>>> 
>>> Sometime when I open the Property Inspector for an object it opens the 
>>> inspector for the stack instead. I don?t know what triggers it, but once it 
>>> starts happening it always happens; relaunching LC restores sanity for a 
>>> while. This is on a Mac using Catalina LC 9.6.3 but it has been happening 
>>> for  while now.
>>> 
>>> Neville Smythe


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

Bye, and thanks for the fish

[Neville Smythe via use-livecode]

> On 1 Sep 2021, at 11:36 pm, use-livecode-requ...@lists.runrev.com wrote:
> 
> i am not sure, if everyone is aware of it, but standalones that were created 
> with the Starter Plan license will expire as soon as the Startert Plan 
> subscription expires.

Not even Apple is that rapacious.

I used to have a commercial licence back when I was selling stuff (although the 
economics of software never made sense). Since retiring I have been 
“freeloading" with the Community edition as a hobbyist, my only LC uses being 
for personal use, and maintaining admin and operating software I wrote for a 
not-for-profit sporting organisation, and occasionally contributing bug 
reports. I can well understand the need for LC to move to a profitable basis, 
and I would be happy buy a plan if it made sense for our use, but there is no 
way my NFP association can afford US$1000 every year - or even one year (we 
would use 3 platforms, and not even the Server is thrown in with the desktop 
platforms). And a Starter Kit that means the app would stop working when I pass 
on (I have been around since Hypercard day 1) is an insult. Seems to me the 
hobbyist use of LC has come to an end. A great pity, but I guess times move on.

I have greatly enjoyed being part of this (mostly) friendly and generous 
community for many years.

Neville Smythe 

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

Hi, I'm back for more fish - and a malware query

[Neville Smythe via use-livecode]

OK, Bob S, so I have jumped through the small hoop and turned through 180 
degrees. And I’m impressed even if you were not: that is to say, I am really 
impressed with the generosity and goodwill of the great people at LC.

Many thanks to those who urged me contact Heather and Kevin about  licensing, 
and I heartily echo the sentiment of Erik on the integrity of the company.

And now back to business: the very first compilation of a Windows standalone 
with my brand spanking new 9.6.4 provokes a malware alarm for the Trojan 
Sabsik.TE.A!ml on a Windows 10 machine.

I think it almost certain this is a false positive. My Mac reportedly cannot 
run or spread this particular malware, and I’m pretty sure the only Windows 
file on my Mac which could contain it (or rather the code sequence which 
triggers the alert) would be the Windows engine in LC9.6.4. Just to be sure, 
because no-one want to take chances with ransomware … has anyone seen or heard 
reports like this ?

Neville Smythe
___
use-livecode mailing list
use-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: Stack with the same name loop

[Neville Smythe via use-livecode]

Jaque wrote

> On 8 Oct 2021, at 7:54 am, use-livecode-requ...@lists.runrev.com wrote:
> 
> For me, the confusion would be resolved if the Save button was renamed to 
> "Save and Purge". I was never quite sure what that button saved, though in 
> retrospect it's pretty obvious.

And ...

if the dialog could inform the user as to the filename of the stack which is 
about to be opened, the filename of the stack currently in memory (or “not yet 
saved"), and whether the current stack has unsaved changes. This would make it 
clearer what the consequences are in each of the options.

It seems to me in Sean’s case the stack being loaded was not the stack one 
might expect (ie was it attempting to reload the the original or the renamed 
stack?)

Neville 

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

dropShadow knockout

[Neville Smythe via use-livecode]

The knockout checkbox is missing from the graphic effect dropShadow edit dialog 
in LC9.6.5 (Mac). The knockout property still works however.

Further occasionally the edit box appear to become corrupted  - after a few 
launches the display is out of kilter, and eventually the edit box won’t open 
at all (or is invisible). Not recipe for this as yet.

Neville Smythe
___
use-livecode mailing list
use-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: dropShadow knockout

[Neville Smythe via use-livecode]

>> Further occasionally the edit box appear to become corrupted
> 
> This only happens to me when I accidentally close the edit box via the close 
> decoration and not via the "OK" button.
> The same happens with the edit box for editing gradients.

Thanks for confirming that Bernd.

Closing that corrupted gradient editor via the window decoration control rather 
than the inaccessible Cancel or OK buttons also leaves the selected graphic in 
a bad state: resizing it (though not moving it)  corrupts the fillGradient of 
the target -- it does not modify the points co-ordinates to reflect the new 
values [IMO an unhappy design decision to use stack co-ordinates rather than 
target co-ordinates for the from, via and to points in the gradient array]. It 
apparently leaves the target graphic in edit mode, because it can also display 
ramp handles in the target control which cannot be removed without relaunching 
LC.

And speaking of bugs I personally clearly have a proof-reading bug, I cannot 
believe the number of typos in that last post of mine.

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

Accessing array custom properties

[Neville Smythe via use-livecode]

Is there a logic behind the following?

I want the values of a custom property which is an array: to take a specific 
example the dropShow of button “button” and I want  the specific element color

Of course I can write: put the dropShadow of button “button” into aa; put  
aa[color]

Conveniently there is a shortcut : put the dropShadow[color] of button “button” 

(which I guess would need special coding because there isn’t a property whose 
name is "dropShadow[color]”; and this doesn’t work for DataGrids - but that’s 
another question)

Now I want to use variables so I can script for different properties

put “color” into pElementName; put “dropShadow” into pArrayName

1. This works:put the dropShadow of button “button” into aa; put 
aa[pElementName]

2. And this works:put the pArrayname of button “button” into aa; put 
aa[pElementName]

3. And (conveniently) this works:put the dropShadow[pElementName] of button 
“button”

4. BUT (annoyingly) this fails, giving an empty result: put the 
pArrayName[pElementName]  of button “button”

Why? If 3 works, I would have thought the parser would substitute values for 
all variables before getting the property using  the “special coding”

Neville
___
use-livecode mailing list
use-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: use-livecode Digest, Vol 217, Issue 30

[Neville Smythe via use-livecode]

> On 27 Oct 2021, at 3:00 am,Craig wrote:
> 
> An array variable is just a variable, it is not a property. You cannot ?make? 
> one into the other.
> 
> So, basically, put the pArrayName[pElementName]  of button ?button? is just 
> syntax that does not exist in the lexicon, for the above reason.

Thanks Craig. I was thinking in terms of a natural language, not strict lexical 
syntax.

Because I would have thought strictly speaking  

put the dropShadow[color] of control X

shouldn't work, there must be an extension of the language  to interpret is as

put (the dropShadow of control X) into foo; put foo[color].

But that extension won’t work with a variable in place of the literal property 
name, or for a literal which is not a reserved word, because the parser has to 
check for literal reserved words before it evaluates variables.  Which also 
explains why the apparently similar

put the foo[bar] of control X

returns empty even though the control has a custom property foo with key bar 
having a non-empty value. 

Speaking of  reserved words here is an oddity

put rect[1]

returns “]" (strange, but true, and apparently happens for any reserved word 
value of rect)

Of course

put “rect” into foo; put foo[1]

returns empty, because as above reserved words are interpreted before variable 
evaluation, not after. It all makes sense now - well, except for rect[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

Object property management

[Neville Smythe via use-livecode]

I have uploaded a plugin tool nsFormatMapper 2.0 to RunRevOnline. It is 
designed to help with maintaining uniformity of UI elements such as colours and 
text properties. It works rather like the Format Paint brush in Word or Pages. 
You get all the required property types from an object, and set those 
properties in another via drag and drop. You can also save sets of properties 
for use as favourites. Properties transferrable included  color, text, button 
and field properties, graphic effects, gradients and blending. Hope some 
developers find it useful.

Neville
___
use-livecode mailing list
use-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: Object property management

[Neville Smythe via use-livecode]

Aaargh, I can’t even remember the name of my own stack! I have incurred the 
wrath of Blind Io by invoking her name in the help text.

Thanks Matthias it is indeed nsPropertyMapper

Neville

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

Pattern ID bug

[Neville Smythe via use-livecode]

Try setting the backgroundPattern of a button to ID 141, either from a script, 
or by using the Image Library chooser and going to the MetaCard Compatible 
Patterns, look for ID 141 which is small image of dots on the second page.

What you get, at least on my Mac with LC9.6.5, is a pattern of red leaves which 
is image id 236 (tho also weirdly id 277). Similar things happen with id 142 
and others.

I came across this while trying to write an ImagePicker for the 
nsPropertyMapper plugin which would improve on the built -in Image Library 
Chooser, which frankly I thought couldn’t be all that hard. I find I need to 
bypass the way LC finds pattern and icon images when all it has an ID (I guess 
this is a legacy from Hypercard), rather than a full reference to an image; the 
ID is by no means unique even within built-in rev image libraries - though 
actually 141 is unique in this case so that is not the explanation for the bug. 
I had to fool around with behaviors to force the LC search path and thought at 
first I must have corrupted the revIcons or revGeneralPatterns stacks. But I 
get the same bug on a fresh install on a completely different Mac.

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

nsPropertyMapper revision 3

[Neville Smythe via use-livecode]

I have uploaded version 3 of my drag-and-drop property management tool, which 
now handles patterns, graphic objects and images. Included is an ImagePicker 
which gives access to images in all open stacks as well as LC built-in images, 
allowing easier transfer of images between stacks, and many more icons than the 
LC Image Chooser; you can save favorite images, view image metadata, facilitate 
scaling an image to fit given bounds, and check your stacks for duplicate image 
IDs and unloaded images referenced in icons and patterns which could go missing 
in a standalone.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

nsPropertyMapper Revision 4

[Neville Smythe via use-livecode]

Sigh. Revision 4 fixes a bug: placing an image with the ImagePicker didn’t 
work, Something I thought I tested just before I uploaded Rev3. I really have 
angered Blind IO this year.
___
use-livecode mailing list
use-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: add a "scale" option to the icongravity

[Neville Smythe via use-livecode]

> Wouldn?t you really need another property like ?iconSizing? which would have 
> values of ?none? or ?clip? (current behavior), ?resize? or ?fill? (the 
> current iconGravity option), and ?scale? (your proposal)?  I can think of 
> situations where clip and scale would need the current positioning afforded 
> by the gravity setting.

I think often the best option is “scale to fit” by which I mean scale the image 
down to fit the button keeping the same aspect ratio *if* it is too large, but 
leave the original image size as is if it will already fit, *do not* upscale, 
which can cause pixelation. It is neither the current ”resize”  nor the usual 
“scale to fit"
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Property mapper and a s script database

[Neville Smythe via use-livecode]

I have uploaded version 3.4 (revision 7) of nsPropertyMapper to the Sample 
Stacks site. You can now insert an image into a text field by dragging an image 
reference from the ImagePicker onto a character in the field. It looks like 
another revision soon will be needed in light of the new iconGravity settings 
in LC 10.

While working on the PropertyMapper I have been frustrated by not being able to 
open alternative versions of the stack (working version, previous version, 
golden master, version I left on the Desktop for some reason I have forgotten) 
to compare or recover bits of scripts, because of the limitation in LC about 
stack names. So I have put together a script database management 
stack/standalone in which one can install as many copies of stacks as you like, 
and search their scripts. You can save favourite code snippets (eg a UTC 
timestamp handler, or Jacque's recent note about visual effectrate which was 
news to me), add keywords for later database queries, compare versions, and 
even search for that script you wrote some time before 2010 where you made a 
comment somewhere about a memory leak.

It runs best as a standalone so rather than submit it to Sample Stacks the 
compiled versions together with the source are available at

https://www.dropbox.com/sh/6jlr902yn6kktun/AADLjPIl8fb4lGvaYt1ZsOhla?dl=0

Comments, bugs and suggestions most welcome.

OT: All this would have been ready days ago if I hadn’t been diverted by the 
wordle craze  - it’s all too tempting  to use LC to quickly cobble together 
versions for other languages since I already have word lists for English, 
French, Italian, German etc, and looking at frequency tables for the best first 
test word. Hint: the most frequent letters sequence is *not* ET AION RSH… 
well-known to codebreakers.

Neville Smythe
___
use-livecode mailing list
use-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: Speed up a slow loop

[Neville Smythe via use-livecode]

Jacque, are you trying to keep the whole of SOWPODS in memory the whole time? 
That’s a 2.5MB file. It sounds to me like you are getting virtual memory 
thrashing.

If so, try breaking up the wordlist into 26 files for example - or even more by 
length as well as initial letter - kept as resources (rather than in fields)  
and only reading in the file required to check  a word as needed (and emptying 
the variable loaded from file asap). My guess is a linear search on a small 
file is going to be faster than array indexing magic if memory swapping starts 
to occur.

Neville
___
use-livecode mailing list
use-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: Speed up a slow loop

[Neville Smythe via use-livecode]

Bob’s suggestion of storing the word list in an sqlite database would keep the 
list on disk and not in memory, so avoiding VM swapping which is  I think  the 
basic problem, and also use a much faster search engine than LC to do the 
checking for the existence of user candidates. A more elegant solution than 
breaking up the wordlist into hundreds of small files. 

It is possible because we know the structure of the data in this case that lots 
of small files, with a couple of other tricks to reduce file size, and then 
using an LC search, could be faster (because the OS file system is even more 
efficient than sqlite) but I’d be surprised if the db approach didn’t solve 
your problem.


Neville
___
use-livecode mailing list
use-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: Speed up a slow loop

[Neville Smythe via use-livecode]

Jacque seems to have found a satisfactory solution to her problem with the help 
of the excellent suggestions we have seen here. Since there seems to have been 
a lot of interest, I thought I would take the opportunity to report on an 
alternative method I had been exploring with Jacque via email.

I believe there were two problems: a) the original search search algorithm was 
too slow, and b) when implemented on certain devices the app went into an 
unusable state. Both problems were caused by the wordlist being stored being 
too large (275K words for a file size of  2.5 MB). The second issue we are 
pretty sure was Virtual Memory swap space thrashing. 

Using Quentin’s why-didn’t-I-think-of-that filtering suggestion the wordlist 
can be reduced (in the vasty majority of cases) to a manageable size, say 20K 
words or less, and both problems solved very elegantly.

There are however edge cases where the filtered wordlist can still be huge, 
over 200K words, [ eg unused letters are JQXYZ  ]. Such cases are going to be 
very rare, so Jacque is going with the above solution. 

An alternative is to use an sqlite database, always an option which should be 
considered when handling large data. This completely removes the issue of 
having the wordlist in memory, and at the same time provides an extremely fast 
search engine, so was worth exploring as a solution to both problems.  Storing 
the words in a db single table with an index on initial letter and word length, 
or as lots of tables, one for each initial and length (!), both return a result 
for a search for a word in a small fraction of a millisecond, so definitely 
this would be a viable solution which would handle all letter distributions.

There is however a downside: both methods produce a db file size of 7.1 MB for 
the SOWPODS wordlist, which rather bloats the app footprint, even when you 
discount the text file version of the wordlist which no longer needs to be 
stored. If one was writing a crossword app, where you might be searching for 
words for which you know the 3rd and fifth letter for example, bread and butter 
for an sqlite query, this would definitely be the way to go, but probably 
overkill for Jacque’s app.

But now, speaking of databases, I have a question. I have an update to my 
nsScriptDatabase stack which I want to upload to the Sample Stacks. Because it 
really should be compiled to a standalone, I really need to upload a pair of 
stacks, a launch stack and one to hold data which can one modified by the user. 
But it would seem a sample stack must be a single item. What to do?

Neville
___
use-livecode mailing list
use-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: Speed up a slow loop

[Neville Smythe via use-livecode]

> On 9 Mar 2022, at 4:00 am,Alex Tweedly wrote:
> 
> Oh, well, if you've got the fast boardwalk code in there anyway, that 
> opens up another possibility (with one caveat).
> 
> The boardwalk will find all valid words on the board. So that list of 
> words can be used as the "dictionary" for the user's guesses - and now 
> you have a "dictionary" of only a few hundred words, rather than than 
> the many thousands of either the original or the filtered dictionaries.
> 
Really only a few hundred potential words? My back-of-a-very-small-envelope 
guesstimate was about 2000.
I’ll be interested to see how many there are, because my envelope isn’t big 
enough to work it out, and the walking algorithm which I am really impressed 
can be so fast.

But anyway checking even a few hundred potential words (the vast majority of 
which would be non-words so the worst case) is going to be slower than checking 
a much smaller number of mostly valid user candidates. Both can one done in 
idle time so not a problem I guess.

Neville
___
use-livecode mailing list
use-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: Speed up a slow loop

[Neville Smythe via use-livecode]

> On 9 Mar 2022, at 4:00 am, Alex Tweedly wrote:
> 
> I guess I'm not convinced about VM space thrashing being the problem, 
> certainly not due to the wordlist. It's 2.5 Mb - i.e. 0.02% of the real 
> RAM in a Pixel 5. There may be something else in the app making the 
> total VM space very large - but the wordlist wouldn't do it on its own.

I have to agree … although the relevant RAM size is the amount allocated to the 
app, not the total RAM. The OS presumably takes up most of the RAM by itself. 
But of course just a single copy of the list in memory is not a problem or 
Jacque wouldn’t be able to do the filtering.  Turning the list into an array 
will add indexing overhead very similar to what using a database would do (I 
suspect extremely similar in fact!) but I would have thought we are still only 
talking 10MB at most. Possibly more, the faster-than-light magic that happens 
with arrays must be trading off memory for cpu time somehow  The symptoms 
definitely sound to me like VM thrashing, and reducing the list to around 20K 
words evidently removes the issue, which suggests multiple copies of the array 
are being created somewhere in (Jacque’s original ) search algorithm.
> 
> 
>> An alternative is to use an sqlite database, always an option which should 
>> be considered when handling large data. This completely removes the issue of 
>> having the wordlist in memory, and at the same time provides an extremely 
>> fast search engine, so was worth exploring as a solution to both problems. 
>> Storing the words in a db single table with an index on initial letter and 
>> word length, or as lots of tables, one for each initial and length (!), both 
>> return a result for a search for a word in a small fraction of a 
>> millisecond, so definitely this would be a viable solution which would 
>> handle all letter distributions.
> Sounds cool. I'd like to see an example of how this would be created and 
> used (I'm very much a SQL novice).

I can’t claim to be an expert myself (see below) but it’s not hard and the LC 
tutorial together with online sqlite cheat sheets make it pretty 
straightforward. The hardest bit is getting into the db mindset which a bit 
different from procedural coding. The LC library makes it very easy to use 
sqlite in stacks. Creating the db from the data is easy,  it only needs some 
thought on what tables and columns are needed - just like designing a DataGrid 
in LC. Making simple queries of the db is plain language-like. For example to  
find all words matching a crossword pattern - - T - - - -  containing N you 
execute a query such as

SELECT FROM words WHERE (length=7) AND (word LIKE ‘__T’) AND (word LIKE 
‘%N%’);

[ wildcard underscore _ matches a single character, % matches an arbitrary 
string … sound familiar? LIKE is used for comparing strings]

This outputs the 89 answers in a few milliseconds [most of which look to me 
like real words. But LETTERN ?? WITCHEN ?? SOWPODS really is ridiculous]

Making more complex queries is where things get arcane.

>> There is however a downside: both methods produce a db file size of 7.1 MB 
>> for the SOWPODS wordlist, which rather bloats the app footprint, even when 
>> you discount the text file version of the wordlist which no longer needs to 
>> be stored.
> You could do the opposite. Store the wordlist (700Kb compressed), and 
> decompress/populate into the SQLite database on initial run.

But unfortunately populating the database is very slow, taking minutes. [Note 
to myself: hey wait a minute, me, a database with only 275K rows is not that 
big in sqlite terms. Why is it taking so long? Because I am using a dumb repeat 
loop inserting one word at a time, akin to adding one word at a time to a field 
and then updating the UI. There is a better way. Physician, heal thyself!]

>> But now, speaking of databases, I have a question. I have an update to my 
>> nsScriptDatabase stack which I want to upload to the Sample Stacks. Because 
>> it really should be compiled to a standalone, I really need to upload a pair 
>> of stacks, a launch stack and one to hold data which can one modified by the 
>> user. But it would seem a sample stack must be a single item. What to do?
> 
> Yep -this is a big drawback of the Sample Stacks system.
> 
> Maybe you could make a single app, which contains the two desired stacks 
> as custom props.

Ah thank you, and a very interesting approach which I would never have thought 
of. Prompted me to think of another way: include the data stack as a substack 
when used in the IDE, but on openstack when not in the development environment 
clone the data stack to a writeable directory. That should work.

Neville

___
use-livecode mailing list
use-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: Speed up a slow loop

[Neville Smythe via use-livecode]

I just ran a test to try to find out how much RAM is used when you create a 
large array; the result is rather surprising.

 BTW Bob: I did not imply that an array is implemented in LC as a database. 
Merely that to work its magic it must be indexing keys somehow. 

I had suggested a 2.5 MB list of 275K words might expand to no worse than 10MB 
when split into an array. Not quite, as it turns out.

I wrote a very simple stack which just has two buttons. 

The first reads SOWPODS.txt into a global variable gWordlist. Don’t try putting 
that variable into the msg box — LC becomes unusable with the Beachball of Hope 
spinning for a few seconds whenever you do anything. Aha, it is the LC engine 
that is having problems with large data (in this case displayed in a field of 
course, not in the variable itself)

The second button puts gWordlist into aa, and splits aa by CR  as a set.

I then turned the stack into a standalone and looked at the memory used in the 
Mac Console

. When the stack launches, real memory used is 29.8 MB (in a second run 45 MB)
That’s the basic LC engine + 18 MB of Mac OS stuff which is shared with 
all apps, the stack itself would be tiny

. after button 1, reading in the 2.5 MB file, the real memory used is 46 MB 
(second run 56 MB)
So 16 MB to store a 2.5 MB file in a variable (in the second run 11 MB, 
I guess 5 MB of engine code was garbage collected)

. After button 2, the real memory used is 121 MB (second run 131 MB)
So splitting a 2.5 MB file into an array with 275 K keys required 75 MB 
(this figure was duplicated in the second run)

We are now talking pretty large amounts of memory that the LC engine has to 
move around, for example probably making copies in its procedure stacks (that's 
stack in the coding sense).

I'm not surprised that LC might be getting indigestion with variables of this 
size on a small device. I seem to remember running into RAM allocations for an 
iOS app measured in the low hundreds of MB.

Neviille
___
use-livecode mailing list
use-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: Speaking of Filter and Match...

[Neville Smythe via use-livecode]

I just ran a speed test on Dick Kriesel’s method for removing duplicates and 
keeping the original sort order. It is indeed faster than Jacque’s method

Sorting 11000 lines of text including 1000 duplicated lines:

Jacque’s method: 2.807 seconds [lineoffset is really slow, and in effect the 
text is scanned 3 times]

Kriesel method:  0.017 seconds

Bu what really made my eyes pop — unless I am doing something wrong, it is 
faster than using the accepted wisdom of just using “split  by cr as set; put 
the keys” method of removing duplicates and leaving the text unsorted

Split as set, don’t care about sort order method: 0.024 seconds

I can’t see anything wrong with my code, but can someone independently confirm 
this??

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

nsScriptDatabase 1.1

[Neville Smythe via use-livecode]

I have uploaded version 1.1 of nsScriptDatabase to the Samples Stacks. This 
fixes a few problems with editing code snippets and running the stack as a 
standalone, which is the preferred environment.

You don’t need to know anything about the technicalities of databases to use 
nsScriptDatabase to maintain a searchable archive of scripts, re-usable 
handlers, code snippets and notes.

Neville



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

Plugin changes not saved

[Neville Smythe via use-livecode]

I hadn’t realised that LC does not offer to save changes to plugin stacks when 
it quits. Foo!

I have therefore updated nsPropertyMapper (version 3.6. Revision 9) in Sample 
Stacks so changes to favorites and settings will be available on the next 
launch, there wasn’t much point to the favorites feature if they weren’t being 
saved! There is also an update to nsScriptDatabase (version 1.3)

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

Widget properties

[Neville Smythe via use-livecode]

Is it not a bug that

 the properties of widget “foo”

returns empty (for all values of foo)?

No rect, no visible, no disabled etc, even though these clearly are settable 
and functional properties of the widget.

You can

export widget “foo” to array “bar”

but that gives the intrinsic properties of the widget not the usual object 
properties. Oh and don’t forget the reserved word “array” in the above line, 
that causes an IDE crash (bug 23655 
 confirmed)

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

Re: widget properties

[Neville Smythe via use-livecode]

I have submitted the bug report (Bug 23670 
) As others have said, it 
is not likely this will be considered a high priority bug but it should be on 
the record.

Interestingly eg setting tbar[“textcolor”] to a value and then

set the properties of widget “foo" to tbar 

does work (although the properties are still reported as empty). 

Many thanks for the reference to Ali’s forum article, which is very helpful. I 
came across this  problem because I am adding listing of all object properties 
to my nsScriptdatabase utility. Thus in version 2 it will be possible to 
compare stacks in the database down to the complete saved state of the stack, 
and so (theoretically) reconstruct the stack. Ali’s post prompts me to add 
listing the handlers of a widget which could be very useful information. I 
expect to upload version 2 within a few days.

Neville

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

Re: widget properties

[Neville Smythe via use-livecode]

Just a point of clarification; Ali’s post does not explain how to access the 
object properties of a widget. The properties returned by

put the keys of (revIDEExtensionProperties("com.livecode.widget.foo"))


are the intrinsic properties of the widget, which these days  are accessible 
via the 

export widget “foo” to array tBar

command. They are not the ordinary object properties such as its rect, 
visibility etc. 

My current workaround is to just make up a list of likely properties names, for 
example those of a group, deleting the few properties obviously specific to a 
group. Unfortunately LC doesn’t respond with a “object does not have this 
property” error message if you query any old reserved property key for a 
widget. An alternative would be to go through the properties shown in the 
Property Inspector deleting the intrinsic properties specific to the widget; 
but some intrinsic properties are also common object properties, eg showBorder, 
depending on the widget you choose, and further I am not entirely sure that the 
Property Inspector actually exposes all the properties of an object (?). It 
also lists interdependent properties (loc <- rect) which should not be returned 
by the properties function.

Neville

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

Re: widget properties

[Neville Smythe via use-livecode]

 (Bug 23670 ) has been 
referred by QualityControl to Expert Review, as Panos was not sure whether this 
is a real bug. As a use-case I have commented that the properties of all 
controls, including widgets, is needed when comparing stacks for example.

In the meantime, I have uploaded version 2 of nsScriptDatabase to Sample 
Stacks,  now optionally allowing adding the properties of objects to the 
database, so the complete state of a stack is captured, although scripts remain 
the main focus. When using the "compare stacks” feature I make up a credible 
list of properties for widgets.

Neville

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

IAC for Livecode standalones

[Neville Smythe via use-livecode]

When developing my recent utility I have thought it could be useful if other 
users could access the output from some of its features, in other words 
inter-application communication. Stacks can do this if the utility is running 
in the IDE but not when run as a standalone.

Now a Mac fully-featured app is encouraged to implement AppleScript access. It 
appears LC has a couple of features for helping to implement AS, (send to 
program and reply) but implementing AC in an LC standalone still looks to be 
even more complicated than in Xcode, where it so painful than most apps don’t 
bother: you have to set up a separate event handler and create the AS 
dictionary, and the AS  language itself is abstruse to say the least — but how 
fantastically useful are those apps like Excel which do the implementation 
well! LC appears to have nothing for VB for Windows and I have no idea how to 
to do it myself on Windows. And of course there is nothing for Linux (go away 
and write your own sockets implementation at both ends!!)

How cool would it be if LC standalones could easily talk to each other, at 
least when running on the same platform, which is where AppleScript and VB 
live! It certainly is possible, I have done at least one half of it running 
scripts in an LC app from a shell interface, connecting via sockets; but the 
learning curve for the coding was high.

[Remote IAC raises knotty problems of implementation (secure login or Html 
POST?) and heightened security problems - though LC actually already does 
Remote Debugging which is related but not quite the same as normal IAC usage; 
for example with Remote Debugging you can run any script remotely unless it is 
password protected, quite the opposite of what you want IAC access to do. And 
it only works from the IDE source]

I don’t know if this idea has been raised before, but I reckon all it should 
need for a very LC-style implementation would be:

In the target app,  expose a handler by simply marking it as public. And 
preferably provide a manifest describing the usage and input/output.That’s it. 
No dictionary resource files, no coding.

In the source app I'm guessing one would only have
Open application “foo” for IAC with credentials “its me"  -> an access id 
and array of handlers and their manifests
Dispatch “myhandler” to application “foo” with  -> the result 
or error if not handled for timed out
Close application pAccessId

The engine would handle finding the LC app, connecting to a socket 
automatically opened on launch if the app has a public handler, getting user 
authorisation [Allow Always? On Launch? On Request?] and swapping certificates, 
and then data transfer. I leave this part as an exercise for the reader


Neville


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

Pulldownmenu button bug on Windows

[Neville Smythe via use-livecode]

I have a pulldown menu button which has a menupick script and also a mouseLeave 
script.

On a Mac, when a user brings up the menu and drags the mouse down  to select a 
menu item (leaving the button rect but within the pulldown menu), the menupick 
handler is invoked, and then the mouseleave handler is called. This is what I 
expected.

However on Windows, the mouseleave script is called immediately the mouse 
leaves the button while the user is still in the process of making the 
selection, and then menupick is called if the user actually makes the selection.

Which means standalones behave quite differently (in my app, the menupick did 
something to a selection in a field, and mouseleave did something else to the 
selection: the order is thus critical).

They can’t both be right, so certainly one is a bug. The Mac order is IMO 
correct since the pulldown menu has been started by the user so the app should 
be in a modal state until the menu selection is resolved.

Neville


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

Zip file problem on Mac

[Neville Smythe via use-livecode]

I distribute a Mac standalone via a zip file, created using revZipOpenArchive 
etc.

This has worked fine until macOS Monterey or LiveCode 9.6.x 

Either a bug has been introduced into the revZip tools in 9.6.x, or I have a 
corrupted version, or the Mac Archive Utility has changed so as to make the rev 
zip tool fail. Can anyone verify the following?

 On my Mac, the Archive Utility in Monterey, which automagically unzips files 
when a zip file is downloaded by Safari or double-clicked, now unsets the 
execute bit on the application (more precisely, on the executable file in the 
bundle). Which means the user gets a “This application could not be opened”, 
with no options to continue, when they try to launch the unzipped app. A 
terminal savvy user can use chmod x+ to make the app launchable, but I can 
hardly expect the ordinary user to have to do that. The execute bit is 
definitely set in the archive, because TheUnarchiver, a free third party 
decompression tool, unzips the file leaving the app launchable. This also 
suggests that the problem is not in my code.

I can see why Granny Apple might have thought this was a good idea, executables 
in zip files are a the major sources of trojans, but if Apple has made this 
change it is a bit nasty because there is no obvious way to override the 
behaviour.

If I use the Archive Utility to actually create the zip file from the 
standalone app bundle rather than using the rev tools, and then double-click it 
to decompress, the file unzips with the execute bit set. This shows the archive 
produced by revZip is not the same as that expected by the Archive Utility. It 
also suggests  a workaround would be to use Archive Utility from a shell 
command (it is not AppleScriptable – bad Apple!). From a cursory search on 
Stackoverflow,  the command line would be (this is not yet tested and the post 
is 5 years old)

ditto -c -k --sequesterRsrc --keepParent Product.app Product.app.zip

to create the zip file for the Mac platform. The post says that is what the 
Archive Utility uses to compress files. Probably  the rev zip tools use zlib. 
Or maybe I should be creating a .dmg disk image instead of a zip file.

Neville


___
use-livecode mailing list
use-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: Zip file problem on Mac

[Neville Smythe via use-livecode]

I have submitting a report to QC (Bug 23698 
)

Thanks Matthias for clarifying that permissions are not correct in the archive. 
I can now add that the Linux archive has the same problem. The Windows archive 
created by revZip executes correctly.

So the problem is nothing to do with Apple. TheUnarchiver and Keka changing the 
permissions to what they think they ought to be sounds well-intentioned but 
highly problematic (what’s the meme for the opposite of an overprotective 
nanny? Busybody big sister?)

Your last comment caused me to realise that I have only changed very recently 
to automating the process of creating the zip files as a post-standalone 
build-process using revZip. Previously I created the zip files by hand, and my 
beta-tester uses Windows. Thought I was being clever. So the bug in the LC 
implementation may have been present for a long time.

Neville

> 
> Neville, i can confirm that behavior even under BigSur.
> 
> I've created a small standalone with LC 10DP3 on BigSur and created  2  zip 
> files  from the output folder using LC's zip library and using shell command 
> zip.
> 
> Running the shell command 'zipinfo' to analyse both zip files showed, that 
> the zip created with LC's zip library did not contain any executable 
> permissions while the zip created with macOS zip shell command did contain 
> the permissions.
> So it seems the LC's zip library does not store the permissions in the zip.
> 
> According to your comment about The Unarchiver. Yes, i can also confirm that 
> The Unarchiver and also Keka can extract the zip file created with LC and the 
> standalone in the extracted folder is executable again.
> But...
> As zipinfo did list all the files wihtout any executable permissions, i 
> unzipped the zip with the shell command 'unzip' and that standalone was not 
> executable again. All files showed exact those permissions that zipinfo 
> showed before.
> 
> So i assume the following: Keka and The Unarchive seem to correct file 
> permissions when they detect a folder structure that seems to be an app 
> bundle. But that's just an assumption.
> At least Keka seems to have such feature according to its change log Changes 
> in version 1.0.11 
> 
> 
> But anyway. The LC zip library ignores the permission when creating an 
> archive.  If this worked before with older versions of LC  i cannot say, as i 
> always used the zip shell command or tools like Keka.
> 
> 
> Matthias
> 
> 

___
use-livecode mailing list
use-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: Zip file problem on Mac

[Neville Smythe via use-livecode]

> On 7 May 2022, at 2:00 am, use-livecode-requ...@lists.runrev.com wrote:
> 
> This sounds like this enhancement request
> https://quality.livecode.com/show_bug.cgi?id=9642 
> 

Thanks Panos for pointing out this is a duplicate to bug 9642, an enhancement 
request since 2011. I did do a quick search but clearly not very thoroughly.

The comments in that request hint that it is an OSX specific thing to include 
the execute permission flag in the zip files, and maybe the revZip tools are 
just following the zip specs as Matthias says, but I’m not sure about either. 
The original zip description said it included a copy of the file directory, but 
that was in the context of MSDOS which didn’t have an execute flag. Whether 
permissions are included in the archive does depend on the tool used to create 
the zip file and the platform. There is a long and confuseing thread on 
Stackoverflow about producing zip files which include execute permissions.

Recall my objective was to use LC to post-process the standalone build to 
produce a compressed file of each of the Mac, Windows and Linux standalones 
created by LC, and to do this whether the development platform was a Mac, 
Windows or a Linux box. At the time zip appeared to be the obvious choice.

I haven’t checked what the OSX shell command zip produces, but the Mac version 
produced by the default archiver (in effect the shell command ditto) does 
include the x flag. As Matthias notes one can check this using zipInfo or its 
equivalent unzip -Z on any platform. But it is not just Mac specific in the 
sense that Linux will happily decompress the Mac-created Linux standalone into 
an executable – at least on Ubuntu unzip -Z reports that x is set to true. On 
Windows unzip -Z looks at the .exe extension to decide if the file is 
executable rather than looking at unix permissions, so the Windows standalone 
will decompress into a launchable app (and I guess that is the reasoning behind 
TheUnarchiver and Keka setting the permission when unzipping a file with .app 
file extension on a Mac, even if the permission is not set in the archive 
itself). 

So I can achieve my objective if the development platform is a Mac using a 
shell command from LC.

On Linux I don’t know what shell command would work. Windows not being 
unix-based clearly requires something more than just zip to set the permissions 
in the archives of the two non-Windows standalones. The clever people at LC 
know how to set unix permissions for the unix standalones themselves from the 
Windows IDE but it's beyond my skillset I’m afraid. 

I had hoped this could all be done in LC without going to platform-specific 
tools. So the requested enhancement would be nice. But I won’t hold my breath.


___
use-livecode mailing list
use-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 Pulldownmenu button bug on Windows

[Neville Smythe via use-livecode]

The pulldownmenu bug I reported has been confirmed: bug 23693 


To remind the reader: On a Mac, when a user select a menu item from a pulldown 
menu button, the menuPick message is sent first followed by a mouseLeave 
message (generated as the mouse leaves the button rect to select the menu 
item). On Windows, the mouseLeave is sent immediately, followed by menuPick.

The Mac order is correct, the mouseLeave should be delayed until the displayed 
menu is dismissed.

Linux has the same incorrect behaviour as Windows.

The same situation applies to popupmenus and option menu buttons: the Mac has 
the correct order, Windows and Linux incorrect.

However for the combobox button, all three platforms give the wrong message 
order!

And one last twist, although the Mac implementation gives the correct order for 
3 menu buttons, it sends the mouseLeave message twice, once immediately after 
the menuPick, and then again when the mouse is released.

Neville
___
use-livecode mailing list
use-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: Zip file problem on Mac

[Neville Smythe via use-livecode]

> On 8 May 2022, at 2:00 am, Brian Milby wrote:
> 
> It is a bug somewhere. See this big report:
> https://quality.livecode.com/show_bug.cgi?id=21447 
> 
> 
> I actually think it is related. The zip should be created as a Unix variant 
> and not Fat and file attributes should be stored. One thing that could be 
> tried is to manually set the executable bit when creating the archive. I was 
> able to store a link in a zip using this method, but there is no way to read 
> the file attributes in LC.
> 

Brian, utter genius!

Not only do you pinpoint the bug — revZip is creating a ‘fat’ zip not a ‘unx’ 
zip and not adding the external attributes – but it looks like you have 
provided the workaround (for my problem of execute permissions at least)

I tried the implausible trick of using the undocumented revZipSetItemAttributes

put 0x8000 into tExtAttributes -- regular file
add 0x01ED to tExtAttributes -- rwxrwxr-x -- modify as per file (and may 
only do for Mac,Linux?)
revZipSetItemAttributes pArchive, pName, 3, tExtAttributes  — 3 for unix system

for each file as it is added to the archive. I didn’t really expect this to 
work as the file is already added to the archive in ‘fat’ format.

Not only does unzip -Z report that the archive items are now in ‘unx’ format 
with permissions rwxrwxr-x, but astonishingly the zip actually decompresses to 
a working executable – well, only so far briefly tested on a Mac but it seems 
likely this is going to work on all platforms. 

As you point out in your bug 21447 report, revZip probably won’t be able to 
decompress the archive correctly because of other deficiencies, but I only need 
the user's system to unpack it. And I will have to modify the permissions for 
each individual file in the archive. 

I never thought I would use the expression, but, like , awesome! OK sorry I 
went there, but jolly well done, that man!

Neville


___
use-livecode mailing list
use-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 Pulldownmenu button bug on Windows

[Neville Smythe via use-livecode]

Thanks Richard for your wise observations.

As cross-platform developers we do indeed need to be aware of differences that 
will arise in standalones because of GUI differences in the operating systems – 
different placement of menus, different text string lengths, some features not 
even being available. These things are largely well-known and documented with 
warnings. 

But I contend this problem is something different. Here the order of processing 
user events from an LC object is different. Although this may indeed be an 
artefact of the way the LC button menu objects are implemented, I don’t think 
the developer could be  expected to expect this, and to my mind that makes it a 
definite bug. If it occurred with more common event pairs, LC coding would be 
much more difficult.

I am not actually fussed which processing order is accepted as “correct”: 
although I expressed an IMO preference for the order as implemented on a Mac, 
the case for the opposite order is at least as strong.

My use-case was as follows. I have a pulldownmenu, not an application-wide 
menu, which applied to only certain selected items in a field. On mouseEnter, 
the selection changed colour, as a visual cue to the user that these menu items 
could be applied to the selection. On mouseLeave the colour changed back. At 
some point I inadvertently added a line of code to the mouseLeave handler which 
had the effect of killing the selection; this line was supposed to go into the 
menuPick handler. On my Mac the app continued to work as intended, but on a 
user's Windows PC the effect was to change a very minor cosmetic difference 
into a major bug because the menu no longer did anything. This was quite 
difficult to track down.

As to the priority of the bug: very low. Unless it turns to be easy to fix I 
don’t expect the inconsistency will ever be fixed even if the expert review 
agrees that it is actually a bug. Consistency of event order across platforms 
is clearly of very high importance, but this is a pretty extreme edge case, 
which only cropped up for me because of my own coding mistake. I reported it 
here because it caused me grief and I thought it of general interest. If anyone 
else is bitten and is looking for documentation, it is probably sufficient that 
the matter is now on record at least for readers of this list and in the bug 
submission.

Neville
___
use-livecode mailing list
use-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 Pulldownmenu button bug on Windows

[Neville Smythe via use-livecode]

Thanks again Richard

In my case I don’t actually need a workaround. Once I had corrected my own 
error, the only effect of the inconsistent event order is that on Windows and 
Linux the colour coding of the selection turns off a fraction of a second 
earlier than on a Mac. I am not so obsessive as to need to fix that.

Nevertheless it is conceivable, if unlikely, that someone might want to do 
something more significant in the mouseLeave handler, so I continue to call the 
inconsistency a bug. The fact that the combobox menu button behaves in the same 
way on all 3 platforms does seem to indicate that the inconsistency could be 
resolved (in favour of the Windows event order). 

But I am also not so obsessive as to expect the LC team to do a major 
architectural reset to address the issue. I have added a note to my bug 
submission suggesting a small note in the documentation for the 3 anomalous 
buttons noting how they behave slightly differently on a Mac, thus turning a 
hidden bug into a documented feature.

Neville


___
use-livecode mailing list
use-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: s it a bug?

[Neville Smythe via use-livecode]

Bob:

I'm not seeing this in the IDE or standalone. LC 9.6.7, macOS Monterey

> 
> I found one thing I think is a bug, and I'd like to report it, but I want to 
> see if anyone else thinks this may be the expected behavior: 
> 
> It seems to me that when clicking and holding the mouse button down on an 
> pulldown menu, then releasing outside that menu so that no menu item is 
> actually selected, the parameter passed to menuPick ought to be empty, if 
> menuPick even should get sent in the first place. What it actually does is it 
> passes the first menu item, even though that item was not specifically 
> chosen. 
> 
> Bob S
> 
> 
> *


___
use-livecode mailing list
use-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: char as word boundary

[Neville Smythe via use-livecode]

Jean-Jacques

In 9.6.8

 the number of chars of (numtochar(32)& numtochar(202)&numtochar(32)& 
numtochar(202)&numtochar(32)) = 5

As it should be.

Did you mean the number of words?

But then 

 the number of words of (numtochar(32)& numtochar(202)&numtochar(32)& 
numtochar(202)&numtochar(32)) = 0 (in 9.6.8)

As it should be.

Char 202 is unicode for an invisible char marking a paragraph end I believe, I 
think rarely used until recently. It has been turning up in web sites causing 
difficulty for old parsers.


Neville

> 
> Hypercard and livecode 6.7:  the number of chars (numtochar(32)& 
> numtochar(202)&numtochar(32)& numtochar(202)&numtochar(32)) = 2
> livecode 9.67  :   the number of chars (numtochar(32)& 
> numtochar(202)&numtochar(32)& numtochar(202)&numtochar(32)) = 0
> 
> Is it a change or a bug considering now numtochar(202) as word boundary, as 
> it is with numtochar(32)
> 

___
use-livecode mailing list
use-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: Property Sheet for LC

[Neville Smythe via use-livecode]

Alex wrote

> The NavBar widget has a number of properties (itemNames, itemStyle, 
> hilitedItem, itemArray, ..) which are visible in the Object Inspector, 
> but not in 4WProps.

As discussed in a post a while ago, the problem is that requesting the 
properties of a widget object returns nothing [it is supposed to return enough 
property settings to be able to completely reproduce the object]. I guess 
Richard has assumed a list of basic properties and reported those, unless he 
has more information about widgets than I know. I do the same in 
nsScriptDatabase, the current version of which will report what I am calling 
the extrinsic properties of the object such as its rect, visibility etc.  It’s 
a slightly different list from Richards, but achieves much the same result. It 
just displays the values, it does not allow setting them as does Richard's 
excellent tool, because the objective of my app is as an archive not an IDE 
tool so it doesn’t alter the inspected stack.

However nsScriptDatabase will also expose the intrinsic properties of the 
widget reported by exporting the widget, such as the itemNames of the navBar 
widget etc. 

It turns out there are sometimes other internal properties of a widget which 
are only discoverable through the manifest for the widget, which is held by the 
IDE. An example is the scaledHeight of an SVG Icon widget. The next version of 
nsScriptDatabase will display the values of these properties, together with 
their default and expected values. Further, it it will also expose the public 
handlers for the widget with their input and output parameters. I expect to 
finish coding nsScriptDatabase 2.2 in the next few days.

Neville



___
use-livecode mailing list
use-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: char as word boundary

[Neville Smythe via use-livecode]

Hmm. I jumped without thinking…I was thinking if unicode char 2029 which is the 
paragraph separator.

Unicode Char 202 is supposed to be Latin Capital Letter E With Circumflex.

But 202 is beyond the standard ascii range so the deprecated numtochar(202) 
will return an extended ascii character depending on the platform. On a Mac, 
202 is a non-breaking space which should be a word boundary (or maybe shouldn’t 
be? Looks like the LC team changed it’s collective mind). On Windows it is 
capital E circumflex, the same as unicode— I now understand your concern, 
Jean-Jacques. 

So it is a bug but as numtochar() is deprecated not one that is going to be 
fixed.

Neville


___
use-livecode mailing list
use-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: char as word boundary

[Neville Smythe via use-livecode]

Still jumping without thinking…

If native char 202 or unicode char 202 is a word boundary in Windows it is a 
real bug — but is that the case?

Native char 202, a non-breaking space, should (or maybe shouldn’t) be a word 
boundary in Mac - the docs say word boundaries are space, tab and return. 
Whether the change between versions of LC is bug or not is questionable, but 
not one which will be addressed in current versions (a deprecated bug?). One of 
course should not be using chars at all. NumtoCodepoint(202) is circumflex E on 
the Mac, and is not a word boundary, and surely that is also the situation on 
Windows.

Neville


___
use-livecode mailing list
use-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: Property sheets

[Neville Smythe via use-livecode]

I have uploaded version 2.2 of nsScriptDatabase which can display supported 
properties of widgets, with their current and default values.

There are also some bug fixes so current users should download the new version 
and update their database for those stacks which contain widgets or for which 
the bug fixes are relevant. A link to standalone versions is included in the 
new version.

Neville



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

Multiple revCursors substacks added to standalone

[Neville Smythe via use-livecode]

For a while now (LC 9.x) I have been finding that making a standalone sometimes 
adds multiple copies of revCursors to the standalone. One copy as a substack of 
the mainstack is expected, but under some unknown circumstances I get 3 more 
copies of the stack added (not as substacks). This on a Mac.

I first thought this occurred when the standalone builder reported errors about 
the ask dialog, but my last build included the extra copies without any 
warnings occurring during the build process.

The source file stack after the build has finished also has these copies of 
revCursors. I discovered this when I added the source stack to 
nsScriptDatabase. But it can also be seen in the Project Browser - a number of 
blank lines occur in the stack list tree, presumably because PB doesn’t like 
the duplicate stack names.

A difficult bug to report to Quality Control without a recipe.

Neville
___
use-livecode mailing list
use-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: nsScriptDatabase (was property sheets)

[Neville Smythe via use-livecode]

Bob S wrote
> On 11 Jun 2022, at 2:00 am, use-livecode-requ...@lists.runrev.com wrote:
> 
>  A direct link, or where to go to get it would be helpful.

The stack is in the Development section of Sample Stacks, though it seems to 
help the extraordinarily slow search engine to click All before Go. There are 
only 542 stacks listed, why does it take so long to find one? Bob and I know a 
better way, eh?

You can also download the stack and pre-build standalones from

https://www.dropbox.com/sh/6z4yuw55rnvub3t/AAB3jJ9yO4l2zCOoDq1uO7L2a?dl=0

I didn’t give the direct link in this list because I was interested in the 
number of downloads from Sample Stacks, but evidentlyI can track the number of 
accesses from my Dropbox folder.

Neville Smythe
neville.smy...@optusnet.com.au
0414517719




___
use-livecode mailing list
use-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 way to update a large DB ?

[Neville Smythe via use-livecode]

> update myDB set col1 = "blah blah", col2 = "blah blah" where id = 12345 
> limit 1
> I have a file with all the requests that weights almost 200 Mb.

Unless your "blah blah”s are very large indeed shouldn’t your change data be 
packable into a much smaller file to transmit? Eg if they were integers (or 
could be made to be integer, ie indexes into string tables)  3 integers per 
line could be packed into 13 bytes, file length 2MB. If they are short strings 
and you needed say 100 bytes per line that’s still only 20MB. Then use php - if 
you have the luxury lcserver -to unpack at the server, wrapping the long list 
of requests with BEGIN and END TRANSACTION of course.


Neville



___
use-livecode mailing list
use-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 way to update a large DB ?

[Neville Smythe via use-livecode]

Oh and you can prevent a file transfer from timing out… look up 
libURLSetExpect10

Neville



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

long id trap for the unwary

[Neville Smythe via use-livecode]

If I write

 put the long id of field 1 of card 1 into tObject; put the text of tObject

I get the text of field 1 of card 1, right ? Not necessarily.

If field 1 of card 1 is in a shared group, then what I get is the text of field 
id something of card id whatever, where whatever is the id of the current card 
or maybe the first card containing the group. 

This is not actually a bug when you read the docs carefully but it certainly is 
a trap and in my case a major bug generator. It means this seemingly obvious 
way of obtaining the long id of an object (rather, in this case an instance of 
an object)  cannot be used to uniquely identify it when getting its properties.

The workaround is to replace card id (whatever) with card id (the id of card 1) 
in tObject;  the properties of tObject returned are then the properties of the 
expected instance of the object.

Sigh, a new version of nsScriptDatabase coming up.

Neville





___
use-livecode mailing list
use-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: long id trap for the unwary

[Neville Smythe via use-livecode]

No crashes or errors, I just didn’t get back the data I expected.

Does it really have anything to do with message paths?

I just expected

the long id of field1 of card 1

to do what it says, that is, to return a specifier to (the instance of) field 1 
on card 1. At the time I was iterating through all substacks and controls in a 
stack and wanted a specifier which would work for substacks as well as objects 
so the long id was the natural choice.

I understand why the long id of a group has to contain a reference to the  
current card or the first card containing the group, but in this case I am 
actually specifying the card reference I want, so it *could* return what I 
expected, it just doesn’t. Tough cheese. (Oops, I mentioned c…..)


Neville




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

nsScriptDatabase (and long id's)

[Neville Smythe via use-livecode]

I have uploaded version 3 of nsScriptDatabase to Sample Stacks, and the 
standalones are at

https://www.dropbox.com/sh/6z4yuw55rnvub3t/AAB3jJ9yO4l2zCOoDq1uO7L2a?dl=0

This version addresses the issues with groups caused by my misplaced 
expectations raised in the thread about long id’s of grouped controls, as well 
as some more serious bugs. Existing users should read the info page accessed 
from the i button. Hopefully this version is finally fit for purpose.

Referring back briefly to that thread, which rather ran away with itself, I was 
struck once again how useful was the old version of the dictionary in which 
users could add notes to the entries, to augment, exemplify, elucidate or even 
correct documentation. In this case I would have added to the long id entry a 
note to the effect that the paragraph concerning the long id of a group also 
applied to the long id of controls contained in groups, even if the group was 
not explicitly mentioned. Did that feature disappear just because of the new 
implementation of the Dictionary, or was it killed because it needed moderation?

Neville




___
use-livecode mailing list
use-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: Is LC encryption different for Mac than for Windows??

[Neville Smythe via use-livecode]

Is socketTimeOut set high enough?


Neville


___
use-livecode mailing list
use-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: Is LC encryption different for Mac than for Windows??

[Neville Smythe via use-livecode]

Bob Sneider wrote
> So strange. I built in some logging, removed the base64 stuff, and now it 
> works! Timing problem of some sort? Who knows. 

That’s what I was inferring. I’d suggest you increase socketTimeOut to avoid 
the problem recurring (or reduce it if you want to test that timing was the 
problem!)

It may well be that

> A socket is a socket

but performance ain’t performance

Neville

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

SVG Icon tool query

[Neville Smythe via use-livecode]

Many thanks to Brian for sharing the fantastic collection of icons included in 
this tool. Can I enquire as to the copyright status of the images?

Neville



___
use-livecode mailing list
use-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: Standardize Font Appearance

[Neville Smythe via use-livecode]

Standardising fonts, so that one would no longer have to check that every label 
and field carefully crafted on the Mac to fit text precisely would not have 
missing pixels or whole words wrapped out of sight on Windows because of 
different font metrics, sounds like a great idea. But the reality of the way 
systems render fonts seems to complicate things:

I set up a test standalone with the Google fonts NotoSans-regular.ttf and 
NotoSerif-regular.ttf installed. A label and and single line text field were 
set up to be exactly the right size to fit some text using Arial font on a Mac 
(Monterey). Then the labels and field were set to use NotoSans or NotoSerif 
fonts.

There does still appear to be a small difference in the baselines for the two 
fonts between Mac and Windows, possibly more than the difference between Arial 
on the two platforms, so that I think pixels could be cut off under some 
circumstances. Bizarrely there is a bigger difference between NotoSerif as 
rendered on Monterey and High Sierra — on High Sierra the space character seems 
to be more compressible when the system tries to fit a right-justified label 
into a given length - or possibly the 8pixel margins are honoured on High 
Sierra, whereas on Monterey the text just overwrote the left margin?

When it comes to Linux (Ubuntu) however everything came unstuck. The NotoSans 
text renders much wider, wrapping the final word of a piece of text to the next 
line. At least I think it is using NotoSans: LC lists the NotoSans and 
NotoSerif files as in use, but the Serif font just doesn’t render at all (that 
is, it does not change the displayed text)! It could be the system is 
substituting another font entirely for NotoSans, and not recognising NotoSerif 
[does the font have to be set to NotoSerif-regular on Linux rather than 
NotoSerif??]. 

I need to make a more detailed comparisons. I presume the LC text measurement 
functions return the exact pixel height and width that the text will use when 
rendered by the iterating system, but can I get the bottom-right of its rect? 
And the actual font the system will employ?

Neville




___
use-livecode mailing list
use-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: Standardize Font Appearance

[Neville Smythe via use-livecode]

Consulting the dictionary would have helped me (in this case!): 

measureText(text,field,bounds) 

should give me what I need to make precise comparisons of how the various 
operating (iterating?!!!) systems will render my fonts. I will report back

Interesting idea, Richard, to use images for all labels. I presume you automate 
the export process, it would seem to be rather large task when one can have 
hundreds of label fields. And it wouldn’t work for fields with dynamic content.

Neville




___
use-livecode mailing list
use-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: Standardize Font Appearance

[Neville Smythe via use-livecode]

So I have conducted a more careful test of the proposed method of standardising 
fonts across platforms, that is, installing some Google fonts in the standalone 
for use in labels and fields, with the objective of setting the rects of 
objects on the development platform and having the same appearance on all 3 
platforms: no more missing pixels or wrapped words because of the differences 
in fonts between the platforms.

Unfortunately the method does quite not give the hoped-for solution. Even 
though the fonts supposedly have the same metrics, the appearance still differs 
between platforms. For both NotoSans and NotoSerif I find the baselines differ 
by one or two pixels between Mac Monterey and Windows (which I don’t really 
understand, since the ascent is built into the font, but nevertheless becomes 
different when rendered). The pixel lengths of the tested strings were the same 
however: allowing just a couple of extra pixels height should be sufficient in 
these cases. However on Linux (Ubuntu), while the baselines were the same, the 
length of rendered strings differed markedly, in one test case wrapping a 
trailing word out of sight. And a nasty surprise, the text length on Mac High 
Sierra was 8% longer than on Monterey!

So I’m afraid one must still write once, test everywhere. 

Neville




___
use-livecode mailing list
use-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: Standardize Font Appearance

[Neville Smythe via use-livecode]

Actually it is possible to ensure the baselines of fields are consistent across 
platforms without having to use conditionals.

From experimentation it appears that the baseline is given (relative to the top 
of the field) by 

the top margin - 3*fontAscent/4 -1

 where the fontAscent is  item 2 of  measureText(text,fld,”bounds”) (note this 
is a negative number; in macOS it is the traditional font ascent, in Windows I 
think it is the traditional font top )

Since the bottom margin is ignored in this placement, we can force the baseline 
to be at the bottom margin as follows:

put the margins of fld  “foo" into tMargins
put item 4 of tMargins into tBottomMargin
put measuretext(fld “foo",fld “foo",bounds) into tFontInfo
put 1 + the height of fld “foo” - tBottomMargin + round(3*(item 2 of 
tFontInfo)/4) into tTopMargin
put tTopMargin into item 2 of tMargins
set the margins of fld “foo" to tMargins

The pixel length of text however cannot be made consistent across platforms, 
and one can only allow some extra padding to make sure the text appears 
unmangled.  My very limited experiments with just the fonts NotoSans and 
NotoSerif at textSize 13 and  the text “A standard label:” indicate that
Mac Monterey and Windows 10 : text widths are the same
Mac High Sierra : about 8% longer
Linux Ubuntu: about 15% longer (!!)

Other fonts differ more widely between platforms and system versions (perhaps 
most weirdly 13pt Times on the Mac looks like 9pt)

Neville Smythe




___
use-livecode mailing list
use-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: Standardize Font Appearance

[Neville Smythe via use-livecode]

I agree Quentin, trying to make text appear exactly the same on all platforms 
is a fools errand.

That however is not the main point of the exercise, at least for me. When 
designing an apps interface, it would be good to know that (at least static) 
text items will (probably) appear in the same font style and height and the 
text is all visible: no pixels obscured at top or bottom or left or right, no 
unintended word-wrapping, and not too close to other objects such as a field 
border. 

Including one’s own fonts such as Google fonts, which are probably not in the 
user’s default system setup — on a desktop at least, and setting the baseline 
as in a previous post, would seem to be a useful addition to the production 
process  (and may even achieve precise equality between Monterey and Windows 10 
if my early experiments hold true! ). 

But  the most important parameter is of course the text length. The usual 
mantra is to add about 10% extra padding to the field length. I intend to set 
up a database for a range of fonts and platforms to check just what extra 
length is really needed (is that figure of 15% for Linux I quoted actually 
correct, it sounds unbelievable). I have access to Mac Monterey, Mac High 
Sierra, and Windows 10 and Ubuntu via Parallels.  Once done I will publish the 
database. Hopefully someone could then add data for Window 11 for example ( and 
iOS and Android)

Finally a couple of other comments about fonts on Monterey. I mentioned Times 
on the Mac being weirdly small. Turns out Times is no longer included in 
Monterey although it will recognise a scripted setting to Times ; if you set 
text to 13pt Times it seems the system substitutes Times New Roman 11pt (which 
looks like 9pt in any other font). 

And if you set the text to the (Default) font then changes to the textSize of 
the field have no visible affect, what you get is the default system font at 
its default size (SF Pro 12pt) 


Neville




___
use-livecode mailing list
use-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: Cross-platform font handling, and why you don't want to do it

[Neville Smythe via use-livecode]

Bob Sneider wrote:
> The fonts do not get included in a MacOS standalone


embedding fonts in a Mac standalone worked fine for me. Have you checked that 
the fonts are actually in /Contents/Resources/_MacOS/ and your file 
path when loading is correct

On the IDE problem
> when I quit Livecode, then relaunch it and open the stack, all the text of 
> the labels appear out of alignment!

 sounds like a timing problem about what resources are available when LiveCode 
launches and your stack gets to do its font loading (in a pre-open stack 
handler?) and that the timing on Windows launch is just different.

Neville Smythe




___
use-livecode mailing list
use-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: Standardize Font Appearance

[Neville Smythe via use-livecode]

I have enough datapoints to report some findings from my comparison of the 
appearance of fonts across platforms, in particular on the length of strings in 
fields and text baselines, and to correct some of my previous statements. My 
intention is to compile a database for some 7000+ fonts in 7 different font 
sizes ranging from 9pt to 18pt on Mac Windows and Linux system; but for now 
(for reasons given below) I looked at four basic fonts in common use: Arial, 
Times New Roman, Noto Sans and Noto Serif.

The good news is that the horrible problem of different strings lengths is no 
longer a problem, as long as your target platforms are just Mac or Windows 10. 
For each of these four fonts, strings in (right or left justified) fields have 
the same rendered length (they differ between fonts of course). I would be 
confident that holds for all TrueType fonts installed on these platforms, 
starting from the advent of Windows 10. My former claim about a difference 
between High Sierra and Monterey on the Mac is incorrect, the result of a 
coding error. Of course the field or stack must have a font assigned: leaving 
the font to empty will result in the system using its own font, which will be 
consistent with the look-and-feel of the platform/system version, but which 
will certainly be quite different between platforms.

On LInux (Ubuntu 18.x) however, string lengths for all the fonts in all sizes 
are quite different, sometimes longer and sometimes shorter than on the other 
platforms. The biggest difference was for Noto Sans 9pt, the sample Linux 
string being 14% longer; this was an outlier, mostly the Linux strings were 
less than 8% longer. In the other directions was Arial 15pt, where Linux was 5% 
shorter. So if Linux is a target platform, allow some extra length for your 
fields (on the right  for a left justified field, on the left for a right 
justified label).

A more difficult problem is the vertical placement of text. With the default 
settings for fields, strings in Windows will typically appear 2 or 3 pixels 
lower than on a Mac, which can mess with your layout — text carefully 
positioned on one platform will appear too close to nearby objects on the 
other, or will not align with text in adjacent fields. This can be fixed by 
adjusting the topMargin of the field, but the details are not straightforward..

The baseline for rendered strings is determined by the font metrics and the 
font size; unfortunately Mac Windows and Linux all use different metrics from 
each other. It would be nice if LC had a function which returned the baseline 
for the rendered string, but I couldn’t find such a function. The closest 
formula I can get is (for text using the textFont and textSize of the owner 
field, and consigning to oblivion the formula I had previously proposed which 
was caused by the aforementioned error plus a glitch in the data processing 
unit, ie my brain.)

 first baseline relative to the top of the field = the topMargin of the 
field + fontAscent - 6
 where
fontAscent = - (item 2 of measureText(fld ,fld ,”bounds”)

Why the magic number -6? It seems this places text in a common font such as 
Time New Roman or Arial in medium range textSizes such as 11 to 15 so that the 
top of the lower case character “x” is at ...approximately... the topMargin of 
the field. This would be the ideal placement for text at all fonts and sizes, 
but of course in general 6 is nothing like the difference between the 
fontAscent (the height of the capital “A” above the baseline) and the height of 
“x”, and anyway the fontAscent is not the actual height of the font, so for 
other sizes and fonts the placement is wildly different from the ideal. The 
simplification is probably a legacy of a decision originally made for speed 
given the complications of dealing with different font formats; a correction 
now would break all existing stacks.

Actually while my formula fits precisely most of the time, it occasionally is 
out by 1 pixel. And that precision holds for all fonts I have looked at, even 
for the gorgeously extravagant Zapfino at 64pt. So the discrepancy is probably 
some floating point rounding from the correct formula. If anyone (LC 
engineer’s?) can provide the correct formula that would be nice, but I have the 
feeling it may involve a font metric not directly exposed by the LC api.

The formula can be used to adjust the topMargin so that the baseline is fixed, 
to within 1 pixel anyway The adjustment would have to be done at runtime, or 
applied to a stack before building a standalone for a particular platform, 
using a pre-cooked fontAscent. Hence my database project. Just at the moment 
this has hit a bit of snag: as far as I can see, fonts have to be added to 
Windows 10 one at a time -- on a Mac you just dump a folder of fonts onto Font 
Book. Does anyone know how to do this in Windows and Linux? If necessary, 
following Ralph’s post I believe I could work out where the Mac and Windows 10 
sy

Re: Standardize Font Appearance

[Neville Smythe via use-livecode]

I agree Richard text management is a lot better than it used to be but problems 
remain. 

Text strings on Windows standalones used to be longer than on Mac. It was a 
painful process to find a label which had been clipped in Windows, fix it in 
the Mac IDE, compile, copy to a Windows box, only to find another label that 
hadn’t been supplied with enough padding so back the drawing board. If you were 
developing on Windows you didn’t see this problem, since Mac strings were 
shorter. I am pretty sure this problem has gone away, strings rendered in a 
TrueType font on Mac and Windows now have the same length. [Was this really a 
fix in LC, or a change in the Windows 10 font engine? If the LC team did it I 
am lost in admiration, a fantastic piece of work! I thought LC just left it to 
the operating system to draw the text.] On Linux however the problem remains, 
strings can be longer or shorter than on the other platforms.

Vertical placement is the remaining problem: strings in Windows typically 
appear 2 or 3 pixels below the Mac equivalent. Mostly this is a trivial 
problem. But it can cause havoc if your interface has closely packed items. I 
offer the following fable as a demonstration.

I am working on a Mac, designing an app for deployment on Mac and Windows. I 
select a stock-standard label object, drawn as a box with a border thickness 1 
pixel. If I leave the default font to (Message) then the fonts used will be 
different on the two platforms, and I don’t want that. I have a fondness for 
smallish 12pt labels and Times New Roman font. Shouldn’t be a problem since 
Times New Roman exists on Windows (not on Linux of course). They won’t look 
*exactly* the same because the device resolutions and antaliasing algorithms 
are different etc, but only a perfectionist would care, and I know the text 
won’t be clipped because the lengths are same (not on Linux of course, even if 
I instal Time New Roman) Hmm, the text, which was nicely vertically centered in 
its box, has moved up a bit, I wonder why? Easily fixed, just set the top 
margin to 9, yes that is just right. Now  I need a text field next to my label, 
with the baseline of the text aligned with the label text. But the font for 
this field has to be different, say Arial 36pt (Arial is course is installed on 
Windows. Not on Linux of course.). Gee, the text which was pretty much aligned 
is now way out of kilter. There is no IDE command to align text, but easily 
fixed, just move the field up a bit. Finally I want to draw a red line just 
under the two text strings, at the point where LC would draw text baselines.

You can see screen grabs of the resulting Mac and Windows standalones at
https://www.dropbox.com/s/v2hzwe159ep6nep/My%20beautiful%20app%20on%20Mac.png?dl=0
 


https://www.dropbox.com/s/wr2limdozwob9v7/My%20beautiful%20app%20on%20Windows.png?dl=0
 


Or you can read the reviews from the influential Good Design Now! magazine

Mac review: Everything looks fine. Simple, boring interface. -1 for the retro 
box and -1 for mixing fonts. 3 stars.

Windows review: Wow! Quirky unbalanced placing of the label in its box. 
Fashionable haphazard alignment of text. And an ultramodern red line slashing 
through the text. An (unintended) brilliancy. 5 stars. (But if that red line 
had been a more substantial object, text would have been clipped, 0 stars.)

Neville


___
use-livecode mailing list
use-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: Standardize Font Appearance

[Neville Smythe via use-livecode]

Thanks Richard for your comments. Interesting to see comments about font drift 
in a general context

The problems is however not fixed if you add Google fonts to your standalone. 
The problem could probably be fixed (on Mac and Windows anyway) by hacking the 
fonts to change their metadata tables but that is getting into really deep 
water, and may even violate copyright. 

The core of the issue is what I think is a design flaw in the way LC places 
text when it asks the platform OS to render the string.

Experiment 1: Create a standard field. Set the properties to non-3d, draw 
borders with thickness 1 so we can judge the vertical placement. Type the text 
“A standard label”. Set the field font to Arial so we can compare the results 
on Mac and Windows.

Result: On the Mac and Windows we get subtly different results. On Windows the 
capital “A" appears centered in the box; on the Mac the lower case letters 
“san" appear centered. Which means the Windows string is lower than the Mac 
string. As an initialisation of the new field it looks OK on both IDEs. But as 
we have seen we get into trouble when the text uses other fonts or sizes or if 
it interacts visually with nearby objects.

Experiment 2: Now change the font size to 64pt. 

Result: The text disappears. It is now placed way below the bounding box, and 
it is a bit of a hassle to get it back into view. That is a terrible user 
interface. 

The nicest user experience would be if the newly sized string appeared with the 
same baseline as the initial string, and that would certainly make alignment of 
text easier. However, that model wouldn’t quite fit the LC field model with a 
user-settable top margin, as it would necessitate overriding the top margin. If 
the top margin is to be honoured, the two obvious choices are to place the text 
so the top of the capital A appears at the bottom of the top margin (perhaps 
the Windows viewpoint?) or if the top of the lowercase letters appear at the 
top margin, allowing cap letters and risers such as h to bleed into the top 
margin (let us call this the Mac viewpoint). But neither of these two are what 
actually happens.

I can confirm that LC actually places the text (the first line, for a field 
with fixedLineHeight false - that is another story) so that the baseline is set

top margin of the field + fontAscent of the font - 6

pixels below the top of the field. This formula holds precisely over all the 
fonts and sizes I have tested and on all 3 platforms.

It appears what was intended, probably way back in Hypercard when fonts were 
bitmaps, was to drop the string below the top margin by the height of capitals 
(the ascent) and then pull back by 6 pixels so that the top of the lowercase x 
is at the top margin (the Mac viewpoint). It works well enough on the common 
initial fonts and sizes for fields because  6 is about the difference in letter 
heights at these sizes.

However the fontAscent returned by measureText is quite evidently not the 
height of the letter A above the baseline, it is more like the maximum font 
height above the baseline, so the string disappears in Experiment 2. And the 
two platforms return different values for fontAscent anyway, leading to the 
alignment problems in Experiment 1. Furthermore that constant 6 is of course 
grossly wrong for other font sizes. What was meant surely was

 top margin + x-ascent of the font

(Which was possibly computational more expensive bearing in mind various font 
formats?)

It would now be impossible for LC to change how it places text in fields, to 
either the Mac or Windows viewpoint, because that would break every stack 
having a text field!

What could be done however would be to add a couple of field properties which 
would enable baselines to be aligned, as I suggested in a previous post.

Neville


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