Re: What have I done now ? (aka CR and LF confusion)

[Mark Talluto via use-livecode]

On May 28, 2020, at 10:33 AM, Mark Wieder via use-livecode 
 wrote:
> 
> On 5/28/20 10:17 AM, Mark Talluto via use-livecode wrote:
>> I am a fan of moving Mac to default to LF. We use LF explicitly as our line 
>> ending of choice in all of our current software projects.
>> LF is useful if only to natively work with the expected line endings from 
>> Github and text files interchanged with Linux servers.
> 
> I agree, but have you tried adjusting your git core.autocrlf settings?

No. I was unaware. While this is very complete of them, standardizing has 
unified our experience and made it consistent. But, it is good to know that 
GitHub is accommodating. 


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: Code-signed apk fails

[matthias rebbe via use-livecode]

Good to hear that you´ve found the solution.



-
Matthias Rebbe
Life Is Too Short For Boring Code

> Am 28.05.2020 um 20:24 schrieb J. Landman Gay via use-livecode 
> :
> 
> Okay, here are the results of my tests, all done in LC 9.6rc2.
> 
> 1. Keystore: FPMobile.jks, included TSNet: fails to download files
> 2. Keystore: FPMobile.jks, TSNet removed: works
> 3. Keystore: FPMobile.keystore, included TSNet: works
> 
> So TSNet doesn't like "jks" extensions, which is the file extension Google 
> suggests. But I am baffled why a keystore would affect TSNet at all, not to 
> mention it only prevents file downloads. The user can log in normally, make 
> php queries to the server and get replies, the only thing that fails is 
> actually downloading files.
> 
> Panos, is this bug-worthy? Or is it a documentation thing?
> 
> 
> On 5/28/20 8:03 AM, panagiotis merakos via use-livecode wrote:
>> Hello Jacque,
>> I did a quick test, I put this in a button:
>> get url "https://google.com
>> "
>> put it into fld "url"
>> and signed the .apk with a release.keystore, and it works as expected for
>> me. The stack includes tsNet - I used LC 9.6 RC-2 for this.
>> Could you file a bug report with a recipe about this issue, and attach your
>> stack (or send it to me directly if it is confidential), so as we
>> investigate?
>> Kind regards,
>> Panos
>> --
> 
> 
> 
> -- 
> 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 
> 
___
use-livecode mailing list
use-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: Special Paste

[Peter Bogdanoff via use-livecode]

Hi Charles,

Is this what you’re looking for?:

put the clipboardData["html"] into tStoredData
put the fullClipboardData["text"] into tData
set the clipboardData to tData
paste
set the clipboardData["html"] to tStoredData

Peter Bogdanoff


> On May 28, 2020, at 7:04 AM, Charles Szasz via use-livecode 
>  wrote:
> 
> Both Apple's Pages and Microsoft’s Word software have key commands for 
> pasting text into an existing document to match the current formatting 
> (font). How do you script to accomplish this when copying text to the 
> clipboard in a button so the user does not have to use keyboard commands?
> 
> Sent from my iPad
> ___
> use-livecode mailing list
> use-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: ADA Compliency

[Paul Dupuis via use-livecode]

On 5/26/2020 6:56 PM, Dan Friedman via use-livecode wrote:

Has anyone done anything in regards to ADA compliancy in mobile apps built with 
LiveCode?   Using the apple or android accessibility tools such as Screen 
reading, for example.




I have been periodically looking at assistive technologies for LiveCode 
built applications on desktop platforms (vs mobile) over the years. 
Certain OS bases assistive tool like screen magnifiers do work as they 
are application independent. Unfortunately, screen readers and voice 
recognition tools generally don't work with LiveCode because the 
application independent tools look to act on OS native controls which 
most LC app don't use through out.


With LC 9 and the FFI/Widgets it may be possible to build integration 
libraries for one or more of those assistive tools that require 
application specific integration, but I don't think anyone has done it.


For mobile ADA compliance, you best bet is to test your app with 
whatever OS level assistive tools are provided with iOS and Android or 
look in the associated App store for application independent assistive 
app to test with your app.


If you mobile uses all native controls it *may* work better with OS or 
3rd party assistive tool, but that is a guess. I have no mobile app 
experience.



