date:20200406

Andre Garzia wrote:

> I just reinstalled LC and Devolution here but every time I try opening
> any of the panes, it does an audible chime. Trying to click any of the
> tabs in the first pane (the one with about, check for updates, etc)
> just sounds the chime and doesn't change anything. It feels like there
> is a modal somewhere offscreen and I can't click it.

I've seen reports in the forums about dialogs opening behind palettes in 
recent versions of LC, unrelated to devolution.

Devo rarely does anything modal, but if perhaps you clicked something 
that opens a file picker, if you're seeing the same LC bug others have 
seen in other contexts, it may be the getfile dialog is opening behind 
the pane.

Just a hunch.  Haven't seen this yet, but if you can tell which OS 
you're on I'll see if it's possible to reproduce it here.

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

Devolution bug

2020-04-06 Thread Andre Garzia via use-livecode

Hi Folks,

I just reinstalled LC and Devolution here but every time I try opening any
of the panes, it does an audible chime. Trying to click any of the tabs in
the first pane (the one with about, check for updates, etc) just sounds the
chime and doesn't change anything. It feels like there is a modal somewhere
offscreen and I can't click it.

Best
Andre

-- 
http://www.andregarzia.com -- All We Do Is Code.
http://fon.nu -- minimalist url shortening 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: ANN: glx2 script editor 4.0

Mark has identified some anomalies and is presently working on it.

Bob S


On Apr 6, 2020, at 4:48 PM, Andre Garzia via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

I'm also experiencing some oddities with GLX2 4.0.1 here.

I've uploaded a screenshot to:

http://andregarzia.com/img/shots/glx2/glx2-strange.png

* The GLX2 bar is misplaced and even though it moves when I move the main
LC menu, it moves to the wrong location.
* The menubar in the GLX2 script editor has wrong colors and can't be read.
* The handler columns is too small.

Those are the main issues I noted so far.

Best
Andre

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

Re: ANN: glx2 script editor 4.0

2020-04-06 Thread Andre Garzia via use-livecode

I'm also experiencing some oddities with GLX2 4.0.1 here.

I've uploaded a screenshot to:

http://andregarzia.com/img/shots/glx2/glx2-strange.png

* The GLX2 bar is misplaced and even though it moves when I move the main
LC menu, it moves to the wrong location.
* The menubar in the GLX2 script editor has wrong colors and can't be read.
* The handler columns is too small.

Those are the main issues I noted so far.

Best
Andre

On Mon, 6 Apr 2020 at 21:39, matthias rebbe via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Mark,
> where do you want feedback? I place it here for now.
>
>
> Tested now with LC 9.5.1, 9.6.0DP3 on Mac OS 10.14.6 with two displays.
>
> 1. the GLX2 bar is not under the LC menubar. It´s placed on the right of
> the screen
> see https://livecode.dermattes.de/screenshots/glx2_bar.png
>
>
> And it  seems that GLX does not write back the preferences or maybe some
> of them back to the prefs file.
>
> 2. tried to set to chalkboard, but that was not saved. I had to change the
> GLX2 Code Prefs.txt file in an editor while LC is not running to get
> Chalkboard working
>
> 3. setting the font size does also not work
>   even after changing the size manually in the editor (while LC is not
> running) does not work. I need also to open the GLX preferences once in LC
> and then  the font size changes in GLX
>
> 4. when GLX2 is first opened then a menu is visible in GLX
> see https://livecode.dermattes.de/screenshots/glx2_menu_visible.png
>
> when i click onto any of the menu items then the menu disappears
> see https://livecode.dermattes.de/screenshots/glx2_menu_hidden.png
>
>
> Matthias
>
>
> -
> Matthias Rebbe
> Life Is Too Short For Boring Code
>
> >
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>


-- 
http://www.andregarzia.com -- All We Do Is Code.
http://fon.nu -- minimalist url shortening 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

Apps to fight COVID-19

2020-04-06 Thread Dar Scott Consulting via use-livecode

Hi, everybody!

I apologize for the drive-by email. 

And I miss everybody on the list. Been busy all that.

I am a strong believer in contact tracing as an implortant part of COVID-19 
containment.

There are several teams out there working on voluntary privacy-protecting 
contact tracing apps to deploy before Big Brother mandates some central DB app 
usage. Those include COVID Watch, CoEpi, Private Watch Safe Paths, and others. 
Most have already started and are using swift and kotlin. Only Safe Paths has 
something out. However, there might be some room in creating some instant apps 
in LiveCode or in supporting in other ways. Also, some teams are just getting 
started and need something fast. I think we need some education apps done 
quickly.

Also, 4Catalyzer is making a home test and needs some app development.

For myself, I am on on the COVID Watch team.

If you want to do something, take a look around at privacy preserving contact 
tracing projects. And also look specifically I the ones I mentioned. 

I might be rehashing what has already been discussed.  Sorry. Like I said, 
"Drive by email".

And remember what the Beatles said, "You wanna wash your ha-a-ands!"

Dar Scott

I am using Private Watch: Safe Paths on my iPhone to fight COVID-19..

___
use-livecode mailing list
use-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: Maximum field height?

2020-04-06 Thread Alex Tweedly via use-livecode


Hi Jacque,

Scott made many of the same good points as you did - so I won't 
replicate my replies here.


On 06/04/2020 05:20, J. Landman Gay via use-livecode wrote:
On April 5, 2020 8:39:15 PM Alex Tweedly via use-livecode 
 wrote:



1. xTalk features just don't work, or work totally inadequately (e.g.
scrolling fields).


Somewhat true. LC made a start by adding widgets you can drop onto the 
stack to create native mobile buttons and fields, but I'd like to see 
regular LC controls magically change to native mobile controls much as 
the Mac, Windows, and (sort of) Linux appearances do. That would make 
a world of difference.

Yes !!


But there are features on mobile that don't exist on desktop. LC has 
provided for things like Android toasts and iOS popups. These things 
are one reason the language can't be entirely universal; mobile 
requires a different feature set. But it would be great if a scrolling 
field would just be a scrolling field everywhere. On the other hand, 
mobile lets you scroll all sorts of things (images, carousels, etc.) 
so we'd still need our mobile scroller anyway.
Same response to that as I have to mobilePick, mobilePickDate, etc. Why 
shouldn't they exist on desktop - if they're useful features for a good 
UI, why would LC not want to add them for desktop.



I agree it could be easier, but it isn't impossible. But parity 
wherever possible would be my first choice in what I'd like to see 
improved.




2. Failure in cross-platform equivalence.


If you mean mobile equivalence, Android is catching up quickly, in 
part because of the FM initiative. I appreciate that. iOS is pretty 
well covered for the most part. Some folks mentioned the issue of 
branching for different mobile platforms but that doesn't bother me 
much. We have to do that sometimes for the three desktop platforms 
already. The features that both iOS and Android do have in common use 
the same code and syntax.


I mean that, but for all platforms. If there is a common piece of UI 
functionality (e.g. pick a date) then abstract that out to a library 
function (in the box - not one we each create separately and slightly 
differently), and have it use the appropriate platform method. And if 
that means we finally get a pickDate widget on desktop then I'd say 
"about time" (and ask for a pickTime function as well :-)






The other two are, I suspect, not truly solvable.

3. It's not "Live"Code. Developing for Mobile gets you back into the
horrible edit - compile (i.e. build a standalone) - test cycle.


Yeah, this is a pain. I'm not sure there's any way around it but the 
addition of remote debugging has made it far easier. For a long time I 
felt like I was back in 1998 where I had to sprinkle "answer" dialogs 
all over the place just to know what my variable values were. There 
are some tricks though that help. I created a generic launcher app 
that loads my working stack so there's no actual compile required. I 
can't do this for complex apps, but I can do it for testing pieces and 
bits that will eventually go into the main app later. For simpler 
apps, the entire stack can be tested pretty easily this way.


Great. Now why didn't LC create a Launcher app like that so that 
everyone (esp new users) can use it,  one that runs in a standard way so 
we can easily communicate about it - and is documented.


4. You still need to deal with the ugly issues of the SDKs and the
app-store  requirements.


For me this is the hardest part, way worse than developing the app 
itself. It's also why I'd much rather deal with Android than Apple. 
Google is pretty easy to deal with. Apple is a constantly moving 
target with a rollercoaster of requirements, not to mention the 
profiles and certificates and what seems to me to be an unnecessarily 
complex review process.


Yes, but even getting the Android SDK seems to be (still) troublesome. I 
know it took me (literally) days way back when - it does seem to be 
better documented now, but apparently not quite straightforward.





However, if you are just developing for yourself or a few other 
people, you don't have to mess with either app store. Android apps can 
be freely distributed to anyone by any method and you don't even need 
a Google account. iOS apps can be distributed to a few people as 
"testers" without going through their byzantine submission process, 
though you do still need to mess with their account, certificates and 
profiles.


I'm thankful that the LC team keeps up with Apple's constantly 
changing requirements. Apple doesn't seem to value their developers much.




So, for me personally, even if LC Ltd. could fix (1) and (2), I would
still not even bother trying to build a mobile app; it's just not worth
the hassle or the learning curve.


