Re: LC subscription and special characters

[jbv via use-livecode]

Thank you for your reply.
Obviously, it was possible in earlier versions of LC.

So, could someone be kind enough to make a quick test with the most 
recent versions of LC, by typing text inside a field, if special 
characters can be used, like alt+144 for É, and possibly on azerty and 
qwerty keyboards ?

Thank you in advance.

Le 2022-05-10 17:53, Paul Dupuis via use-livecode a écrit :

I thought I recalled a bug in the LC engine where using the keyboard
method of typing the character code, press ALT, and then press X. For
example, to type a dollar symbol ($), type 0024, press ALT, and then
press X, didn't work in Livecode. However, I just tried searching the
Livecode Quality Center for a bug number and couldn't find it so
perhaps I am mis-remembering.



___
use-livecode mailing list
use-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: use-livecode Digest, Vol 224, Issue 8

[Bob Sneidar via use-livecode]

You can read for x characters then check the result for empty. So no you do not 
need to read the entire file into memory. 

Bob S


> On May 10, 2022, at 12:14 , Mark Clark via use-livecode 
>  wrote:
> 
> Thanks Tom, Mike and Craig. Sorry for the late response, I’m on the digest 
> version.
> 
> My thought was that an open file for read does not require placing the whole 
> file into memory. Am I mistaken in that assumption? Seems like it would be 
> nice to not use all of the available memory to run the decrypt. Results below 
> seem to confirm this...
> 
> I worked up a quick stack using the chunking notion I referenced in the 
> original post and this seems to work fine. I compressed the Mac system folder 
> on an old SSD. That directory was 8.9GB on disk. Compressing it with the 
> Finder took about 28 minutes. Compressed size was 5.9GB.
> 
> Using a byte range of 1048576 (1MB—small but useful for testing), I was able 
> to read the source compressed file, encrypt and write to the new (encrypted) 
> file in about 2 minutes. Decrypt took a little longer (less than 3 min). 
> Memory utilization (I did a quick build of the stack) was 44-45MB during both 
> operations. I’ll bump up the byte range and see how that compares. 
> 
> 
> 
> Thanks,
> Mark
> 
> 
>> On May 10, 2022, at 11:00 AM, use-livecode-requ...@lists.runrev.com 
>>  wrote:
>> 
>> there is no way to decrypt something that does not fit in memory. with 64
>> bit builds the limit is whatever the motherboard  supports.   on 32 bit
>> builds the limit is whatever the os will allow 1 process to have,
>> but then u need memory to store the decrypted data too.
>> you can use a command line program to outsource that work and memory
>> management.
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

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

Re: LC subscription and special characters

[Paul Dupuis via use-livecode]

I thought I recalled a bug in the LC engine where using the keyboard 
method of typing the character code, press ALT, and then press X. For 
example, to type a dollar symbol ($), type 0024, press ALT, and then 
press X, didn't work in Livecode. However, I just tried searching the 
Livecode Quality Center for a bug number and couldn't find it so perhaps 
I am mis-remembering.


On 5/10/2022 2:33 PM, jbv via use-livecode wrote:

Hi list,
I have been asked by a client to make some upgrades to a standalone 
app that I built with LC 6.5 about 12 years ago.
The app is a front end for managing a remote DB on a server. The DB 
content is roughly 90% in french, and the rest in english and german. 
It has about 16 entries and counting.


I am about to buy a LC standard plan for both Mac and Win, since the 
app is been used on both platforms, and will also be in the future.
But before I proceed, I'd like to make sure that it will help solving 
a minor problem that users have met lately.


Last year a re-compiled the app, without changing anything, with a LC 
8.2 Community version.
It keeps running fine on both Win & Mac, except that on Windows, some 
special characters in french (like Ê or Æ or Œ) have become impossible 
to type with regular keys combinations (or any other mean), when it 
was possible before with the LC 6.5 version.
Furthermore, a few new users will be added to the crew, who will work 
with qwerty keyboards, when the rest of the staff will continue to 
work with azerty keyboards.


So finally my question : it seems that the standard plan is the best 
option because it will give me access to the latest LC versions, but 
what about these special characters issue ? Is it only related to LC 
8.2, or will it also occur with the latest versions ?


Thanks in advance.
jbv

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

http://lists.runrev.com/mailman/listinfo/use-livecode



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

Re: Re Pulldownmenu button bug on Windows

[Richard Gaskin via use-livecode]

What a very kind thing of you to say. Thank you.

After 30 years as a recipient of so much wisdom and lore shared with me, 
I've felt compelled to share some of that forward. In recent years most 
of what I write seems ignored, so I've been spending my time elsewhere. 
Your encouragement may see me checking in on LC stuff more often. Thank you.


--
 Richard Gaskin
 Fourth World Systems


Craig Newman wrote:


Richard.

So glad to have you in this world.

Craig


On May 7, 2022, at 5:35 PM, Bob Sneidar via use-livecode  wrote:

Well put. I wonder what the real world effect of the order of messages is, and 
whether or not it could be compensated for by send in time?

Sent from my iPhone