___
use-livecode mailing list
use-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: Code-signed apk fails

[J. Landman Gay via use-livecode]

Okay, here are the results of my tests, all done in LC 9.6rc2.

1. Keystore: FPMobile.jks, included TSNet: fails to download files
2. Keystore: FPMobile.jks, TSNet removed: works
3. Keystore: FPMobile.keystore, included TSNet: works

So TSNet doesn't like "jks" extensions, which is the file extension Google suggests. But I am 
baffled why a keystore would affect TSNet at all, not to mention it only prevents file 
downloads. The user can log in normally, make php queries to the server and get replies, the 
only thing that fails is actually downloading files.


Panos, is this bug-worthy? Or is it a documentation thing?


On 5/28/20 8:03 AM, panagiotis merakos via use-livecode wrote:

Hello Jacque,

I did a quick test, I put this in a button:

get url "https://google.com
"
put it into fld "url"

and signed the .apk with a release.keystore, and it works as expected for
me. The stack includes tsNet - I used LC 9.6 RC-2 for this.

Could you file a bug report with a recipe about this issue, and attach your
stack (or send it to me directly if it is confidential), so as we
investigate?

Kind regards,
Panos
--





--
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: Code-signed apk fails

[J. Landman Gay via use-livecode]

I'm fairly sure that's the reason the file dialog didn't enable the .jks file, but the file 
still works. I used Google's terminal command example, which creates .jks files, instead of 
LC's example which I think uses .keystore. Next time I'll change the extension just to make 
file selection easier.


On 5/28/20 6:40 AM, JeeJeeStudio via use-livecode wrote:

The normal exstension is .keystore , maybe that's the reason?


Op 28-5-2020 om 08:52 schreef J. Landman Gay via use-livecode:
We're about to release an Android app. I've been signing it for development only and it works 
well. Today I created a keystore "FPMobile.jks" in Terminal as usual.


As an aside, I got this in Terminal:
Warning:
The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is 
an industry standard format using "keytool -importkeystore -srckeystore FPMobile.jks 
-destkeystore FPMobile.jks -deststoretype pkcs12".


I don't know if that's significant. I've ignored it in the past, so I went ahead and entered 
the jks file in standalone settings. When LC 9.6rc2 asked me to locate the keystore during 
the build, I was unable to select it in the file dialog until I chose "All files". That 
seemed to work and the build finished.


At any rate the real problem:

The codesigned app fails to download files from the server. My error log shows that sometimes 
there is no error at all but nothing is downloaded, other times the error is vague: "Invalid 
URL:" with no URL indicated. The same script and URLs work in the IDE and in the apk when 
built without the keystore.


I don't think codesigning should affect server queries but that seems to be what's happening. 
I rebuilt the apk without any changes except to remove the keystore and it worked perfectly 
again. Could TSNet be involved somehow?


I'm not sure where to look for the fault. Ideas?



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



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

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

Re: Code-signed apk fails

[J. Landman Gay via use-livecode]

On 5/28/20 5:24 AM, matthias rebbe via use-livecode wrote:

did you already try to build the .apk without tsNet?  This way you could check 
if tsNET is involved.
You need to do the 2 steps before building the .apk
1. executedispatch "revUnloadLibrary" to stack "tsNetLibUrl"in message 
box
(btw. to load it again after building the standalone execute dispatch 
"revLoadLibrary" to stack "tsNetLibUrl" - no need to restart LC IDE )
2. if "Select inclusions for..." is selected, then deselect tsNET external in 
standalone settings.

Now build the .apk with the keystore.
If the .apk is able now to download the files although it is signed, then tsNET 
is involved.


I did this. Without TSNet, the apk works perfectly again. Now I wonder if I can do without 
TSNet for now.


--
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: What have I done now ? (aka CR and LF confusion)

[Mark Wieder via use-livecode]

On 5/28/20 10:17 AM, Mark Talluto via use-livecode wrote:

I am a fan of moving Mac to default to LF. We use LF explicitly as our line 
ending of choice in all of our current software projects.
LF is useful if only to natively work with the expected line endings from 
Github and text files interchanged with Linux servers.


I agree, but have you tried adjusting your git core.autocrlf settings?