It isn't such a steep learning curve as you'd think. One test app will 
probably get you going. If I were starting over, I'd start with 
Android because it's so much more flexible. The hardest part there is 
just makin

Re: Old Fossil seeks fast track assistance

2020-04-06 Thread scott--- via use-livecode

Thanks for these links!

--

Scott Morrow

Elementary Software
(Now with 20% less chalk dust!)
web   https://elementarysoftware.com/
email sc...@elementarysoftware.com
booth1-800-615-0867
--
> On Apr 6, 2020, at 7:55 AM, Devin Asay via use-livecode 
>  wrote:
> 
> Graham,
> 
> I’ve just been through this gauntlet with my students. I provided some links 
> and lessons for them at http://livecode.byu.edu/mobile/test-deploy-links.php. 
> I found the process for setting up Android a little fraught with pitfalls, so 
> I created an expanded instruction sheet for Android setup, linked to that 
> page.
> 
> I’m staying with the latest Stable version of LiveCode for my class, 9.5.1. 
> I’m running on Mac OS 10.14 Mojave. With this setup I have to use Xcode 10.1.
> 
> As a refresher, on developer.apple.com, you need 
> to create your iOS developer certificate, register all of the UDIDs for your 
> iOS devices, then create a wildcard provisioning profile for testing your 
> apps. The provisioning profile must include all devices you want to test on.
> 
> A collection of links of instructions for distributing mobile apps: 
> http://livecode.byu.edu/mobile/mobileAppDistribution.php.
> 
> I hope this will all help jog your memory. I find mine needs to be jogged 
> every time I come back to this mobile stuff after a long time away.
> 
> Cheers,
> 
> Devin
> 
> 
> 
> On Apr 4, 2020, at 2:38 AM, Graham Samuel via use-livecode 
> mailto:use-livecode@lists.runrev.com>> wrote:
> 
> Hi All - sorry this is a bit long, but I need help.
> 
> I’m a long term LC developer who more or less retired from development a 
> couple of years ago, but I’ve kept on lurking in this list and trying rather 
> hopelessly to remain up to date. My experience has been mostly on desktop 
> apps, with a little iOS work. I haven’t ever done much on Android. I have 
> just about retained my credentials as an Apple developer.
> 
> Now I find I really want to develop a mobile app at speed, and deploy it.
> 
> I don’t anticipate all that much difficulty in creating my app in the sense 
> of designing and coding it - this can call on my own quite extensive 
> experience of the past, the LC documentation and this invaluable list. I can 
> reasonable hope to create a prototype in a few days. However there is a 
> massive gap: testing and deployment.
> 
> I don’t have access to my most recent development machine (it’s in another 
> country and I’m self-isolating), so I am working with an iMac that can only 
> run MacOS High Sierra (and Windows 10 via Parallels, but I was hoping not to 
> go there for this project). Now, I clearly need to organise the right version 
> of XCode and the right SDK for my iOS development, and I need to do the 
> equivalent thing for Android - and I don’t know how to do it.
> 
> For iOS, I THINK I need XCode 10.2, which I’m trying to download to replace 
> the copy of 9.2 already on my machine. I obviously need to work with a 
> compatible SDK. For Android, I don’t know where to start, so for now I am 
> putting this on the back burner, but I will have to return to it eventually. 
> Even when I’ve lined all this up (if indeed it’s feasible), I then need to 
> remind myself how to test via simulators (I used to be good at this, so maybe 
> that is not so scary, but I am not at all up to date) and then I need to get 
> the app onto real hardware - starting with iPhones, as I’ve got a few of 
> these. I really don’t know how to do this for testing, and more so I don’t 
> know how to distribute a test version to a small population of testers, 
> although I know this is feasible. The whole project may crash and burn at 
> this beta testing stage, so actually getting it into the App Store can wait a 
> bit.
> 
> Obviously I am not expecting people on this list to hold my hand at every 
> step. My main concern is to be guided through the body of LC notes etc to get 
> absolutely practical advice and recipes as to what to do at each stage. If I 
> study the LC stuff long enough, I will get there, but I would dearly love 
> help to fast-track it all.
> 
> Thanks
> 
> Graham
> ___
> use-livecode mailing list
> use-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: Mobile Wondering

2020-04-06 Thread scott--- via use-livecode

That was my experience too… until LC added native support for other Android 
processors. Now I find the Android emulator to be very usable!
—
Scott Morrow

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

> On Apr 6, 2020, at 10:53 AM, J. Landman Gay via use-livecode 
>  wrote:
> 
>>  Well - they were right about that - the simulator was S...L...O...W.
> 
> You're right, the Android emulator is horrible. I stopped using it early on. 
> LC recently added support for x86-64bit specifically so we could use the 
> faster version, but I found it much easier to just cable my phone to my Mac 
> and use the real thing. It's quick and painless.

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

Re: ANN: glx2 script editor 4.0

I suspect the repeated LC SE reversion is the same issue as prefs not sticking.

Bob S


On Apr 6, 2020, at 1:49 PM, Bob Sneidar 
mailto:bobsnei...@iotecdigital.com>> wrote:

seeing some of the same things. There was an issue where the GLX2 menu under 
certain conditions would become the custom menu of the open GLX2 SE, and the 
system menu would revert back to the default. If the GLX2 menu becomes the 
System Menu you cannot access the default System Manu at all.

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: ANN: glx2 script editor 4.0

seeing some of the same things. There was an issue where the GLX2 menu under 
certain conditions would become the custom menu of the open GLX2 SE, and the 
system menu would revert back to the default. If the GLX2 menu becomes the 
System Menu you cannot access the default System Manu at all. 

Bob S


> On Apr 6, 2020, at 1:38 PM, matthias rebbe via use-livecode 
>  wrote:
> 
> Mark,
> where do you want feedback? I place it here for now. 
> 
> 
> Tested now with LC 9.5.1, 9.6.0DP3 on Mac OS 10.14.6 with two displays.
> 
> 1. the GLX2 bar is not under the LC menubar. It´s placed on the right of the 
> screen
> see https://livecode.dermattes.de/screenshots/glx2_bar.png
> 
> 
> And it  seems that GLX does not write back the preferences or maybe some of 
> them back to the prefs file.
> 
> 2. tried to set to chalkboard, but that was not saved. I had to change the 
> GLX2 Code Prefs.txt file in an editor while LC is not running to get 
> Chalkboard working
> 
> 3. setting the font size does also not work
>  even after changing the size manually in the editor (while LC is not 
> running) does not work. I need also to open the GLX preferences once in LC 
> and then  the font size changes in GLX
> 
> 4. when GLX2 is first opened then a menu is visible in GLX
> see https://livecode.dermattes.de/screenshots/glx2_menu_visible.png
> 
> when i click onto any of the menu items then the menu disappears 
> see https://livecode.dermattes.de/screenshots/glx2_menu_hidden.png
> 
> 
> Matthias
> 
> 
> -
> Matthias Rebbe
> Life Is Too Short For Boring Code
> 
>> 
> 
> 
> ___
> use-livecode mailing list
> use-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: ANN: glx2 script editor 4.0

2020-04-06 Thread matthias rebbe via use-livecode

regard 3. I meant 

...changing the size manually in AN editor (while LC is not running)

-
Matthias Rebbe
Life Is Too Short For Boring Code

> Am 06.04.2020 um 22:38 schrieb matthias rebbe via use-livecode 
> :
> 
> Mark,
> where do you want feedback? I place it here for now. 
> 
> 
> Tested now with LC 9.5.1, 9.6.0DP3 on Mac OS 10.14.6 with two displays.
> 
> 1. the GLX2 bar is not under the LC menubar. It´s placed on the right of the 
> screen
> see https://livecode.dermattes.de/screenshots/glx2_bar.png
> 
> 
> And it  seems that GLX does not write back the preferences or maybe some of 
> them back to the prefs file.
> 
> 2. tried to set to chalkboard, but that was not saved. I had to change the 
> GLX2 Code Prefs.txt file in an editor while LC is not running to get 
> Chalkboard working
> 
> 3. setting the font size does also not work
>  even after changing the size manually in the editor (while LC is not 
> running) does not work. I need also to open the GLX preferences once in LC 
> and then  the font size changes in GLX
> 
> 4. when GLX2 is first opened then a menu is visible in GLX
> see https://livecode.dermattes.de/screenshots/glx2_menu_visible.png
> 
> when i click onto any of the menu items then the menu disappears 
> see https://livecode.dermattes.de/screenshots/glx2_menu_hidden.png
> 
> 
> Matthias
> 
> 
> -
> Matthias Rebbe
> Life Is Too Short For Boring Code
> 
>> 
> 
> 
> ___
> use-livecode mailing list
> use-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: ANN: glx2 script editor 4.0

2020-04-06 Thread matthias rebbe via use-livecode

Mark,
where do you want feedback? I place it here for now. 


Tested now with LC 9.5.1, 9.6.0DP3 on Mac OS 10.14.6 with two displays.

1. the GLX2 bar is not under the LC menubar. It´s placed on the right of the 
screen
see https://livecode.dermattes.de/screenshots/glx2_bar.png