On May 7, 2022, at 13:44, Richard Gaskin via use-livecode  wrote:

It's definitely an inconsistency, but the bug's status as requiring "EXPERT REVIEW" prompts us to 
consider why these differences exist, and which, if any, should be considered "wrong" or 
"right".  It may not be as simple as it seems at first glance.


Background:
--
MetaCard (the engine we now call LiveCode) was born on Unix, later ported to 
Windows, Linux, and then MacOS.

On all platforms menus are implemented as selector buttons, buttons which 
provide the appearance and behavior of OS-provided menu objects.

And until the port to MacOS, all platforms behaved consistently.

So why the Mac change?

Mac is unique among popular GUI OSes in its use of a global menu bar, attached 
to the top of the display; other OSes place the menu bar attached to the top of 
the window.

Internally, LC menus are implemented as temporary dynamically-instantiated 
nameless stacks, which may seem counterintuitive until you realize that a menu 
is in essence a highly specialized form of window, a viewport independent of 
other windows with its own buffer, contents, and like all windows needs to use 
a common compositor for rendering them all together. (Indeed you can even use 
stacks as menus explicitly when you need a non-standard look, like a graphical 
picker, but that's another topic).

So the engine's method of using a subclass of the stack object for rendering 
menus worked well and consistently for a great many years - until the port to 
MacOS.

The Mac global menubar required a deep rethink on how menus are handled, not 
only in terms of detaching them from the window but also in terms of the 
nuances of display and interaction.

So Dr Raney special-cased menus on MacOS, so the engine uses OS routines to 
render those, fed by the menu button properties for things like the menu name 
as parameters to those OS routines. On every other platform you're interacting 
with a LiveCode object, but on Mac you're interacting with a system object into 
which the engine has inserted some hooks to tie it in with your scripting so 
you can at least know when an item has been selected.

This rewiring of properties and messages is no small feat, and has pervasive effects.  So from time 
to time you'll find Mac-specific things needed to conform to that platform like adding an 
"About" item to a menu that doesn't exist in your stack (the Mac's 
"Application" menu belongs to the OS).

It's not surprising that messages related to menu objects also have some 
inconsistencies along with everything else.

If we consider that on all other platforms the menu object we're interacting 
with is a button, and the menus that appear are a stack, the messaging you see 
with Windows and Linux is consistent with other button object messaging: once 
the mouse leaves the control the mouseLeave message is sent.

On Mac we have an exception to LC's normal button messaging because we're not 
interacting with an LC button at all, but with a system object, into which the 
engine devs have grafted just enough messaging to trigger actions from scripts.

I have no opinion on qualitative labels like "right" or "wrong" on this; that 
seems a matter of personal familiarity and taste. It may even be somewhat philosophical: is a menu 
a single thing that expands, or two things (menu and items) where one triggers the appearance of 
the other?

All I can do is help describe the under-the-hood parts to help makes sense of 
how the difference came about.



The Here-And-Now:

Whether or not we prefer it, the menu architecture is what it is, at least at 
the moment. Changing the behavior on all other platforms to be like Mac, or Mac 
to be like all other platforms, would be a scope of work that I'd guess the 
team would not be in a position to make a priority any time soon, even if they 
felt strongly about this one way or another.