--
 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: What have I done now ? (aka CR and LF confusion)

[Mark Talluto via use-livecode]

I am a fan of moving Mac to default to LF. We use LF explicitly as our line 
ending of choice in all of our current software projects. 
LF is useful if only to natively work with the expected line endings from 
Github and text files interchanged with Linux servers. 


Best regards,

Mark Talluto
livecloud.io 
nursenotes.net 
canelasoftware.com 


> On May 28, 2020, at 9:14 AM, Brian Milby via use-livecode 
>  wrote:
> 
> Just changes CR to LF.  2 files updated.
> https://github.com/livecode/livecode/pull/7214/files
> 
> On Thu, May 28, 2020 at 12:10 PM Richard Gaskin via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> Alex Tweedly wrote:
>> 
>>> Re. a PR to change it, it does seem it will run into concerns about
>>> backward compatability. Is it likely to succeed to propose a new
>>> URL-type - maybe "textfile".
>> 
>> What exactly does the PR do?
>> 
>> If it changes default Mac line endings from CR to LF, thumbs up.

___
use-livecode mailing list
use-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: What have I done now ? (aka CR and LF confusion)

[Brian Milby via use-livecode]

Just changes CR to LF.  2 files updated.
https://github.com/livecode/livecode/pull/7214/files

On Thu, May 28, 2020 at 12:10 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Alex Tweedly wrote:
>
>  > Re. a PR to change it, it does seem it will run into concerns about
>  > backward compatability. Is it likely to succeed to propose a new
>  > URL-type - maybe "textfile".
>
> What exactly does the PR do?
>
> If it changes default Mac line endings from CR to LF, thumbs up.
>
>
>
___
use-livecode mailing list
use-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: What have I done now ? (aka CR and LF confusion)

[Brian Milby via use-livecode]

binfile is just short for binary file... it means that the file is written
exactly as presented.  If you use encode (UTF8/16 etc) then you need to use
it anyway.

The PR is a pretty much single constant update (changes CR to LF for Mac
line ending).

The backwards compatibility issue is a very minor edge case.  To be
impacted you need to export text from LiveCode which uses CR where a
non-LiveCode app/process consumes the data and requires the CR line
ending.  LiveCode file in/out will automatically convert, so there would be
no impact to a LiveCode generated application that uses file for in/out.

On Thu, May 28, 2020 at 11:21 AM Alex Tweedly via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Thanks Brian, that was a very helpful and clear description. It's
> amazing that I've been an active Runrev/livecode for nearly 20 years and
> not been affected by this until now :-)
>
> Re. a PR to change it, it does seem it will run into concerns about
> backward compatability. Is it likely to succeed to propose a new
> URL-type - maybe "textfile".
>
> Then you could do
>
>put tData into URL "textfile:tiny.txt"   to get the sane behaviour
>
> but continue to do
>
>put tData into URL "file:tiny.txt"   to get the existing behaviour
>
> To me, it feels like a better self-documenting case - binfile vs
> textfile, rather than binfile vs file.
>
> Alex.
>
>
> On 28/05/2020 03:15, Brian Milby via use-livecode wrote:
> > You need to use binfile on Mac to get sane line endings.  I have a PR to
> fix, but doubt it will get merged.
> >
> > On Mac/Windows, file will convert line endings to what LC thinks is the
> native one for the OS.  CRLF for Windows and CR for Mac (the real CR, not
> the one that LC uses internally where CR and LF are synonyms for LF).  So
> on Linux you can use either file or binfile, on Windows you need to use
> file, and on Mac you need to use binfile to get the currently expected line
> endings.
> >
> > Thanks,
> > Brian
> > On May 27, 2020, 9:24 PM -0400, Alex Tweedly via use-livecode <
> use-livecode@lists.runrev.com>, wrote:
> >> I don't know if I've done something to my LC prefs, or to my Mac, or to
> >> myself :-)
> >>
> >> the following script
> >>
> >>> on mouseUp
> >>> local t
> >>> put "asd" & CR & "qwe" & CR & "zxc" &CR into t
> >>> put t into URL ("file:/Users/alextweedly/tiny.txt")
> >>> end mouseUp
> >> does create a file - but that file can't be (easily, properly) used by
> >> some other Mac apps, because all the end-of-line characters are 0x0d
> >> (i.e. numtochar(13)). So unix utilities like wc, cat, grep, more, ...
> >> won't deal with it properly - though emacs, Sublime, Coda2, etc. do ok.
> >>
> >> If I create the same file in an editor (emacs, Sublime Text, ...) they
> >> all produce e-o-l characters which are 0x0A (i.e. numtochar(10)), and
> >> this works in both editors and utilities mentioned above, as well as LC.
> >>
> >> Maybe it's always been like this ??
> >>
> >> I don't know - I just noticed because I tried to 'grep' for some
> >> characters in all files within a folder, and didn't find anything
> >> (though I should have done).
> >>
> >> SO I can get by - just avoid using any files created within LC with any
> >> other apps - but I'd rather find out if I should be doing something
> >> different, or if I've accidentally changed some setting that causes
> this.
> >>
> >> Thanks for any thoughts,
> >>
> >> Alex.
> >>
> >>
> >> ___
> >> use-livecode mailing list
> >> use-livecode@lists.runrev.com
> >> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> >> http://lists.runrev.com/mailman/listinfo/use-livecode
> > ___
> > use-livecode mailing list
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: What have I done now ? (aka CR and LF confusion)

[Richard Gaskin via use-livecode]

Alex Tweedly wrote:

> Re. a PR to change it, it does seem it will run into concerns about
> backward compatability. Is it likely to succeed to propose a new
> URL-type - maybe "textfile".

What exactly does the PR do?

If it changes default Mac line endings from CR to LF, thumbs up.

macOS is a certified Unix, and has been for more than 20 years.  LF is 
the OS-default line ending. Command-line tools expect LF, and the GUI 
apps I've explored this in accept both where they use CR at all.


So while I can understand a concern about backward compatibility, it 
seems this one really only applies to a relatively small subset of edge 
cases for those depending on the simpler non-binary syntax for a 
specific binary sequence.


The simpler non-binary syntax is there to make things, well, simple.

Those needing a specific binary sequence should expect to use the binary 
syntax, while everyone else can enjoy simple file I/O reliably.


Keep in mind that "everyone else" includes what we hope will be a much 
larger audience of future users than the sum of all users to date.  Why 
plan for no-growth?  And even among current users, as in this thread it 
seems most expect the default to use the OS'es current default, not 
something leftover from the '90s.


Am I missing something?

LC has a very strong and favorable history of maintaining backward 
compatibility, far beyond anything I've seen with any other language.


I wonder sometimes if we take it too far, if maybe the rest of the world 
isn't wrong in sometimes allowing for the inevitable changes that take 
place in OSes.


From time to time LC does deprecate and change things, and sometimes 
that means a little extra work for folks moving to a newer engine.  But 
given how rarely this happens, I don't think folks would mind another 
rare moment of change, esp. one that seems far more an improvement for 
most devs than a problem.


--
 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: What have I done now ? (aka CR and LF confusion)

[Alex Tweedly via use-livecode]

Thanks Brian, that was a very helpful and clear description. It's 
amazing that I've been an active Runrev/livecode for nearly 20 years and 
not been affected by this until now :-)


Re. a PR to change it, it does seem it will run into concerns about 
backward compatability. Is it likely to succeed to propose a new 
URL-type - maybe "textfile".


Then you could do

  put tData into URL "textfile:tiny.txt"   to get the sane behaviour

but continue to do

  put tData into URL "file:tiny.txt"   to get the existing behaviour

To me, it feels like a better self-documenting case - binfile vs 
textfile, rather than binfile vs file.


Alex.


On 28/05/2020 03:15, Brian Milby via use-livecode wrote:

You need to use binfile on Mac to get sane line endings.  I have a PR to fix, 
but doubt it will get merged.

On Mac/Windows, file will convert line endings to what LC thinks is the native 
one for the OS.  CRLF for Windows and CR for Mac (the real CR, not the one that 
LC uses internally where CR and LF are synonyms for LF).  So on Linux you can 
use either file or binfile, on Windows you need to use file, and on Mac you 
need to use binfile to get the currently expected line endings.

Thanks,
Brian
On May 27, 2020, 9:24 PM -0400, Alex Tweedly via use-livecode 
, wrote:

I don't know if I've done something to my LC prefs, or to my Mac, or to
myself :-)

the following script


on mouseUp
    local t
    put "asd" & CR & "qwe" & CR & "zxc" &CR into t
    put t into URL ("file:/Users/alextweedly/tiny.txt")
end mouseUp

does create a file - but that file can't be (easily, properly) used by
some other Mac apps, because all the end-of-line characters are 0x0d
(i.e. numtochar(13)). So unix utilities like wc, cat, grep, more, ...
won't deal with it properly - though emacs, Sublime, Coda2, etc. do ok.

If I create the same file in an editor (emacs, Sublime Text, ...) they
all produce e-o-l characters which are 0x0A (i.e. numtochar(10)), and
this works in both editors and utilities mentioned above, as well as LC.

Maybe it's always been like this ??

I don't know - I just noticed because I tried to 'grep' for some
characters in all files within a folder, and didn't find anything
(though I should have done).

SO I can get by - just avoid using any files created within LC with any
other apps - but I'd rather find out if I should be doing something
different, or if I've accidentally changed some setting that causes this.

Thanks for any thoughts,

Alex.


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

Special Paste

[Charles Szasz via use-livecode]

Both Apple's Pages and Microsoft’s Word software have key commands for pasting 
text into an existing document to match the current formatting (font). How do 
you script to accomplish this when copying text to the clipboard in a button so 
the user does not have to use keyboard commands?

Sent from my iPad
___
use-livecode mailing list
use-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: Code-signed apk fails

[panagiotis merakos via use-livecode]

Hello Jacque,

I did a quick test, I put this in a button:

get url "https://google.com
"
put it into fld "url"

and signed the .apk with a release.keystore, and it works as expected for
me. The stack includes tsNet - I used LC 9.6 RC-2 for this.

Could you file a bug report with a recipe about this issue, and attach your
stack (or send it to me directly if it is confidential), so as we
investigate?

Kind regards,
Panos
--



On Thu, 28 May 2020 at 14:41, JeeJeeStudio via use-livecode <
use-livecode@lists.runrev.com> wrote:

> The normal exstension is .keystore , maybe that's the reason?
>
>
> Op 28-5-2020 om 08:52 schreef J. Landman Gay via use-livecode:
> > We're about to release an Android app. I've been signing it for
> > development only and it works well. Today I created a keystore
> > "FPMobile.jks" in Terminal as usual.
> >
> > As an aside, I got this in Terminal:
> > Warning:
> > The JKS keystore uses a proprietary format. It is recommended to
> > migrate to PKCS12 which is an industry standard format using "keytool
> > -importkeystore -srckeystore FPMobile.jks -destkeystore FPMobile.jks
> > -deststoretype pkcs12".
> >
> > I don't know if that's significant. I've ignored it in the past, so I
> > went ahead and entered the jks file in standalone settings. When LC
> > 9.6rc2 asked me to locate the keystore during the build, I was unable
> > to select it in the file dialog until I chose "All files". That seemed
> > to work and the build finished.
> >
> > At any rate the real problem:
> >
> > The codesigned app fails to download files from the server. My error
> > log shows that sometimes there is no error at all but nothing is
> > downloaded, other times the error is vague: "Invalid URL:" with no URL
> > indicated. The same script and URLs work in the IDE and in the apk
> > when built without the keystore.
> >
> > I don't think codesigning should affect server queries but that seems
> > to be what's happening. I rebuilt the apk without any changes except
> > to remove the keystore and it worked perfectly again. Could TSNet be
> > involved somehow?
> >
> > I'm not sure where to look for the fault. Ideas?
> >
>
> ___
> use-livecode mailing list
> use-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: ADA Compliency

[Mike Kerner via use-livecode]

Oh gawd, I had an ancient college sweaty OMG FINALS panic attack, because I
thought you wrote Ada, not ADA.


On Tue, May 26, 2020 at 6:57 PM Dan Friedman via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Has anyone done anything in regards to ADA compliancy in mobile apps built
> with LiveCode?   Using the apple or android accessibility tools such as
> Screen reading, for example.
>
> -Dan
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>


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

Re: Code-signed apk fails

[JeeJeeStudio via use-livecode]

The normal exstension is .keystore , maybe that's the reason?


Op 28-5-2020 om 08:52 schreef J. Landman Gay via use-livecode:
We're about to release an Android app. I've been signing it for 
development only and it works well. Today I created a keystore 
"FPMobile.jks" in Terminal as usual.


As an aside, I got this in Terminal:
Warning:
The JKS keystore uses a proprietary format. It is recommended to 
migrate to PKCS12 which is an industry standard format using "keytool 
-importkeystore -srckeystore FPMobile.jks -destkeystore FPMobile.jks 
-deststoretype pkcs12".


I don't know if that's significant. I've ignored it in the past, so I 
went ahead and entered the jks file in standalone settings. When LC 
9.6rc2 asked me to locate the keystore during the build, I was unable 
to select it in the file dialog until I chose "All files". That seemed 
to work and the build finished.


At any rate the real problem:

The codesigned app fails to download files from the server. My error 
log shows that sometimes there is no error at all but nothing is 
downloaded, other times the error is vague: "Invalid URL:" with no URL 
indicated. The same script and URLs work in the IDE and in the apk 
when built without the keystore.


I don't think codesigning should affect server queries but that seems 
to be what's happening. I rebuilt the apk without any changes except 
to remove the keystore and it worked perfectly again. Could TSNet be 
involved somehow?


I'm not sure where to look for the fault. Ideas?



___
use-livecode mailing list
use-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: Code-signed apk fails

[matthias rebbe via use-livecode]

Jacque,

did you already try to build the .apk without tsNet?  This way you could check 
if tsNET is involved.
You need to do the 2 steps before building the .apk
1. executedispatch "revUnloadLibrary" to stack "tsNetLibUrl"in message 
box
(btw. to load it again after building the standalone execute dispatch 
"revLoadLibrary" to stack "tsNetLibUrl" - no need to restart LC IDE )
2. if "Select inclusions for..." is selected, then deselect tsNET external in 
standalone settings.

Now build the .apk with the keystore.
If the .apk is able now to download the files although it is signed, then tsNET 
is involved.

If the .apk still does not download, then i would try to convert the keystore 
file to the new format as suggested in the warning message and would try to use 
that file during standalone building.


And if you are on Mac and if your time allows could you try an older LC version 
to build the .apk. e.g. 9.6.0 DP3. According to the FAQ at Livecode.com 

all DP versions are not notarized:
"Our test releases (DP versions) will not be fully notarized and you will still 
need to do this. Future Stable releases will be notarized and will not need 
whitelisting."

So RC1 and RC2 could be notarized and who knows, if or if not  the notarization 
process touched the Android externals of tsNET in some way. But that´s just a 
shot in the dark.


Matthias




-
Matthias Rebbe
Life Is Too Short For Boring Code

> Am 28.05.2020 um 08:52 schrieb J. Landman Gay via use-livecode 
> :
> 
> We're about to release an Android app. I've been signing it for development 
> only and it works well. Today I created a keystore "FPMobile.jks" in Terminal 
> as usual.
> 
> As an aside, I got this in Terminal:
> Warning:
> The JKS keystore uses a proprietary format. It is recommended to migrate to 
> PKCS12 which is an industry standard format using "keytool -importkeystore 
> -srckeystore FPMobile.jks -destkeystore FPMobile.jks -deststoretype pkcs12".
> 
> I don't know if that's significant. I've ignored it in the past, so I went 
> ahead and entered the jks file in standalone settings. When LC 9.6rc2 asked 
> me to locate the keystore during the build, I was unable to select it in the 
> file dialog until I chose "All files". That seemed to work and the build 
> finished.
> 
> At any rate the real problem:
> 
> The codesigned app fails to download files from the server. My error log 
> shows that sometimes there is no error at all but nothing is downloaded, 
> other times the error is vague: "Invalid URL:" with no URL indicated. The 
> same script and URLs work in the IDE and in the apk when built without the 
> keystore.
> 
> I don't think codesigning should affect server queries but that seems to be 
> what's happening. I rebuilt the apk without any changes except to remove the 
> keystore and it worked perfectly again. Could TSNet be involved somehow?
> 
> I'm not sure where to look for the fault. Ideas?
> 
> -- 
> 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

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