And it  seems that GLX does not write back the preferences or maybe some of 
them back to the prefs file.

2. tried to set to chalkboard, but that was not saved. I had to change the GLX2 
Code Prefs.txt file in an editor while LC is not running to get Chalkboard 
working
 
3. setting the font size does also not work
  even after changing the size manually in the editor (while LC is not running) 
does not work. I need also to open the GLX preferences once in LC and then  the 
font size changes in GLX

4. when GLX2 is first opened then a menu is visible in GLX
see https://livecode.dermattes.de/screenshots/glx2_menu_visible.png
   
when i click onto any of the menu items then the menu disappears 
see https://livecode.dermattes.de/screenshots/glx2_menu_hidden.png


Matthias


-
Matthias Rebbe
Life Is Too Short For Boring Code

> 


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

Re: ANN: glx2 script editor 4.0

Normally I wouldn’t, but in the past for one reason or another I turned off 
GLX2 to get to the script editor, and somewhere in the process of turning it 
off and on, a lot of new coding disappeared. That was long ago though, and I 
may not even be looking at the same problem. It seems that once the stack is 
saved, everything is in sync.

One other thing, when I enable GLX2, it’s menu becomes the system menu, even if 
the pointer tool is selected. Is this the desired behavior? No worries if it 
is. I’ll probably end up living in GLX2 from now on.

Bob S


On Apr 6, 2020, at 12:43 PM, Mark Wieder via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

On 4/6/20 12:36 PM, Bob Sneidar via use-livecode wrote:
This may be fixed in 4.0.1. I’ll check.
OK I verified that if I make a change in GLX2, then switch to the Native SE, I 
see the change. If however I make a change in the Native SE, then switch to 
GLX2, it does NOT reflect the change.
If however I SAVE the stack, THEN GLX2 sees the code change. It must be that 
GLX2 is maintaining it’s own in memory version of the code, and the switching 
is not synching in one of the directions. This is likely where the code loss 
seemed to happen, but seeing this I do not think there was actual code loss.
Maybe a preference to save stack on compile?

So... I'm confused... you want to change the builtin script editor to save 
after compiling so that it's compatible with the glx2 editor?

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

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

Re: ANN: glx2 script editor 4.0


On 4/6/20 12:36 PM, Bob Sneidar via use-livecode wrote:

This may be fixed in 4.0.1. I’ll check.

OK I verified that if I make a change in GLX2, then switch to the Native SE, I 
see the change. If however I make a change in the Native SE, then switch to 
GLX2, it does NOT reflect the change.

If however I SAVE the stack, THEN GLX2 sees the code change. It must be that 
GLX2 is maintaining it’s own in memory version of the code, and the switching 
is not synching in one of the directions. This is likely where the code loss 
seemed to happen, but seeing this I do not think there was actual code loss.

Maybe a preference to save stack on compile?


So... I'm confused... you want to change the builtin script editor to 
save after compiling so that it's compatible with the glx2 editor?


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

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

Re: Who else doesn't want auto-select when opening a card?

I ALWAYS want that. Nevertheless, have you tried select nothing in after 
OpenCard?

Bob S


On Apr 6, 2020, at 11:39 AM, J. Landman Gay via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

This makes me crazy. I almost never want the first field selected when I go to 
a card, particularly on mobile. And god forbid the first field is a list field, 
where the first line is hilited whenever the stack resumes focus, even if the 
hilitedline was 0.

The workaround is tedious: on preOpenCard, set traversalOn to false, send a 
message to turn it back on after the card is displayed, include a handler that 
will catch the message and do the deed.

I want a property or setting that lets me turn off this default behavior. It's 
annoying and disruptive, and has been there since day one.

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

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

Re: ANN: glx2 script editor 4.0

This may be fixed in 4.0.1. I’ll check.

OK I verified that if I make a change in GLX2, then switch to the Native SE, I 
see the change. If however I make a change in the Native SE, then switch to 
GLX2, it does NOT reflect the change.

If however I SAVE the stack, THEN GLX2 sees the code change. It must be that 
GLX2 is maintaining it’s own in memory version of the code, and the switching 
is not synching in one of the directions. This is likely where the code loss 
seemed to happen, but seeing this I do not think there was actual code loss.

Maybe a preference to save stack on compile?

Bob S

On Apr 6, 2020, at 12:20 PM, Mark Talluto via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

I should have mentioned that I tested restarting and that did not do it either. 
:(

My bigger problem is that GLX keeps switching back to LC’s script editor. I 
turn it back to GLX and I loose all my code changes in GLX.
I took every plugin out of my plugins to rule them out. My plugins folder is 
just GLX2 Code.rev and glx2Plugins.txt.

We can take this offline where we can discuss this in more detail.


Best regards,

Mark Talluto

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

Re: ANN: glx2 script editor 4.0


Ack! Bernd just hipped me to the fact that I uploaded the wrong version.
It *should* identify itself as version 4.0.1 if you've got the right 
one. If not, download it again - I *think* I've got the right one 
uploaded to bitbucket now.


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

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

Re: ANN: glx2 script editor 4.0

2020-04-06 Thread Mark Talluto via use-livecode

> 
> On Apr 6, 2020, at 12:08 PM, Mark Wieder via use-livecode 
>  wrote:
> 
> On 4/6/20 11:49 AM, Mark Talluto via use-livecode wrote:
> 
>> Quick question: I am interested in using the ‘Chalkboard Motiff’. When I 
>> select it I do not see a change in the look. Same when I close the prefs. 
>> What am I missing?
>> The same is true for changing the font size. I changed the font to “Source 
>> Code Pro” if that matters.
> 
> The motif isn't changing on the fly for some reason. It's something I need to 
> look into. But the next time you launch the IDE it will have the new motif.

I should have mentioned that I tested restarting and that did not do it either. 
:(

My bigger problem is that GLX keeps switching back to LC’s script editor. I 
turn it back to GLX and I loose all my code changes in GLX. 
I took every plugin out of my plugins to rule them out. My plugins folder is 
just GLX2 Code.rev and glx2Plugins.txt.

We can take this offline where we can discuss this in more detail.

Best regards,

Mark Talluto
livecloud.io 
nursenotes.net 
canelasoftware.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: Socket Help

Both. The Windows lag is present on the LAN and Internet. The Internet does not 
seem to be introducing any lag, or so little it’s not detectable.

On Apr 6, 2020, at 11:50 AM, Phil Davis via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

Hi Bob,

I'm realizing now that your system connects client and server via the internet. 
Mine connects them via LAN. Big security difference!

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

Re: ANN: glx2 script editor 4.0


On 4/6/20 11:49 AM, Mark Talluto via use-livecode wrote:


Quick question: I am interested in using the ‘Chalkboard Motiff’. When I select 
it I do not see a change in the look. Same when I close the prefs. What am I 
missing?
The same is true for changing the font size. I changed the font to “Source Code 
Pro” if that matters.


The motif isn't changing on the fly for some reason. It's something I 
need to look into. But the next time you launch the IDE it will have the 
new motif.


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

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

Re: Socket Help


Thanks for the example, Bob.  Yes, it does seem very conclusive.

Do you know if there's an existing bug report for this?

I've seen a few other Win-specific reports, but the ones I recall were 
mostly about file I/O, and I don't recall one for network I/O.


--
 Richard Gaskin
 Fourth World Systems


Bob Sneidar wrote:

> Hi Richard.
>
> Just to be absolutely certain I excluded any other factors, I tested
> retrieving data from mySQL from a Mac and from a PC using only the
> Message Box (no UI).
>
> Since I am out of the office, I can only test my Mac remotely. I can
> however remote into the mySQL server at work which is running LC. Both
> are v9.5.1 Community.
>
> With the Mac I am getting as low as 295 milliseconds to query my
> entire database of customers and retrieve it as an array. On the
> actual server where the mySQL database resides, I am getting over 1000
> milliseconds.
>
> Querying for only 1 record from the same database, I’m getting 123 and
> 865 respectively. To ensure I wasn’t encountering DNS lag I set the
> server host to localhost. I cannot get much more local than that.
>
> Even with the added latency of the Internet from the Mac, and the
> advantage of the PC being the very computer the SQL server is on, I am
> getting a difference of roughly 7 times slower. No UI updating is
> involved. It’s a straight up message box script:
>
> put the milliseconds into tStart
> put sqlquery_createObject("customers") into qObject
> sqlquery_set qObject, "limit", 1
> put dbQuery(qObject, "array") into aData
> put the milliseconds into tEnd
> put tEnd - tStart
>
> I think this is pretty conclusive. Either Windows networking is for
> whatever reason, considerably slower, at least for this kind of
> operation, than Mac, or else the Windows LC engine is the bottleneck.


___
use-livecode mailing list
use-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: Who else doesn't want auto-select when opening a card?

J. Landman Gay wrote:

> I want a property or setting that lets me turn off this default
> behavior. It's annoying and disruptive, and has been there since
> day one.

I lost count of how many times I've seen that come up in the forums over 
the years.

What you propose seems reasonable and useful.  And because it involves 
NOT doing something, it would seem relatively easy to implement.

Anyone here up for the task of implementing it?

--
 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: ANN: glx2 script editor 4.0

Whoa! Quite a bit smaller! I’ll check it out. Really excited! I loved GLX2 but 
the code loss on OS X when switching GLX2 on and off was killing me! I will 
back things up and check for that. 

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: Socket Help

2020-04-06 Thread Phil Davis via use-livecode


Hi Bob,

I'm realizing now that your system connects client and server via the 
internet. Mine connects them via LAN. Big security difference!


In another system I wrote that connects client & server over the 
internet, the server does this upon receiving a request:


   does a 'wait flag' (temp file) exist for this data source?
   - no:
  - is this an update request?
 - no: select/assemble data & put it
 - yes: set a 'wait flag', do the update, delete the wait
   flag, put the response
   - yes: put 'busy'  (client tries again in a few ticks, up to x
   attempts)

In the case of this system, the traffic is low enough so this approach 
has worked fine for years. In a higher volume system you might want to 
see if any other CGI transactions are in progress against the requested 
data source before you start changing data.


That's all I got.
I realize it probably isn't new news.

Phil



On 4/6/20 7:49 AM, Bob Sneidar via use-livecode wrote:

Hi Phil. Thanks for the reply.

I’m curious how this client server method handles multiple simultaneous 
connections? I had the idea of having a listener agent spawn an SQL Agent stack 
the first time a client connected, that would then listen on a random port. The 
listener agent would return the random port to the client which would then in 
the future communicate with the random SQL agent directly. A kind of passive 
connection if you will. I’m not sure all that is necessary though.

I kept waking up all night thinking of ways to implement the encryption so that 
even a person with time to decipher the method would not be able to use it in 
subsequent captures.

Of course, nothing is uncrackable, even Fort Knox, given the time, resources 
and resolve. The trick to encryption is to make the process of foreign 
decryption so tedious and time consuming that it isn’t worth the effort.

And of course the reward for the foreign agent has to be considered when 
determining the level of complexity. There is no hacker in the Ukraine poring 
over the encrypted packets of my SQL transactions to access my data, so I don’t 
think I need go to extreme measures! I simply need to be able to reassure the 
principles of my company that their data is secure in transit.

One more note, to secure passwords that I store in SQL, I encrypt those 
separately with a different key and seed before creating the SQL. That way, 
even if someone got physical access to the database, they couldn’t decipher the 
passwords.

Bob S

On Apr 5, 2020, at 11:25 PM, Phil Davis via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

Hi Bob,

I created a client-server business system for a client some years ago. It too uses data 
encryption. What I did on the server side was prep the data for net transfer 
(base64Encode it as the final prep step, I think), then transfer length(data) & CR 
& data.

On the client side, the app reads from the socket for 1 line (which goes into a variable, 
say "X"), then read from socket for X bytes. This keeps it simple - no need for 
special terminators etc - and seems to always work.

Phil Davis

___
use-livecode mailing list
use-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: Who else doesn't want auto-select when opening a card?

2020-04-06 Thread Mark Talluto via use-livecode

On Apr 6, 2020, at 11:39 AM, J. Landman Gay via use-livecode 
 wrote:
> 
> This makes me crazy. I almost never want the first field selected when I go 
> to a card, particularly on mobile. And god forbid the first field is a list 
> field, where the first line is hilited whenever the stack resumes focus, even 
> if the hilitedline was 0.
> 
> The workaround is tedious: on preOpenCard, set traversalOn to false, send a 
> message to turn it back on after the card is displayed, include a handler 
> that will catch the message and do the deed.
> 
> I want a property or setting that lets me turn off this default behavior. 
> It's annoying and disruptive, and has been there since day one.

Agreed. It is much easier for us to focus on a field if wanted this on a 
preOpenCard. 


Best regards,

Mark Talluto
livecloud.io 
nursenotes.net 
canelasoftware.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: Socket Help

Hi Richard. 

Just to be absolutely certain I excluded any other factors, I tested retrieving 
data from mySQL from a Mac and from a PC using only the Message Box (no UI). 

Since I am out of the office, I can only test my Mac remotely. I can however 
remote into the mySQL server at work which is running LC. Both are v9.5.1 
Community. 

With the Mac I am getting as low as 295 milliseconds to query my entire 
database of customers and retrieve it as an array. On the actual server where 
the mySQL database resides, I am getting over 1000 milliseconds. 

Querying for only 1 record from the same database, I’m getting 123 and 865 
respectively. To ensure I wasn’t encountering DNS lag I set the server host to 
localhost. I cannot get much more local than that. 

Even with the added latency of the Internet from the Mac, and the advantage of 
the PC being the very computer the SQL server is on, I am getting a difference 
of roughly 7 times slower. No UI updating is involved. It’s a straight up 
message box script:

put the milliseconds into tStart
put sqlquery_createObject("customers") into qObject
sqlquery_set qObject, "limit", 1
put dbQuery(qObject, "array") into aData
put the milliseconds into tEnd
put tEnd - tStart

I think this is pretty conclusive. Either Windows networking is for whatever 
reason, considerably slower, at least for this kind of operation, than Mac, or 
else the Windows LC engine is the bottleneck. 

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: ANN: glx2 script editor 4.0

2020-04-06 Thread Mark Talluto via use-livecode

On Apr 6, 2020, at 11:08 AM, Mark Wieder via use-livecode 
 wrote:
> 
> I posted this to the web forum last night and figured I should put it in the 
> list as well... so here's something to help with working in isolation.

Nice work Mark. I am giving it a try right now. I am interested in to seeing 
how it goes. 

Quick question: I am interested in using the ‘Chalkboard Motiff’. When I select 
it I do not see a change in the look. Same when I close the prefs. What am I 
missing?
The same is true for changing the font size. I changed the font to “Source Code 
Pro” if that matters.

Thanks again for this update.

Best regards,

Mark Talluto
livecloud.io 
nursenotes.net 
canelasoftware.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: Socket Help

Bob Sneidar wrote:

> I was a big believer that SSL was never going to be compromised… until
> it was. The retooling of industry security standards over the last 6
> years or so has taught me the opposite: NEVER rely on out of the box
> security if you can help it.

After acknowledging how bugs can creep into even widely-used and 
critical code, do you really want to try to outdo hundreds of security 
specialists single-handedly?

Heartbleed is an excellent case in point, as the maintainer was a single 
person, and though the code was open everyone using it just took it for 
granted. The amazing thing is that nothing worse happened - that one 
fella was pretty good, just one single error added during an uncommonly 
hectic day. After that there are now two assigned maintainers, and an 
large number of code reviews with every build from staff in orgs 
dependent on it.

I hold no security certifications. But I pass along the rubric of "never 
write your own security" from literally everyone I know who does.

Your code, your call, of course.

> Asking a web server to get data and return it introduces a lag time
> which I am already struggling with.

What is the lag time of an already-resident Apache process (or Lighttpd, 
or NGinX) in compiled object code optimized for that one task by 
specialists, vs a scripted implementation in LiveCode?

Might be worth measuring before replicating.

> And if I DID use a web server, I would still have to go through
> extraordinary measures to secure THAT!

What steps are needed to secure a standard web server that are not 
needed for equivalent security in a custom server?

I'm not arguing here.  Heck, I sometimes even write my own database 
engines, so I'm certainly not trying to talk you out of having a good 
time scripting.  But the older I get the more I like to have my fun 
where the fun happens, in the business logic of the system I'm 
delivering, rather than reinventing generic infrastructure.

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

Who else doesn't want auto-select when opening a card?

2020-04-06 Thread J. Landman Gay via use-livecode

This makes me crazy. I almost never want the first field selected when I go to a card, 
particularly on mobile. And god forbid the first field is a list field, where the first line is 
hilited whenever the stack resumes focus, even if the hilitedline was 0.


The workaround is tedious: on preOpenCard, set traversalOn to false, send a message to turn it 
back on after the card is displayed, include a handler that will catch the message and do the deed.


I want a property or setting that lets me turn off this default behavior. It's annoying and 
disruptive, and has been there since day one.


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

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

Re: Mobile Wondering

When a desktop theme manager isn't available, LC reverts to its built-in
emulated Motif, hence the odd appearance (which is awesome if you love
NeXT, and horribly confusing to literally every newcomer if they're not
ancient enough to remember the old Unix UI and know the intricacies of
MetaCard's history, or even what MetaCard was).

For mobile, LC suggests hand-scripting a overlay object to handle the
user interation and graphical feedback for scrollable controls like
fields and groups.

In practice, most devs I know don't type those manually, but have
written their own routines that automatically instantiate mobile
scrollers by examining controls on preOpenCard and setting up the
scrollers as needed.

I do not know why this is impossible for the engine to do, but it's easy
enough to work around in a script.

--
Richard Gaskin
Fourth World Systems

Mobile Wondering
Neville Smythe neville.smythe at optusnet.com.au
Mon Apr 6 13:50:27 EDT 2020

Previous message (by thread): Mobile Wondering
Next message (by thread): [ANN] This Week in LiveCode 220
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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

Previous message (by thread): Mobile Wondering
Next message (by thread): [ANN] This Week in LiveCode 220
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the use-livecode mailing list

___
use-livecode mailing list
use-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: Problems locating Android SDK


Skip Kimpel wrote:

> Richard,
>
> It took me two attempts at the Android Studio install.  I realized
> during the first attempt that I had cut it short before it had
> finished everything.  After re-installing, it worked just fine.

Thank you, Skip (and good to see you back on this list, BTW).

Well, turning it off and then turning it back on again is the universal 
IT fix, so I'll do a resinstall and see how it goes.


--
 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: Problems locating Android SDK


Colin Holgate wrote:

> You may have read the path where tools are as being where you need to
> point LiveCode to. Point LiveCode to ~/Library/Android/SDK, and not
>  ~/Library/Android/SDK/Tools

Thank you, Colin.  ~/Android/SDK/ is where I pointed it (Ubuntu 18.04).

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

ANN: glx2 script editor 4.0

I posted this to the web forum last night and figured I should put it in 
the list as well... so here's something to help with working in isolation.


Whew! It's been a long time since I've updated this.
I really thought I had made my peace with the built-in script editor, 
but I recently had to look at this thing again and make some long-needed 
adjustments.
Refactored it so much that it really needs a new major version to 
reflect all the changes.

So this is the official release of the glx2 script editor 4.0

new features:

Integration of the status bar with Fourth World's devolution
(http://fourthworld.com/products/devolution/index.html)
Refactored code folding
Status bar colors match LiveCode license version colors
Fixed block comment folding inside handlers
Refactored code folding yet again for speed
Renamed stack for ease of editing in Project Browser
Fixed "end try" tab formatting
Removed most dependence on stack naming convention
Some rework for compatibility with Refactor stack
Folding block comments.
Extended pattern matching to "()[]{}"
Line numbers. Yes, finally.
Pressing enter on a compiled script closes the tab ala the built-in 
editor. I never thought that was a thing.

control-tab and shift-control tab move among the open script editor tabs.
Click in line number field to toggle ghost breakpoints on and off.
Line numbering and ghost breakpoints adjust properly to cut/paste/edit.
There is now a proper license file. GLX2 has always been licensed under 
the MIT license, but there was no external notice of this, only a custom 
property (uRIP["EULA"]) of the mainstack.
The "red dot" breakpoints are now functional, with or without 
PowerDebug. This is a Big Deal, because the dot positions are 
recalculated when you compile so that the actual breakpoints stay in 
sync with the visual indicators. To toggle a breakpoint for a given 
line, right-click on the line and select the option from the pop-up 
menu. Note that the ghost breakpoints are not persistent, i.e., they 
only exist for the current session.
NOTE: If you use breakpoints without PowerDebug in the system, you will 
end up launching the IDE's script editor on hitting a breakpoint. The 
IDE's debugger is intimately intertwined with the IDE's script editor.

The default font size preference is now 12 point.

bugs fixed:

Ghost breakpoints coexist with code folding.
Compilation errors weren't highlighting the error line properly.
Right-clicking the handler panel was only selecting the folders popup.
Some code folding wasn't working properly. Reformatting could lose code 
if collapsed.
Removed lots of unused legacy custom properties (see note about deleting 
prefs file)

Command-w (control-w) closes the current tab.
OSX problem with toggling GLX2 on and off
Ghost breakpoints weren't correctly responding to cut/paste
Refactored for speed
Folding case statements inside switch contructs works properly now.
It was previously collapsing all the way down to the 'end switch' statement.
Line numbering could get out of sync on opening a new tab.
Reopening the script editor after closing wasn't properly noticing 
previously-open tabs.

Hacked around LC8.1 interaction with reloading/rewriting revTools.
Lots of little things I had time to fix up while waiting.
For one thing, the splitter bar between the handlers and script panels 
is more accessible now.

The properties were never included in clairvoyance completion
Fixed miscellaneous problems with glx2 plugin handler code
Preferences weren't being loaded properly
Multiple problems solved with handler folders
Several things that were previously working were fixed until they broke, 
then refactored until they worked again.

The cursor was being positioned improperly for new commands and functions
Two folding structures problems fixed
"else if" was folding in the middle
the combination of folding structures and block comments could lose text
Re-enabled live colorization
Bernd Niggeman contributed live colorization fixes
Fixed the cursor flickering problem
Broke and fixed clairvoyance
Frontscript was interfering with text/icons display in the IDE's dock

known issues:

Line wrapping doesn't change the line numbering. If you turn on line 
wrapping, the line numbers after a line wraps will be wrong. I don't 
currently know any way of telling when a line is being wrapped. I'd 
treat this as experimental and not enable it.
Still some problems recognizing that text inside a block comment is not 
actionable.
Swapping back and forth between glx2 and the IDE's script editor can get 
a bit wonky.
Very little testing has been done on any Windows platform. If it works, 
it works.

Spuriously recognizes "the" as a library handler.

NOTE: the glx2Plugins.txt file should be placed in the same user plugins 
folder as glx2 itself. If you have an older "glx2 Plugins.txt" file you 
can get rid of it. I renamed the new file to eliminate the embedded 
space, and the older naming convention will just be ignored. Current 
plugin

Re: Problems locating Android SDK

2020-04-06 Thread Skip Kimpel via use-livecode

Richard,

It took me two attempts at the Android Studio install.  I realized during
the first attempt that I had cut it short before it had finished
everything.  After re-installing, it worked just fine.

SKIP

On Mon, Apr 6, 2020 at 1:47 PM Colin Holgate via use-livecode <
use-livecode@lists.runrev.com> wrote:

> You may have read the path where tools are as being where you need to
> point LiveCode to. Point LiveCode to ~/Library/Android/SDK, and not
> ~/Library/Android/SDK/Tools
>
>
> > On Apr 6, 2020, at 11:32 AM, Richard Gaskin via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Colin Holgate wrote:
> >
> > > On Apr 6, 2020, at 10:14 AM, Richard Gaskin wrote:
> > >>
> > >> I'm setting up a new machine for Android development.
> > >>
> > >> Where is the one-page list of steps on the livecode.com site that
> > >> reliably guides a new user through this for all supported platforms
> > >> (Mac, Win, Linux)?
> > >>
> > >> This one fails:
> > >>
> http://lessons.livecode.com/m/2571/l/625198-livecode-and-android-studio
> > >
> > > That link does work, and helps to solve the problem. The current
> > > Android Studio comes with Android 10 installed, and LiveCode needs
> > > Android 9.
> >
> > The link itself works, in that it goes to a page. :)
> >
> > But I have followed its instructions to install Android 9, and pointed
> my LC prefs to the folder shown in the screen shot, and LC reports:
> >
> >  The chosen folder is not a valid Android SDK. Please
> >  ensure that you have installed it correctly, and enabled
> >  support for 9.0 (API 28)
> >
> >
> > When I run Android Studio it all seems to work.  But LC says it doesn't.
> >
> > What did I miss?
> >
> > --
> > Richard Gaskin
> > Fourth World Systems
> > Software Design and Development for the Desktop, Mobile, and the Web
> > 
> > ambassa...@fourthworld.comhttp://www.FourthWorld.com
> >
> >
> > ___
> > use-livecode mailing list
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Go to card has become slow


Bob Sneidar wrote:

> On Apr 6, 2020, at 9:28 AM, Richard Gaskin wrote:
>
>> Your application writing data to disk is a very different thing from
>> Windows Desktop Explorer automatically refreshing a directory view.
>
> Control doesn’t return to the application until the tilde version goes
> away.

True, but LC is done with that tilde file and deletes it LONG before the 
separate process of the Windows File Explorer polls and redraws the 
graphical illustration of the deletion that has already happened.



> On Apr 6, 2020, at 9:28 AM, Richard Gaskin wrote:
>
>> on mouseUp
>>  put the long seconds into t
>>  write "somedata" to url ("file:whatever")
>>  if the result is not empty then
>> answer "Couldn't write file (" &sysError()&")"
>>exit to top
>>  end if
>>  put the long seconds - t
>> end mouseUp
>
> You are testing low level file operations. I am testing the saving of
> a Livecode stack. I don’t think this test applies.

Comforting to know that there is no perceived difference in generic file 
writes between Mac and Win, and that we can focus exclusively on the 
small handful of additional steps LC takes when saving a stack file.


This is my understanding of the steps LC takes to save a stack file 
(hopefully Mark Waddingham will chime in if any of this is incorrect or 
incomplete), where "*" denotes steps unique to stack files not taken 
with other files:


* 1. Serialize stack data
* 2. If file exists, rename it with tilde
  3. Open the file
  4. Write the data to disk
  5. Close the file
* 6. Delete the tilde'd file


This test will measure that:

on mouseUp
  put the long seconds into t
  save this stack
  put the long seconds - t
end mouseUp


If the stack contains little data, as with other benchmarking you may 
need to put the task in a loop in between the timing statements to have 
a duration long enough to be meaningfully measurable, e.g.:


on mouseUp
  put the long seconds into t
  repeat 100
 save this stack
  end repeat
  put the long seconds - t
end mouseUp

Run that on similar Mac and Win iron and let us know how it goes.

--
 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: Mobile Wondering

2020-04-06 Thread J. Landman Gay via use-livecode

On 4/6/20 10:12 AM, Alex Tweedly via use-livecode wrote:
But, afaik, it's not just scrolling fields; aren't there also issues with keyboard input
requiring you to scroll / move the field to remain visible,

That was fixed recently with mobileSetKeyboardDisplay.

Also, besides mouse events working on both mobile and desktop, there is automatic conversion of
option buttons to native mobile equivalents and cross-platform equivalence for browser widgets.
Other widgets like navigation bars and segmented controls can change between mobile platforms
by altering some of their properties, and the switch button has a handy "theme" property that
lets you do that with a single property setting. I wish they all had that.

We also have Android native fields, and iOS native fields and buttons (where's my Android
button?) which can be dropped onto the stack, though on desktop they are placeholders.

And the fact that mobile-specific commands each need to be wrapped inside an environment-check to keep from throwing an error in the IDE.

That's easy to fix. I have standard library handlers that create scrollers, input fields, etc.
and at the top of each one I put "if the environment <> "mobile" then exit thisHandler". That
way I can script everything normally and if I'm not on mobile the command is ignored so the
scripts don't need to branch for things like that.

On the other hand, a frequent request has been for the LC engine to ignore mobile commands if
we're in the IDE. So there's that.

4A. SDKs and the build environment. Just horrible; when I tried this a few years ago (for Android) it took me
days of frustration and guesswork to get a working SDK, and get it connected to LC, and to try to get a
simulator to work properly. Including choosing (I think it "device type") from a long drop-down
list of devices I didn't own. I picked at random - and was told either that it was "unavailable" or
"will be slow - suggest you try a different device". Well - they were right about that - the
simulator was S...L...O...W.

You're right, the Android emulator is horrible. I stopped using it early on. LC recently added
support for x86-64bit specifically so we could use the faster version, but I found it much
easier to just cable my phone to my Mac and use the real thing. It's quick and painless.

I never did get round to trying for IOS, because everyone said how much harder
it was than Android :-)
I've found the iOS simulator to be very good, on the other hand. It accurately represents what
will happen on a real device, including all the bugs I introduce. It does require a bit of
setup -- downloading gigabytes of XCode is a time suck -- but once set up it performs well.
However, I've found switching between different versions of XCode/LC to be cumbersome. I'd like
it if LC could make the process easier, maybe by issuing shell commands behind the scenes so I
don't have to.

4B. App store issues. Never got that far - though it sounds like it's pretty
annoying.
Build for a few people (and sidestep the store) - seems to be possible, but not
clear how easy it is.

Apple makes it painful to submit to their store, but if all you want is to generate some
certificates and profiles so you can distribute to a few people, more than half the pain is
avoided.

Private Android distribution is a piece of cake. Build the app, send it to someone. The only
caveat is that the user must enable a setting on their phone that allows them to accept apps
that are not downloaded from the Play Store. Newer Android devices will ask the user if they
want to do that, older ones require the user to go into Settings to flip a switch.

Thanks for the reply - it has stiffened my resolve to have another go !!

I'm so glad to hear that. :) Ask us if you get stuck.

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

Re: Mobile Wondering

2020-04-06 Thread 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: Problems locating Android SDK

2020-04-06 Thread Colin Holgate via use-livecode

You may have read the path where tools are as being where you need to point 
LiveCode to. Point LiveCode to ~/Library/Android/SDK, and not 
~/Library/Android/SDK/Tools


> On Apr 6, 2020, at 11:32 AM, Richard Gaskin via use-livecode 
>  wrote:
> 
> Colin Holgate wrote:
> 
> > On Apr 6, 2020, at 10:14 AM, Richard Gaskin wrote:
> >>
> >> I'm setting up a new machine for Android development.
> >>
> >> Where is the one-page list of steps on the livecode.com site that
> >> reliably guides a new user through this for all supported platforms
> >> (Mac, Win, Linux)?
> >>
> >> This one fails:
> >> http://lessons.livecode.com/m/2571/l/625198-livecode-and-android-studio
> >
> > That link does work, and helps to solve the problem. The current
> > Android Studio comes with Android 10 installed, and LiveCode needs
> > Android 9.
> 
> The link itself works, in that it goes to a page. :)
> 
> But I have followed its instructions to install Android 9, and pointed my LC 
> prefs to the folder shown in the screen shot, and LC reports:
> 
>  The chosen folder is not a valid Android SDK. Please
>  ensure that you have installed it correctly, and enabled
>  support for 9.0 (API 28)
> 
> 
> When I run Android Studio it all seems to work.  But LC says it doesn't.
> 
> What did I miss?
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

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

Re: Go to card has become slow

You are testing low level file operations. I am testing the saving of a 
Livecode stack. I don’t think this test applies.

Bob S


On Apr 6, 2020, at 9:28 AM, Richard Gaskin via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

on mouseUp
 put the long seconds into t
 write "somedata" to url ("file:whatever")
 if the result is not empty then
answer "Couldn't write file (" &sysError()&")"
exit to top
 end if
 put the long seconds - t
end mouseUp

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

Control doesn’t return to the application until the tilde version goes away.

On Apr 6, 2020, at 9:28 AM, Richard Gaskin via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

Your application writing data to disk is a very different thing from Windows 
Desktop Explorer automatically refreshing a directory view.

___
use-livecode mailing list
use-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: Socket Help

I was a big believer that SSL was never going to be compromised… until it was. 
The retooling of industry security standards over the last 6 years or so has 
taught me the opposite: NEVER rely on out of the box security if you can help 
it.

Asking a web server to get data and return it introduces a lag time which I am 
already struggling with. And if I DID use a web server, I would still have to 
go through extraordinary measures to secure THAT!

By “rolling my own” (I’m not really, I’m using LC’s built in AES encryption 
with a twist) I am ensuring that even if someone were able to grok my poison 
pill approach, and then brute force the hash, it would only work for that one 
instance. THEY STILL would have to brute force any password data in the 
instance, and they would have to do the same process all over again with the 
next intercepted next transmission.

Bob S


On Apr 6, 2020, at 9:10 AM, Richard Gaskin via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

Two rubrics that have saved me much time, effort, and unrest:

1. Unless you have a specific reason why another protocol is truly
  necessary, use HTTP.

  Tooling, documentation, simplicity, extensibility - it's all there,
  ready to use, right now.


2. Never roll your own security.

  Consider all the hours spent developing, testing, refining,
  reporting, revising, packaging, documenting.  No single human
  will ever replicate even a corner of that in an entire lifetime.
  And there's no need, since most of the best security options are
  Free and open.


--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web

___
use-livecode mailing list
use-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: Problems locating Android SDK

Colin Holgate wrote:

> On Apr 6, 2020, at 10:14 AM, Richard Gaskin wrote:
>>
>> I'm setting up a new machine for Android development.
>>
>> Where is the one-page list of steps on the livecode.com site that
>> reliably guides a new user through this for all supported platforms
>> (Mac, Win, Linux)?
>>
>> This one fails:
>> http://lessons.livecode.com/m/2571/l/625198-livecode-and-android-studio
>
> That link does work, and helps to solve the problem. The current
> Android Studio comes with Android 10 installed, and LiveCode needs
> Android 9.

The link itself works, in that it goes to a page. :)

But I have followed its instructions to install Android 9, and pointed 
my LC prefs to the folder shown in the screen shot, and LC reports:

  The chosen folder is not a valid Android SDK. Please
  ensure that you have installed it correctly, and enabled
  support for 9.0 (API 28)

When I run Android Studio it all seems to work.  But LC says it doesn't.

What did I miss?

--
 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: Mobile Wondering

Alex Tweedly wrote:

> On 06/04/2020 03:55, scott--- via use-livecode wrote:
>>> 1. xTalk features just don't work, or work totally inadequately
>>> (e.g. scrolling fields).
>> I feel this is overly harsh. Livecode fields (and the creation of
>> native UIText fields) do work on mobile. I think the issue is that
>> the use of some objects (like fields) on mobile is not as drag ’n'
>> drop simple as it is on desktop. No argument there.
>
> Yes, it was harsh - but sometimes a little bit of hyperbole helps, if
> only the mood of the speaker :-)

And for purposes of new-user advocacy.  Which could (and arguably 
should) be read as "conversion rates", or more directly, "making money".

Mobile fields are a subset of the excellent LiveCode-native field.

If things were the other way around that would pose a problem.  But as 
they are, the LC field object is so flippin' awesome it certainly 
doesn't hurt us at all to simply use a subset of its rich features for 
mobile development.

Of course mobile editing UI is not directly supported in the LC field 
object. It does a wonderful job on the desktop, and it would be 
super-awesome to see the object extended to support the other 55% of 
where users spend time.  But at least we have the option to script our 
way to an OS-native mobile field.

But why would we do that?  This is an xTalk.  The benefit of The xTalk 
Way is at the heart of all GUIs, direct manipulation of objects.  It may 
seem perfectly reasonable to a C++ programmer to type out every little 
thing, but it doesn't reflect the charm, allure, and productivity 
advantage of The xTalk Way.

Thankfully, LC is also super-flexible, so it's not all that hard to 
write a library that on preOpenCard looks for all editable fields, hides 
them, and creates matching OS-native fields over them.

Extra bonus points for re-routing messages for OS-native mobile fields 
to traditional LC fields - even dispatching them directly to the field 
object the library used as the basis for the mobile field.

This does two things:

1. We type less.

   LC is a GUI app development tool, the world's most powerful
   example of The xTalk Way.  We type only when we need to.
   And we don't need to type out definitions for something as
   basic as a field.

2. We test on-device less.

  The joy of The xTalk Way is that we code and run and
  code and run interchangeably, interleaved, in a seamless
  continuum of creative flow. "We don't need no stinking
  compile-runtime cycle."

  Sure, when you want to test OS-specific features, you need
  to test on the specific OS.  If you want to see how your
  AppleScript works, you test on your Mac.  If you want to
  check your registry settings, you test on Windows.  If you
  want to see how incomplete the player object is, you test
  on Linux. Same with mobile - test your OS-specific features
  where they exclusively live.

  But think about how much of a drag LC would be if every time
  you changed one line of code you had to stop everything you're
  doing, walk through a number of steps to move the app out of
  where you can already see it right in front of you, to go
  look at the same controls on a different screen.

  So just don't do that.

  Design the workflow to reflect the joyful productivity
  which is the reason you're reading this now, the reason we
  choose LiveCode.  Code and run seamlessly interleaved right
  where you are as much as possible.

  When we maximize use of LC-native controls, and automate
  instantiation of mobile-native controls based on those
  LC-native controls, we get to spend more time where time
  is best spent, right in the IDE.

  Data entry, navigation, server connectivity, graphics
  manipulation, and many other things apps do are equally
  available on desktop and mobile OSes.

  So if you set up a workflow that requires on-device testing
  of things that can be tested in the IDE, you're choosing to
  slow down development and reduce the joy of coding.

LiveCode is a wonderful environment, a rich thriving forest of 
development treats.  Let's spend as much time in that lush world as we 
can, minimizing the sometimes-necessary ventures into the desert of a 
handheld device foraging desperately for scraps of debugging info.

Let's live well.  Let's live The xTalk Way.

This discussion on editable fields is just one way to streamline LC into 
a joyful experience.  Other controls can be similarly mapped, and even 
moving the stack to the device for testing can be radically streamlined. 
And the IDE itself is ripe for refinement of some of its GUI elements to 
provide better guidance with a simpler appearance.

We can explore all of that after we resolve the question that gave rise 
to this thread:

What is the simplest way Jacque can accomplish the most basic task of 
gracefully displaying a block of scrolling text?

Money-making hint: if it requires creating a separate container object 
just to handle a deficiency in field buffering, that wou

Re: Problems locating Android SDK

2020-04-06 Thread Colin Holgate via use-livecode

That link does work, and helps to solve the problem. The current Android Studio 
comes with Android 10 installed, and LiveCode needs Android 9.


> On Apr 6, 2020, at 10:14 AM, Richard Gaskin via use-livecode 
>  wrote:
> 
> I'm setting up a new machine for Android development.
> 
> Where is the one-page list of steps on the livecode.com site that reliably 
> guides a new user through this for all supported platforms (Mac, Win, Linux)?
> 
> This one fails:
> http://lessons.livecode.com/m/2571/l/625198-livecode-and-android-studio
> 
> 
> #CriticalDocumentationBugsThatTurnOffNewUsers
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


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

Re: Go to card has become slow

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:

Your application writing data to disk is a very different thing from 
Windows Desktop Explorer automatically refreshing a directory view.

Any GUI file manager on any OS will use some form of timer/polling for 
the refresh, and the refresh rate for macOS' Finder is much shorter than 
the one in Windows Desktop Explorer.

Observing those GUI file managers only tells us the refresh rate of that 
GUI, not the write speed for the app saving a file.

To measure write speed from LC it would be better to measure within LC 
itself, e.g.:

on mouseUp
  put the long seconds into t
  write "somedata" to url ("file:whatever")
  if the result is not empty then
 answer "Couldn't write file (" &sysError()&")"
 exit to top
  end if
  put the long seconds - t
end mouseUp

When run on similarly-configured iron, is there a significant difference 
between macOS and Windows?

When I isolate write speeds in this manner, I don't see a difference 
larger than could be explained by differences in hardware.

But given the frequent notes about perceived differences, it would be 
great if we could pin down the source of those disparities with some 
sort of test isolating the cause.

--
 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: Go to card has become slow

2020-04-06 Thread doc hawk via use-livecode

On Apr 5, 2020, at 11:18 AM, Bob Sneidar via use-livecode 
 wrote:
> 
> I don’t think LC accepts multiple statement transactions at all, does it?

I’d be dead int the water if it didn’t. ;)

I’m flat out *dependent* on these—opening a debtor in my software requires 
several hundred entries to be pulled, and at event few milliseconds of latency, 
this would be brutal.  I had an old version running with livecode’s mySQL 
version several years ago, and even after coming back for it to finish loading, 
the overhead from latenciy for repeated transactions made it simply unusable ( 
I think this was before I was stashing in a memory SQLite.  [I started with a 
file-bases SQLITE and an array of internal variables, and with a couple of 
intermediate steps, ended up with :memory: SQLite, and asynchronously  tapping 
Postgres every 30 seconds or so with updates.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

[ANN] This Week in LiveCode 220

2020-04-06 Thread panagiotis merakos via use-livecode

Hi all,

Read about new developments in LiveCode open source and the open source
community in today's edition of the "This Week in LiveCode" newsletter!

Read issue #220 here: https://bit.ly/2XdS03z

This is a weekly newsletter about LiveCode, focussing on what's been
going on in and around the open source project. New issues will be
released weekly on Mondays. We have a dedicated mailing list that will
deliver each issue directly to you e-mail, so you don't miss any!

If you have anything you'd like mentioned (a project, a discussion
somewhere, an upcoming event) then please get in touch.



-- 
Panagiotis Merakos 
LiveCode Software Developer

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

Re: Socket Help

Bob Sneidar wrote:

> I’m curious how this client server method handles multiple
> simultaneous connections? I had the idea of having a listener agent
> spawn an SQL Agent stack the first time a client connected, that would
> then listen on a random port. The listener agent would return the
> random port to the client which would then in the future communicate
> with the random SQL agent directly. A kind of passive connection if
> you will. I’m not sure all that is necessary though.
>
> I kept waking up all night thinking of ways to implement the
> encryption so that even a person with time to decipher the method
> would not be able to use it in subsequent captures.

Two rubrics that have saved me much time, effort, and unrest:

1. Unless you have a specific reason why another protocol is truly
   necessary, use HTTP.

   Tooling, documentation, simplicity, extensibility - it's all there,
   ready to use, right now.

2. Never roll your own security.

   Consider all the hours spent developing, testing, refining,
   reporting, revising, packaging, documenting.  No single human
   will ever replicate even a corner of that in an entire lifetime.
   And there's no need, since most of the best security options are
   Free and open.

--
 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: Maximum field height?


Bob Sneidar wrote:

> I’m curious though if a library could be created so that a handler for
> a mobile message (let’s say a touch message) could “translate” into a
> desktop message? In this way, the app on the mobile would send a
> mouseUp message to the target.

Why not?  Most developers I know do exactly that.

We all rewrite the same library, over and over, because it isn't in the box.

Newcomers will not know to do this, or how.

--
 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: Problems locating Android SDK


I'm setting up a new machine for Android development.

Where is the one-page list of steps on the livecode.com site that 
reliably guides a new user through this for all supported platforms 
(Mac, Win, Linux)?


This one fails:
http://lessons.livecode.com/m/2571/l/625198-livecode-and-android-studio


#CriticalDocumentationBugsThatTurnOffNewUsers

--
 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: Maximum field height?

2020-04-06 Thread J. Landman Gay via use-livecode

Touch messages already send duplicate mouse messages. In fact, unless you 
need two-finger zooming, you don't need touch handlers at all. I only use 
standard mouse handlers generally because they wotk on both mobile and desktop.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On April 6, 2020 10:02:19 AM Bob Sneidar via use-livecode 
 wrote:


There’s the rub I think. For RunRev (is the company still called that?) to 
make what mobile objects they can universal, and leave the others as is 
would then create a situation where developers would have to know what 
controls were universal, and which were Mobile/Desktop only. It just adds 
another layer of complexity.


I’m curious though if a library could be created so that a handler for a 
mobile message (let’s say a touch message) could “translate” into a desktop 
message? In this way, the app on the mobile would send a mouseUp message to 
the target.


Seems crazy I know. I’m just Pea Brain Storming.

Bob S


On Apr 5, 2020, at 9:20 PM, J. Landman Gay via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:


But there are features on mobile that don't exist on desktop. LC has 
provided for things like Android toasts and iOS popups. These things are 
one reason the language can't be entirely universal; mobile requires a 
different feature set. But it would be great if a scrolling field would 
just be a scrolling field everywhere. On the other hand, mobile lets you 
scroll all sorts of things (images, carousels, etc.) so we'd still need our 
mobile scroller anyway.


___
use-livecode mailing list
use-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: Our first Community Zoom Session

2020-04-06 Thread David Bovill via use-livecode

Me too!
On 6 Apr 2020, 11:40 +0100, Andre Garzia via use-livecode 
, wrote:
> Hi Folks,
>
> I missed the meeting, is there a recording available?
>
> Best
> A.
___
use-livecode mailing list
use-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

Hi Richard.

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.

I do the same thing for SQL queries, querying the exact same data on each 
device I tested on. There are seven individual queries performed for each 
“transaction” in the Main Form.

On my Mac, it takes about 1 to 2 seconds. On any of the Windows systems above, 
it takes 5 to 6 seconds, and one of the systems is the ACTUAL mySQL SERVER 
itself.

I am using sqlYoga to make the queries, but I’ve compared the time it takes to 
query using sqlYoga to mySQL Workbench, and the lag is very minimal (once I 
commented out the statements in libsqlYoga that saved the parent stack every 
time a query was run!)

I disabled Kaspersky during these tests to eliminate that possibility, and 
Defender is disabled domain wide by Group Policy.

My conclusion remains the same. Networking and File Operations on Windows is 
generally slower than on a Mac, or let’s call it *nix.

I can throw together a test app for you if you care to check my numbers.

Bob S


On Apr 5, 2020, at 10:30 AM, Richard Gaskin via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

I've been trying to sort through several reports about write speeds on Windows, 
but most examples I've seen conflate several different tasks. For example, the 
latest I came across had a mix of JSON translation and array manipulation in 
addition to writes, so diligent analysis would require pulling that example 
stack apart into three different tests to pinpoint the actual bottleneck.

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

2020-04-06 Thread Alex Tweedly via use-livecode

On 06/04/2020 03:55, scott--- via use-livecode wrote:

1. xTalk features just don't work, or work totally inadequately (e.g. scrolling
fields).

I feel this is overly harsh. Livecode fields (and the creation of native UIText
fields) do work on mobile. I think the issue is that the use of some objects
(like fields) on mobile is not as drag ’n' drop simple as it is on desktop. No
argument there.

Yes, it was harsh - but sometimes a little bit of hyperbole helps, if
only the mood of the speaker :-)

And, thinking about your and Jacque's responses, maybe my experience is
a bit out of date; I should try again.

But, afaik, it's not just scrolling fields; aren't there also issues
with keyboard input requiring you to scroll / move the field to remain
visible, or

And the fact that mobile-specific commands each need to be wrapped inside an
environment-check to keep from throwing an error in the IDE.

Yes, that's the kind of thing I meant in my item (2) "equivalence".

Many of the mobileXXX function have no desktop equivalent - but could
still be better named, and provide some empty response to ease
development on the desktop.

But others are actually useful features - and I see no reason why LC
shouldn't implement those as widgets for desktop (where feasible). Why
not have a mobilePick that works on desktop ? Or "pickDate", or
"pickContact" ? Or mobileCompose???mail ?

That way we'd be maintaining "platform equivalence" - and maybe even
giving desktop developers features that make LC an even better choice.

3. It's not "Live"Code. Developing for Mobile gets you back into the horrible
edit - compile (i.e. build a standalone) - test cycle.

I agree that there is much more of this needed for mobile since the IDE doesn’t
allow us to build directly on mobile (I’m not sure that is a bad thing.) I have
found simulators to be a good intermediary but it absolutely does require this
frequent build cycle for some aspects of development.
I found simulators completely useless. Though that may be because it was
a few years ago. And even then, you have the clumsiness of wiating for a
build/download/test cycle.

4. You still need to deal with the ugly issues of the SDKs and the app-store
requirements.

I suspect that jumping the security hoops like certificates and store portals are a
big reasons why even if "everyone can code” not everyone can see their mobile
creation made available to others. Learning how to navigate these added security
restrictions is time consuming and confusing (at least to me). Several people like
Trevore DeVore and Matthias Rebbe have been helping ease these complications for
desktop. I’m not sure what the answer is for mobile, though.

I should have made those two separate points.

4B. App store issues. Never got that far - though it sounds like it's pretty
annoying.
Build for a few people (and sidestep the store) - seems to be possible, but not
clear how easy it is.

Thanks for the reply - it has stiffened my resolve to have another go !!

-- Alex.

Re: Maximum field height?

I think that would kill the Apple Desktop OS.

Bob S


On Apr 6, 2020, at 6:37 AM, Paul Dupuis via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

Apple is absolutely working towards iOS and macOS being highly similar. 
However, if you're hoping that brings increased simplicity of application 
development to iOS, that isn't Apple's aim. The value to them of unification is 
to get macOS app into the same exclusivity an app store as iOS. Currently 
deployment of macOS apps can be through the macOS App store or outside of it. 
iOS app must be through the App store. Apple wants to gradually migrate the 
macOS base to the point where they can say macOS apps will only be available 
through the App store as well. Then they can drive the same developer changes 
on OSX that they do on iOS and take their same 30% cut.

___
use-livecode mailing list
use-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: Maximum field height?

There’s the rub I think. For RunRev (is the company still called that?) to make 
what mobile objects they can universal, and leave the others as is would then 
create a situation where developers would have to know what controls were 
universal, and which were Mobile/Desktop only. It just adds another layer of 
complexity.

I’m curious though if a library could be created so that a handler for a mobile 
message (let’s say a touch message) could “translate” into a desktop message? 
In this way, the app on the mobile would send a mouseUp message to the target.

Seems crazy I know. I’m just Pea Brain Storming.

Bob S


On Apr 5, 2020, at 9:20 PM, J. Landman Gay via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

But there are features on mobile that don't exist on desktop. LC has provided 
for things like Android toasts and iOS popups. These things are one reason the 
language can't be entirely universal; mobile requires a different feature set. 
But it would be great if a scrolling field would just be a scrolling field 
everywhere. On the other hand, mobile lets you scroll all sorts of things 
(images, carousels, etc.) so we'd still need our mobile scroller anyway.

___
use-livecode mailing list
use-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: Old Fossil seeks fast track assistance

2020-04-06 Thread Devin Asay via use-livecode

Graham,

I’ve just been through this gauntlet with my students. I provided some links 
and lessons for them at http://livecode.byu.edu/mobile/test-deploy-links.php. I 
found the process for setting up Android a little fraught with pitfalls, so I 
created an expanded instruction sheet for Android setup, linked to that page.

I’m staying with the latest Stable version of LiveCode for my class, 9.5.1. I’m 
running on Mac OS 10.14 Mojave. With this setup I have to use Xcode 10.1.

As a refresher, on developer.apple.com, you need to 
create your iOS developer certificate, register all of the UDIDs for your iOS 
devices, then create a wildcard provisioning profile for testing your apps. The 
provisioning profile must include all devices you want to test on.

A collection of links of instructions for distributing mobile apps: 
http://livecode.byu.edu/mobile/mobileAppDistribution.php.

I hope this will all help jog your memory. I find mine needs to be jogged every 
time I come back to this mobile stuff after a long time away.

Cheers,

Devin



On Apr 4, 2020, at 2:38 AM, Graham Samuel via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

Hi All - sorry this is a bit long, but I need help.

I’m a long term LC developer who more or less retired from development a couple 
of years ago, but I’ve kept on lurking in this list and trying rather 
hopelessly to remain up to date. My experience has been mostly on desktop apps, 
with a little iOS work. I haven’t ever done much on Android. I have just about 
retained my credentials as an Apple developer.

Now I find I really want to develop a mobile app at speed, and deploy it.

I don’t anticipate all that much difficulty in creating my app in the sense of 
designing and coding it - this can call on my own quite extensive experience of 
the past, the LC documentation and this invaluable list. I can reasonable hope 
to create a prototype in a few days. However there is a massive gap: testing 
and deployment.

I don’t have access to my most recent development machine (it’s in another 
country and I’m self-isolating), so I am working with an iMac that can only run 
MacOS High Sierra (and Windows 10 via Parallels, but I was hoping not to go 
there for this project). Now, I clearly need to organise the right version of 
XCode and the right SDK for my iOS development, and I need to do the equivalent 
thing for Android - and I don’t know how to do it.

For iOS, I THINK I need XCode 10.2, which I’m trying to download to replace the 
copy of 9.2 already on my machine. I obviously need to work with a compatible 
SDK. For Android, I don’t know where to start, so for now I am putting this on 
the back burner, but I will have to return to it eventually. Even when I’ve 
lined all this up (if indeed it’s feasible), I then need to remind myself how 
to test via simulators (I used to be good at this, so maybe that is not so 
scary, but I am not at all up to date) and then I need to get the app onto real 
hardware - starting with iPhones, as I’ve got a few of these. I really don’t 
know how to do this for testing, and more so I don’t know how to distribute a 
test version to a small population of testers, although I know this is 
feasible. The whole project may crash and burn at this beta testing stage, so 
actually getting it into the App Store can wait a bit.

Obviously I am not expecting people on this list to hold my hand at every step. 
My main concern is to be guided through the body of LC notes etc to get 
absolutely practical advice and recipes as to what to do at each stage. If I 
study the LC stuff long enough, I will get there, but I would dearly love help 
to fast-track it all.

Thanks

Graham
___
use-livecode mailing list
use-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: Socket Help