They have a lot on their plates, and for all the questions we see regarding Mac-specific menu differences 
(like the auto-migration of the "About", "Help" and "Preferences" items to 
system menus separate from the menu objects where we're asked to put them), I can't recall seeing a message 
here before about mouseLeave.

I'm not saying it isn't important. It might we

Re: Decrypting (and encrypting) Large files

[Richard Gaskin via use-livecode]

Mark Clark wrote:

> Wondering if anyone has used LiveCode for encrypting-decrypting large
> files?
...
> I’m thinking about using LC for decrypting zip compressed log files
> that can be multiple gigabytes in size. I’d like to use just LC vs.
> resorting to shell if possible.

What is behind the preference to roll your own rather than call existing 
purpose-built command-line tools from LC with shell()?


Your chunking described in your latest post seems the way to go, AFAIK 
pretty much how other tools would handle it.


Another option:  if you're in an environment where even log files 
require strong encryption, could you pipe log data to a separate secured 
log server instead?


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

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

Re: use-livecode Digest, Vol 224, Issue 8

[Mark Clark via use-livecode]

Thanks Tom, Mike and Craig. Sorry for the late response, I’m on the digest 
version.

My thought was that an open file for read does not require placing the whole 
file into memory. Am I mistaken in that assumption? Seems like it would be nice 
to not use all of the available memory to run the decrypt. Results below seem 
to confirm this...

I worked up a quick stack using the chunking notion I referenced in the 
original post and this seems to work fine. I compressed the Mac system folder 
on an old SSD. That directory was 8.9GB on disk. Compressing it with the Finder 
took about 28 minutes. Compressed size was 5.9GB.

Using a byte range of 1048576 (1MB—small but useful for testing), I was able to 
read the source compressed file, encrypt and write to the new (encrypted) file 
in about 2 minutes. Decrypt took a little longer (less than 3 min). Memory 
utilization (I did a quick build of the stack) was 44-45MB during both 
operations. I’ll bump up the byte range and see how that compares. 



Thanks,
Mark


> On May 10, 2022, at 11:00 AM, use-livecode-requ...@lists.runrev.com 
>  wrote:
> 
> there is no way to decrypt something that does not fit in memory. with 64
> bit builds the limit is whatever the motherboard  supports.   on 32 bit
> builds the limit is whatever the os will allow 1 process to have,
> but then u need memory to store the decrypted data too.
> you can use a command line program to outsource that work and memory
> management.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

LC subscription and special characters

[jbv via use-livecode]

Hi list,
I have been asked by a client to make some upgrades to a standalone app 
that I built with LC 6.5 about 12 years ago.
The app is a front end for managing a remote DB on a server. The DB 
content is roughly 90% in french, and the rest in english and german. It 
has about 16 entries and counting.


I am about to buy a LC standard plan for both Mac and Win, since the app 
is been used on both platforms, and will also be in the future.
But before I proceed, I'd like to make sure that it will help solving a 
minor problem that users have met lately.


Last year a re-compiled the app, without changing anything, with a LC 
8.2 Community version.
It keeps running fine on both Win & Mac, except that on Windows, some 
special characters in french (like Ê or Æ or Œ) have become impossible 
to type with regular keys combinations (or any other mean), when it was 
possible before with the LC 6.5 version.
Furthermore, a few new users will be added to the crew, who will work 
with qwerty keyboards, when the rest of the staff will continue to work 
with azerty keyboards.


So finally my question : it seems that the standard plan is the best 
option because it will give me access to the latest LC versions, but 
what about these special characters issue ? Is it only related to LC 
8.2, or will it also occur with the latest versions ?


Thanks in advance.
jbv

___
use-livecode mailing list
use-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: Decrypting (and encrypting) Large files

[Mike Kerner via use-livecode]

I don't think you're necessarily going to be limited by physical memory, as
the computer will have  a certain addressing space in VM, as well, right?

On Mon, May 9, 2022 at 2:42 PM Craig Newman via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Ah, I see.
>
> I did not appreciate that the dataset could be in the many gigabytes.
>
> Craig
>
> > On May 9, 2022, at 12:42 PM, Tom Glod via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > there is no way to decrypt something that does not fit in memory. with 64
> > bit builds the limit is whatever the motherboard  supports.   on 32 bit
> > builds the limit is whatever the os will allow 1 process to have,
> > but then u need memory to store the decrypted data too.
> > you can use a command line program to outsource that work and memory
> > management.
> >
> > On Mon, May 9, 2022 at 9:44 AM Craig Newman via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> >> I believe that there is no upper limit to the size of a variable in LC.
> So
> >> I am with Mike here. What makes you nervous about dealing with a large
> >> dataset within LC itself?
> >>
> >> Craig
> >>
> >>> On May 9, 2022, at 8:49 AM, Mike Kerner via use-livecode <
> >> use-livecode@lists.runrev.com> wrote:
> >>>
> >>> have you tried ti? i have not run into a situation where a variable was
> >> too
> >>> big.
> >>>
> >>> On Sun, May 8, 2022 at 6:46 PM Mark Clark via use-livecode <
> >>> use-livecode@lists.runrev.com> wrote:
> >>>
>  Wondering if anyone has used LiveCode for encrypting-decrypting large
>  files? The docs typically have nice examples for files that can fit
> >> into a
>  variable, but what are folks doing for big files that are larger than
> >> what
>  you’d want in a variable? I’m thinking about using LC for decrypting
> zip
>  compressed log files that can be multiple gigabytes in size. I’d like
> to
>  use just LC vs. resorting to shell if possible.
> 
>  Likely need a hash value to compare the decrypted output against the
>  original as well. I’m thinking some variation along the lines of open
> >> file
>  x for read, reading some manageable chunk into memory, decrypting a
>  portion, writing that to disk and repeat. But that seems too simple.
> >> Think
>  we need AES 256. Any shared experience much appreciated.
> 
>  Thanks all,
> 
>  Mark
>  ___
>  use-livecode mailing list
>  use-livecode@lists.runrev.com
>  Please visit this url to subscribe, unsubscribe and manage your
>  subscription preferences:
>  http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> >>>
> >>>
> >>> --
> >>> On the first day, God created the heavens and the Earth
> >>> On the second day, God created the oceans.
> >>> On the third day, God put the animals on hold for a few hours,
> >>>  and did a little diving.
> >>> And God said, "This is good."
> >>> ___
> >>> use-livecode mailing list
> >>> use-livecode@lists.runrev.com
> >>> Please visit this url to subscribe, unsubscribe and manage your
> >> subscription preferences:
> >>> http://lists.runrev.com/mailman/listinfo/use-livecode
> >>
> >>
> >> ___
> >> use-livecode mailing list
> >> use-livecode@lists.runrev.com
> >> Please visit this url to subscribe, unsubscribe and manage your
> >> subscription preferences:
> >> http://lists.runrev.com/mailman/listinfo/use-livecode
> >>
> > ___
> > use-livecode mailing list
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>


-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode