Re: Failure to build on Android.

2019-05-16 Thread Monte Goulding via use-livecode
Hmm… did they have the same application identifier?

> On 17 May 2019, at 1:12 pm, Sannyasin Brahmanathaswami via use-livecode 
>  wrote:
> 
> You were right, plus caveat. You cannot test, with the same development key, 
> two different stacks.
> 
> it was balking at having "rotationTest9.livecode" on the phone at the same 
> time
> 
> Once I deleted "rotationTest9.livecode", then "myApp.app" was installed 
> without errors.
> 
> BR
> 
> On 5/16/19, 11:23 AM, "use-livecode on behalf of Monte Goulding via 
> use-livecode"  use-livecode@lists.runrev.com> wrote:
> 
>I think it’s complaining the version of your app is lower that the 
> installed version. Perhaps either bump it up or manually delete the installed 
> version.
> 
> ___
> use-livecode mailing list
> use-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: Failure to build on Android.

2019-05-16 Thread Sannyasin Brahmanathaswami via use-livecode
You were right, plus caveat. You cannot test, with the same development key, 
two different stacks.

it was balking at having "rotationTest9.livecode" on the phone at the same time

Once I deleted "rotationTest9.livecode", then "myApp.app" was installed without 
errors.

BR

On 5/16/19, 11:23 AM, "use-livecode on behalf of Monte Goulding via 
use-livecode"  wrote:

I think it’s complaining the version of your app is lower that the 
installed version. Perhaps either bump it up or manually delete the installed 
version.

___
use-livecode mailing list
use-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: Seeking confirmation of a bug...

2019-05-16 Thread Paul Dupuis via use-livecode

On 5/16/2019 7:35 PM, Richard Gaskin via use-livecode wrote:

Paul Dupuis wrote:

> I am sometimes astonished that a bug like this can go undetected
> through so many releases. It causes me to worry about the adoption
> of LC as a serious commercial application building tool.

This is why I do my daily work in the latest available build, and 
encourage others to do the same.


I completely agree. I am now on LC9 for everything - 904 and tomorrow 
(didn't have time today) I'll download 905. HT450 and HT200 are on LC9 
and in mid-beta. It makes so many thing easier to be current on the engine.


I had though that given how text intensive HR is, that I would have had 
a lot of work to adjust to "Unicode everywhere", but there was 
surprisingly little. Lots for the adjustment to DirectShow. And there is 
lots of text handling that can now be simplified under LC9, but very 
little I had to do becase the move from LC6.7.11 to LC9 broke something. 
That amazed me that the folks in Scotland made such a huge engine change 
that backwards compatible.


And it's why I'm generally happy with the progress on issues I report.


I have to say Monte fix for this bug may have set a new record! (Thanks 
again Monte!)




When I work in the latest build, I see issues that affect my work 
quickly. I report them quickly.  And, as we've seen here, they're 
often resolved quickly.


I find that true as well. I've reported a fair number of bugs against 
versions of 9 and they have all been resolved very quickly.




LC has thousands of features, with gawdknowshowmany options for using 
them all, a combinatorial explosion of possibilities. The odds that 
someone else might happen to need the same mix of options my work 
relies on seem low.


So I use the current version.

I everyone did, issues like this would be found sooner, and resolved 
sooner.


I wish more people who find bugs took the time to file quality bug 
reports - with recipes and/or test stacks. It is sometime a pain to add 
that to a busy day, but my experience has been it always pays off with a 
fix for the bug in reasonable time, sometimes fast enough that 
work-around code is not necessary.



___
use-livecode mailing list
use-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: Resize Stack Sent Everytime a Stack Opens?

2019-05-16 Thread Sannyasin Brahmanathaswami via use-livecode
OK with the help of Brian off list I go something going! But I have a 
confession to make and a bug to report

1) in middle of the script, in logging, I used a

Put "somevalue" into fld "log"

Which of course removed anything before that, including a "resize" stack, which 
had log entries.

2) But, it not all my fault (hehe)  With Brian's help  (and Richard 
persistently point by point "what should happen, if is it not, it is a 
bug...,") I learned that
 a) orientationChanged fires first, and then 
b) resizestack, x,y,oldX,oldY fire next and *then* it renders.
 (needs to be in the dictionary!) 

Simple! I  made a clone of the production stack, copied the new behavior script 
made Brian's  with help  (Thanks Brian!) and made a little light weight 
standalone for testing and it worked.
 
So I thought "ahha gotcha now" and copied the stack into my modular framework, 
back in, and tested it. It did not work! But they are virtually identical? What 
could be wrong? The only thing was how it was opened, by the IDE and by my code?

Well the reason for my going around in circles about resizestack not firing, 
is, because the resizestack is not fired if you "go to stack in window..."

   if (cardOrStackObject  is not among the items of tLandScapeModeStacks) AND  \
 (trueword 2 of cardOrStackObject  is not among the items of 
tLandScapeModeStacks) AND \
 (oStackName is not among the items of  tLandScapeModeStacks) then
   --go cardOrStackObject in stack oStackName 
 # you do this, you get nothing in resizestack
  --close stack oStackName   
  # I changed to this:
 close stack oStackName  
  go cardOrStackObject

   else
  ntInfo "close one; open next"
  close stack oStackName  
  go cardOrStackObject
   end if

And so, I was fight my geometry handlers when it was in really the navigation, 
from one stack to the next.  All of the above gets reduced to :

  ntInfo "close one; open next"
  close stack oStackName  
  go cardOrStackObject

BR





On 5/13/19, 6:26 PM, "use-livecode on behalf of Brian Milby via use-livecode" 
 wrote:

I'll send a copy of the stack separately, but here are my thoughts:
- Caveat that I only have an Amazon Fire available for testing
- resizeStack does get called, before openCard on card Loader
- no field "log" exists on card "Loader" which is probably why resizeStack
was not working
- I added "addLog" and "clearLog" handlers to allow for logging from any
card
- when launched, I get a "resizeStack 600,952,414,736" call
- nav bar is never positioned off screen

I made the above notes on LC 9.0.1; I then installed 9.0.4 and found
different issues

- there is a visible shift of the log box (corrected with below changes)
- moved script locals to preOpenStack so they would be available sooner
- moved orientation code to preOpenStack

Thanks,
Brian

___
use-livecode mailing list
use-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: Seeking confirmation of a bug...

2019-05-16 Thread Richard Gaskin via use-livecode

Paul Dupuis wrote:

> I am sometimes astonished that a bug like this can go undetected
> through so many releases. It causes me to worry about the adoption
> of LC as a serious commercial application building tool.

This is why I do my daily work in the latest available build, and 
encourage others to do the same.


And it's why I'm generally happy with the progress on issues I report.

When I work in the latest build, I see issues that affect my work 
quickly. I report them quickly.  And, as we've seen here, they're often 
resolved quickly.


LC has thousands of features, with gawdknowshowmany options for using 
them all, a combinatorial explosion of possibilities. The odds that 
someone else might happen to need the same mix of options my work relies 
on seem low.


So I use the current version.

I everyone did, issues like this would be found sooner, and resolved sooner.

--
 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: Seeking confirmation of a bug...

2019-05-16 Thread Paul Dupuis via use-livecode

Thank you Monte!

I just finished dinner and was sitting down to enter a new bug when I 
saw you had already done it!



On 5/16/2019 6:30 PM, Monte Goulding via use-livecode wrote:



On 17 May 2019, at 7:29 am, Monte Goulding via use-livecode 
 wrote:


I just added an updated test stack that showed another issue of only a single 
file type is specified. If you have have a chance could you check that the fix 
addresses that use case too?

I think it would be best to open a separate report about the inconsistency when 
there’s only a single type specified. The original report is a clear regression 
from the refactor while the difference between mac and win when only a single 
type is specified was always the case I think. We need to figure out whether to 
document the inconsistency or fix for one platform or the other. Note that this 
command setting both it and the result is actually a documented anomaly so 
perhaps if we have the choice the result should be cleared.


I opened this separate issue for the platform inconsistency issue which is 
worse on Linux as it doesn’t set the result at all 
https://quality.livecode.com/show_bug.cgi?id=22071
  
___
use-livecode mailing list
use-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: Seeking confirmation of a bug...

2019-05-16 Thread Monte Goulding via use-livecode


> On 17 May 2019, at 7:29 am, Monte Goulding via use-livecode 
>  wrote:
> 
>> I just added an updated test stack that showed another issue of only a 
>> single file type is specified. If you have have a chance could you check 
>> that the fix addresses that use case too?
> 
> I think it would be best to open a separate report about the inconsistency 
> when there’s only a single type specified. The original report is a clear 
> regression from the refactor while the difference between mac and win when 
> only a single type is specified was always the case I think. We need to 
> figure out whether to document the inconsistency or fix for one platform or 
> the other. Note that this command setting both it and the result is actually 
> a documented anomaly so perhaps if we have the choice the result should be 
> cleared.


I opened this separate issue for the platform inconsistency issue which is 
worse on Linux as it doesn’t set the result at all 
https://quality.livecode.com/show_bug.cgi?id=22071
 
___
use-livecode mailing list
use-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: Seeking confirmation of a bug...

2019-05-16 Thread Monte Goulding via use-livecode


> On 17 May 2019, at 6:25 am, Paul Dupuis via use-livecode 
>  wrote:
> 
> Thank you Monte!
> 
> I just added an updated test stack that showed another issue of only a single 
> file type is specified. If you have have a chance could you check that the 
> fix addresses that use case too?

I think it would be best to open a separate report about the inconsistency when 
there’s only a single type specified. The original report is a clear regression 
from the refactor while the difference between mac and win when only a single 
type is specified was always the case I think. We need to figure out whether to 
document the inconsistency or fix for one platform or the other. Note that this 
command setting both it and the result is actually a documented anomaly so 
perhaps if we have the choice the result should be cleared.

> On 17 May 2019, at 6:52 am, Mark Wieder via use-livecode 
>  wrote:
> 
> On 5/16/19 12:53 PM, Monte Goulding via use-livecode wrote:
>> https://github.com/livecode/livecode/pull/7056 
>> 
> 
> Wow! That was a fast fix!

Haha… well I’m shifting my body clock from Tasmanian time to San Jose time over 
the next few days so up today at 5AM and this seemed helpful to sort out. 
Tomorrow it’s 4AM 

Cheers

Monte
___
use-livecode mailing list
use-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: Failure to build on Android.

2019-05-16 Thread Monte Goulding via use-livecode
I think it’s complaining the version of your app is lower that the installed 
version. Perhaps either bump it up or manually delete the installed version.

> On 17 May 2019, at 6:42 am, Sannyasin Brahmanathaswami via use-livecode 
>  wrote:
> 
> Less that 36 hour went by,  when I could build on Android.
> 
> Then today, 9.0.4 and also 9.0.5 (rc1) (# congratulations to team!)
> 
> I am getting the from the Development→Test Target--> Android [id#]
> 
> Installation of app failed: adb: fail to install
> /private/var/folders/t8/70nlq/T/TemporaryItems/tmp.442.ljdgCONh.apk
> Failure [INSTALL_FAILED_VERSION_DOWNGRADE]
> 
> ===
> Mac, Mojave, jdk 1.8.0_171.jdk
> 
> Which, according release notes, should still work (has all along)
> 
> Moto6
> Android 8.0.0 
> 
> 
> ___
> use-livecode mailing list
> use-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: Seeking confirmation of a bug...

2019-05-16 Thread Mark Wieder via use-livecode

On 5/16/19 12:53 PM, Monte Goulding via use-livecode wrote:

https://github.com/livecode/livecode/pull/7056 



Wow! That was a fast fix!

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


Failure to build on Android.

2019-05-16 Thread Sannyasin Brahmanathaswami via use-livecode
Less that 36 hour went by,  when I could build on Android.

Then today, 9.0.4 and also 9.0.5 (rc1) (# congratulations to team!)

I am getting the from the Development→Test Target--> Android [id#]

Installation of app failed: adb: fail to install
/private/var/folders/t8/70nlq/T/TemporaryItems/tmp.442.ljdgCONh.apk
Failure [INSTALL_FAILED_VERSION_DOWNGRADE]

===
Mac, Mojave, jdk 1.8.0_171.jdk

Which, according release notes, should still work (has all along)

Moto6
Android 8.0.0 


___
use-livecode mailing list
use-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: Seeking confirmation of a bug...

2019-05-16 Thread Paul Dupuis via use-livecode

Thank you Monte!

I just added an updated test stack that showed another issue of only a 
single file type is specified. If you have have a chance could you check 
that the fix addresses that use case too?


Thanks!

On 5/16/2019 3:53 PM, Monte Goulding via use-livecode wrote:

https://github.com/livecode/livecode/pull/7056 



On 17 May 2019, at 5:43 am, Monte Goulding via use-livecode 
 wrote:

Hi Paul

I can confirm it is broken. I’ll patch it this morning. If it has been broken 
at some point during the refactor as the blame commit hash is a merge at that 
time. It’s an easy fix though which is good ;-)

Cheers

Monte


On 17 May 2019, at 5:26 am, Paul Dupuis via use-livecode 
 wrote:

Certainly there is a work around based on extensions. You and I have both 
written them for Researchware ;-) However, Jeanne used this feature extensively 
in a bunch of file i/o code she wrote for Researchware for HyperTRANSCRIBE and 
HyperRESEARCH exports to many formats, which is why/how I discovered it. Both 
HR and HT are in mid-beta on LC9 releases.

I have already written work-around code. What I am really looking for is 
CONFIRMATION this is a bug.

I have not checked LC7 yet, but it was working in LC 6.7.11 and is not working 
in 8.1.10 and 9.0.0 through 9.0.4. I am sometimes astonished that a bug like 
this can go undetected through so many releases. It causes me to worry about 
the adoption of LC as a serious commercial application building tool. However, 
ultimately, LC's many advantages outweigh an issue like the length of time this 
bug has gone undetected.

-- Paul

On 5/16/2019 1:30 PM, Richard Gaskin via use-livecode wrote:

Paul Dupuis wrote:


I just filed a serious bug for LC904 that is only under OSX. When
using 'asnwer file  with type ' the selected type is
supposed to be returned in 'the result'. This works as expected under
Windows, but under OSX using LC904 STABLE, 'the result' is the same as
the 'it', both contain the file path selected.

Please see https://quality.livecode.com/show_bug.cgi?id=22070

While it will be useful to have this fixed, the current state of macOS should 
provide a mildly-tedious-but-not-difficult workaround:

The older Finder type codes (the four-character identifiers hidden away in the 
file's metadata) are long deprecated, and for more than a decade macOS relies 
on file extensions to determine type.

Since the range of type options is limited to types you set, a few minutes 
writing a function to match the file extension with the type categories you 
provided should at least get you going while waiting for an engine fix.

In the odd case where you may encounter a very old (or misnamed) file that has no type 
extension in its name, you could extend the function to see if the old Finder type is 
included in info provided with "the detailed files".

If you were super-thorough, you might even provide another check of file contents to 
confirm type.  Image formats have magic numbers, and text formats have patterns 
identifiable within a reasonably small number of bytes.  A short read can confirm the 
type of misnamed files even beyond what can be expected with "answer file".


Psuedocode:

  getFileNameExtension(fileName)
  if absent
 getDetailedFilesInfo
 convertFourCharTypetoExtensionString
  end if
  switch fileType
 case "png"
 case "jpg"
 case "jpeg"
return "image"
break
 case "text"
 case "rtf"
return "text"
break
   end switch
   -- bonus:
   confirmTypeByReadingSomeContent


The case block for your supported types is likely still in your code base.  
Copying it to a new function and adding the earlier step of handling missing 
types by Finder code (if not already there) will make short work of this.



___
use-livecode mailing list
use-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: Seeking confirmation of a bug...

2019-05-16 Thread Monte Goulding via use-livecode
https://github.com/livecode/livecode/pull/7056 


> On 17 May 2019, at 5:43 am, Monte Goulding via use-livecode 
>  wrote:
> 
> Hi Paul
> 
> I can confirm it is broken. I’ll patch it this morning. If it has been broken 
> at some point during the refactor as the blame commit hash is a merge at that 
> time. It’s an easy fix though which is good ;-)
> 
> Cheers
> 
> Monte
> 
>> On 17 May 2019, at 5:26 am, Paul Dupuis via use-livecode 
>>  wrote:
>> 
>> Certainly there is a work around based on extensions. You and I have both 
>> written them for Researchware ;-) However, Jeanne used this feature 
>> extensively in a bunch of file i/o code she wrote for Researchware for 
>> HyperTRANSCRIBE and HyperRESEARCH exports to many formats, which is why/how 
>> I discovered it. Both HR and HT are in mid-beta on LC9 releases.
>> 
>> I have already written work-around code. What I am really looking for is 
>> CONFIRMATION this is a bug.
>> 
>> I have not checked LC7 yet, but it was working in LC 6.7.11 and is not 
>> working in 8.1.10 and 9.0.0 through 9.0.4. I am sometimes astonished that a 
>> bug like this can go undetected through so many releases. It causes me to 
>> worry about the adoption of LC as a serious commercial application building 
>> tool. However, ultimately, LC's many advantages outweigh an issue like the 
>> length of time this bug has gone undetected.
>> 
>> -- Paul
>> 
>> On 5/16/2019 1:30 PM, Richard Gaskin via use-livecode wrote:
>>> Paul Dupuis wrote:
>>> 
 I just filed a serious bug for LC904 that is only under OSX. When
 using 'asnwer file  with type ' the selected type is
 supposed to be returned in 'the result'. This works as expected under
 Windows, but under OSX using LC904 STABLE, 'the result' is the same as
 the 'it', both contain the file path selected.
 
 Please see https://quality.livecode.com/show_bug.cgi?id=22070
>>> 
>>> While it will be useful to have this fixed, the current state of macOS 
>>> should provide a mildly-tedious-but-not-difficult workaround:
>>> 
>>> The older Finder type codes (the four-character identifiers hidden away in 
>>> the file's metadata) are long deprecated, and for more than a decade macOS 
>>> relies on file extensions to determine type.
>>> 
>>> Since the range of type options is limited to types you set, a few minutes 
>>> writing a function to match the file extension with the type categories you 
>>> provided should at least get you going while waiting for an engine fix.
>>> 
>>> In the odd case where you may encounter a very old (or misnamed) file that 
>>> has no type extension in its name, you could extend the function to see if 
>>> the old Finder type is included in info provided with "the detailed files".
>>> 
>>> If you were super-thorough, you might even provide another check of file 
>>> contents to confirm type.  Image formats have magic numbers, and text 
>>> formats have patterns identifiable within a reasonably small number of 
>>> bytes.  A short read can confirm the type of misnamed files even beyond 
>>> what can be expected with "answer file".
>>> 
>>> 
>>> Psuedocode:
>>> 
>>>  getFileNameExtension(fileName)
>>>  if absent
>>> getDetailedFilesInfo
>>> convertFourCharTypetoExtensionString
>>>  end if
>>>  switch fileType
>>> case "png"
>>> case "jpg"
>>> case "jpeg"
>>>return "image"
>>>break
>>> case "text"
>>> case "rtf"
>>>return "text"
>>>break
>>>   end switch
>>>   -- bonus:
>>>   confirmTypeByReadingSomeContent
>>> 
>>> 
>>> The case block for your supported types is likely still in your code base.  
>>> Copying it to a new function and adding the earlier step of handling 
>>> missing types by Finder code (if not already there) will make short work of 
>>> this.
>>> 
>> 
>> 
>> ___
>> use-livecode mailing list
>> use-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: Seeking confirmation of a bug...

2019-05-16 Thread Monte Goulding via use-livecode
Hi Paul

I can confirm it is broken. I’ll patch it this morning. If it has been broken 
at some point during the refactor as the blame commit hash is a merge at that 
time. It’s an easy fix though which is good ;-)

Cheers

Monte

> On 17 May 2019, at 5:26 am, Paul Dupuis via use-livecode 
>  wrote:
> 
> Certainly there is a work around based on extensions. You and I have both 
> written them for Researchware ;-) However, Jeanne used this feature 
> extensively in a bunch of file i/o code she wrote for Researchware for 
> HyperTRANSCRIBE and HyperRESEARCH exports to many formats, which is why/how I 
> discovered it. Both HR and HT are in mid-beta on LC9 releases.
> 
> I have already written work-around code. What I am really looking for is 
> CONFIRMATION this is a bug.
> 
> I have not checked LC7 yet, but it was working in LC 6.7.11 and is not 
> working in 8.1.10 and 9.0.0 through 9.0.4. I am sometimes astonished that a 
> bug like this can go undetected through so many releases. It causes me to 
> worry about the adoption of LC as a serious commercial application building 
> tool. However, ultimately, LC's many advantages outweigh an issue like the 
> length of time this bug has gone undetected.
> 
> -- Paul
> 
> On 5/16/2019 1:30 PM, Richard Gaskin via use-livecode wrote:
>> Paul Dupuis wrote:
>> 
>> > I just filed a serious bug for LC904 that is only under OSX. When
>> > using 'asnwer file  with type ' the selected type is
>> > supposed to be returned in 'the result'. This works as expected under
>> > Windows, but under OSX using LC904 STABLE, 'the result' is the same as
>> > the 'it', both contain the file path selected.
>> >
>> > Please see https://quality.livecode.com/show_bug.cgi?id=22070
>> 
>> While it will be useful to have this fixed, the current state of macOS 
>> should provide a mildly-tedious-but-not-difficult workaround:
>> 
>> The older Finder type codes (the four-character identifiers hidden away in 
>> the file's metadata) are long deprecated, and for more than a decade macOS 
>> relies on file extensions to determine type.
>> 
>> Since the range of type options is limited to types you set, a few minutes 
>> writing a function to match the file extension with the type categories you 
>> provided should at least get you going while waiting for an engine fix.
>> 
>> In the odd case where you may encounter a very old (or misnamed) file that 
>> has no type extension in its name, you could extend the function to see if 
>> the old Finder type is included in info provided with "the detailed files".
>> 
>> If you were super-thorough, you might even provide another check of file 
>> contents to confirm type.  Image formats have magic numbers, and text 
>> formats have patterns identifiable within a reasonably small number of 
>> bytes.  A short read can confirm the type of misnamed files even beyond what 
>> can be expected with "answer file".
>> 
>> 
>> Psuedocode:
>> 
>>   getFileNameExtension(fileName)
>>   if absent
>>  getDetailedFilesInfo
>>  convertFourCharTypetoExtensionString
>>   end if
>>   switch fileType
>>  case "png"
>>  case "jpg"
>>  case "jpeg"
>> return "image"
>> break
>>  case "text"
>>  case "rtf"
>> return "text"
>> break
>>end switch
>>-- bonus:
>>confirmTypeByReadingSomeContent
>> 
>> 
>> The case block for your supported types is likely still in your code base.  
>> Copying it to a new function and adding the earlier step of handling missing 
>> types by Finder code (if not already there) will make short work of this.
>> 
> 
> 
> ___
> use-livecode mailing list
> use-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: Seeking confirmation of a bug...

2019-05-16 Thread Paul Dupuis via use-livecode
Certainly there is a work around based on extensions. You and I have 
both written them for Researchware ;-) However, Jeanne used this feature 
extensively in a bunch of file i/o code she wrote for Researchware for 
HyperTRANSCRIBE and HyperRESEARCH exports to many formats, which is 
why/how I discovered it. Both HR and HT are in mid-beta on LC9 releases.


I have already written work-around code. What I am really looking for is 
CONFIRMATION this is a bug.


I have not checked LC7 yet, but it was working in LC 6.7.11 and is not 
working in 8.1.10 and 9.0.0 through 9.0.4. I am sometimes astonished 
that a bug like this can go undetected through so many releases. It 
causes me to worry about the adoption of LC as a serious commercial 
application building tool. However, ultimately, LC's many advantages 
outweigh an issue like the length of time this bug has gone undetected.


-- Paul

On 5/16/2019 1:30 PM, Richard Gaskin via use-livecode wrote:

Paul Dupuis wrote:

> I just filed a serious bug for LC904 that is only under OSX. When
> using 'asnwer file  with type ' the selected type is
> supposed to be returned in 'the result'. This works as expected under
> Windows, but under OSX using LC904 STABLE, 'the result' is the same as
> the 'it', both contain the file path selected.
>
> Please see https://quality.livecode.com/show_bug.cgi?id=22070

While it will be useful to have this fixed, the current state of macOS 
should provide a mildly-tedious-but-not-difficult workaround:


The older Finder type codes (the four-character identifiers hidden 
away in the file's metadata) are long deprecated, and for more than a 
decade macOS relies on file extensions to determine type.


Since the range of type options is limited to types you set, a few 
minutes writing a function to match the file extension with the type 
categories you provided should at least get you going while waiting 
for an engine fix.


In the odd case where you may encounter a very old (or misnamed) file 
that has no type extension in its name, you could extend the function 
to see if the old Finder type is included in info provided with "the 
detailed files".


If you were super-thorough, you might even provide another check of 
file contents to confirm type.  Image formats have magic numbers, and 
text formats have patterns identifiable within a reasonably small 
number of bytes.  A short read can confirm the type of misnamed files 
even beyond what can be expected with "answer file".



Psuedocode:

  getFileNameExtension(fileName)
  if absent
 getDetailedFilesInfo
 convertFourCharTypetoExtensionString
  end if
  switch fileType
 case "png"
 case "jpg"
 case "jpeg"
    return "image"
    break
 case "text"
 case "rtf"
    return "text"
    break
   end switch
   -- bonus:
   confirmTypeByReadingSomeContent


The case block for your supported types is likely still in your code 
base.  Copying it to a new function and adding the earlier step of 
handling missing types by Finder code (if not already there) will make 
short work of this.





___
use-livecode mailing list
use-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: Innards of an APK

2019-05-16 Thread J. Landman Gay via use-livecode
Also, if the files are stored in the external documents folder, they won't 
be deleted.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On May 16, 2019 12:20:43 PM JJS via use-livecode 
 wrote:



By the way.

There is one thing i noticed before.

When the app is still installed and you go to Settings-->apps-->theapp
then clear cache or other data before removing, then stuff related
should also be gone.

I noticed once with another app. They can try it. But indeed normally
nothing should be left behind i guess with an LC app.

Although other non-lc apps do leave stuff behind sometimes.


Op 16-5-2019 om 18:40 schreef Klaus major-k via use-livecode:

Hi Jerry

Am 16.05.2019 um 18:24 schrieb JJS via use-livecode 
:


Beste Klaus,

:-)

"Beste Klaus" is dutch, german is -> Bester Klaus

Yep, german has a lot of different cases which makes it so hard to learn, 
sorry only know

the latin words for the cases:
Nominativ -> Der beste Mann -> the best man
Genitiv -> des besten Mannes -> (of) the best man
Dativ -> dem besten Mann -> the best man
Akkusativ -> den vbesten Mann -> the best man
:-D

nice that you bring this up. I am working on an app (changing a desktop 
version to mobile) that uses sqlite.
And i was under a same kind of impression, but did not check out on the 
device itself further.
(Because if i remove the app and reinsall it should come up with a question 
when a db does not exist.)

But for android i use "engine and for iphone "home"
Not sure what you mean? If you add the files via the "Copy files" tab in 
the "standalone application settings"
then they will be found in the standalone in -> 
specialfolderpath("resources"), which works on ALL platforms

and also in the IDE!

And need to be copied to -> specialfolderpath("documents") before we can 
use them, at least the database files.



Is it also sqlite that they use?

Yes.


How did they check on the device?

He wrote he used -> Total-Commander
Whatever that is, I do not own any mobile device.


There still was a folder or something left?

Sorry, he did not tell all the details.


Thanks, Jerry

Op 16-5-2019 om 12:20 schreef Klaus major-k via use-livecode:

Hi friends,

this just came up in the german LC forum.
A user wrote that de-installing an app from his Android phone did not
remove database files copied to -> specialfolderpath("documents")?

I always thought that this special folder is just a folder INSIDE of the apk
where we are allowed to write and de-installing the complete apk would
remove everything related to that app. No?

Thanks for any info!

Groetjes

Klaus

--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
use-livecode mailing list
use-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: Seeking confirmation of a bug...

2019-05-16 Thread Richard Gaskin via use-livecode

Paul Dupuis wrote:

> I just filed a serious bug for LC904 that is only under OSX. When
> using 'asnwer file  with type ' the selected type is
> supposed to be returned in 'the result'. This works as expected under
> Windows, but under OSX using LC904 STABLE, 'the result' is the same as
> the 'it', both contain the file path selected.
>
> Please see https://quality.livecode.com/show_bug.cgi?id=22070

While it will be useful to have this fixed, the current state of macOS 
should provide a mildly-tedious-but-not-difficult workaround:


The older Finder type codes (the four-character identifiers hidden away 
in the file's metadata) are long deprecated, and for more than a decade 
macOS relies on file extensions to determine type.


Since the range of type options is limited to types you set, a few 
minutes writing a function to match the file extension with the type 
categories you provided should at least get you going while waiting for 
an engine fix.


In the odd case where you may encounter a very old (or misnamed) file 
that has no type extension in its name, you could extend the function to 
see if the old Finder type is included in info provided with "the 
detailed files".


If you were super-thorough, you might even provide another check of file 
contents to confirm type.  Image formats have magic numbers, and text 
formats have patterns identifiable within a reasonably small number of 
bytes.  A short read can confirm the type of misnamed files even beyond 
what can be expected with "answer file".



Psuedocode:

  getFileNameExtension(fileName)
  if absent
 getDetailedFilesInfo
 convertFourCharTypetoExtensionString
  end if
  switch fileType
 case "png"
 case "jpg"
 case "jpeg"
return "image"
break
 case "text"
 case "rtf"
return "text"
break
   end switch
   -- bonus:
   confirmTypeByReadingSomeContent


The case block for your supported types is likely still in your code 
base.  Copying it to a new function and adding the earlier step of 
handling missing types by Finder code (if not already there) will make 
short work of this.


--
 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: Innards of an APK

2019-05-16 Thread Klaus major-k via use-livecode
Hi Jerry,

> Am 16.05.2019 um 19:19 schrieb JJS via use-livecode 
> :
> 
> By the way.
> 
> There is one thing i noticed before.
> When the app is still installed and you go to Settings-->apps-->theapp then 
> clear cache or other data before removing, then stuff related should also be 
> gone.
> I noticed once with another app. They can try it. But indeed normally nothing 
> should be left behind i guess with an LC app.
> Although other non-lc apps do leave stuff behind sometimes.

ah, thanks will pass this info over to the forum user!


Best

Klaus
--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
use-livecode mailing list
use-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: Innards of an APK

2019-05-16 Thread JJS via use-livecode

By the way.

There is one thing i noticed before.

When the app is still installed and you go to Settings-->apps-->theapp 
then clear cache or other data before removing, then stuff related 
should also be gone.


I noticed once with another app. They can try it. But indeed normally 
nothing should be left behind i guess with an LC app.


Although other non-lc apps do leave stuff behind sometimes.


Op 16-5-2019 om 18:40 schreef Klaus major-k via use-livecode:

Hi Jerry


Am 16.05.2019 um 18:24 schrieb JJS via use-livecode 
:

Beste Klaus,

:-)

"Beste Klaus" is dutch, german is -> Bester Klaus

Yep, german has a lot of different cases which makes it so hard to learn, sorry 
only know
the latin words for the cases:
Nominativ -> Der beste Mann -> the best man
Genitiv -> des besten Mannes -> (of) the best man
Dativ -> dem besten Mann -> the best man
Akkusativ -> den vbesten Mann -> the best man
:-D


nice that you bring this up. I am working on an app (changing a desktop version 
to mobile) that uses sqlite.
And i was under a same kind of impression, but did not check out on the device 
itself further.
(Because if i remove the app and reinsall it should come up with a question 
when a db does not exist.)
But for android i use "engine and for iphone "home"

Not sure what you mean? If you add the files via the "Copy files" tab in the 
"standalone application settings"
then they will be found in the standalone in -> specialfolderpath("resources"), 
which works on ALL platforms
and also in the IDE!

And need to be copied to -> specialfolderpath("documents") before we can use 
them, at least the database files.


Is it also sqlite that they use?

Yes.


How did they check on the device?

He wrote he used -> Total-Commander
Whatever that is, I do not own any mobile device.


There still was a folder or something left?

Sorry, he did not tell all the details.


Thanks, Jerry

Op 16-5-2019 om 12:20 schreef Klaus major-k via use-livecode:

Hi friends,

this just came up in the german LC forum.
A user wrote that de-installing an app from his Android phone did not
remove database files copied to -> specialfolderpath("documents")?

I always thought that this special folder is just a folder INSIDE of the apk
where we are allowed to write and de-installing the complete apk would
remove everything related to that app. No?

Thanks for any info!

Groetjes

Klaus

--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
use-livecode mailing list
use-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: Innards of an APK

2019-05-16 Thread JJS via use-livecode
Haha dass weis ich ganz genau :) i did it on purpose as you know some 
Niederlandisch.



Total commander is a File program which is also free to use on Windows, 
i use it all the time. In fact it's a program i think i use the most.


But now i have also Double Commander as it is available for Linux and 
MacOS too. It works a 1000 times better/easier/faster than any 
"st*pid/unusable/unfriendly" file program on Windows/linux/macos, 
because you see 2 drives/folder at one time, you can zip/unzip ftp with 
whatever. (Double COmmander works slightly different but Total Commander 
is not there for MacOs) Think of good old Norton Commander.


It's also for Android these days.


Ok i checked with a standard File app on the tablet i use for testing 
but i can't find any residu. Still it does not come up with the question 
i need.


I create the sqlite DB once it is installed the first time. It works ok 
in IDE, when i remove the DB.



Ciao! Jerry


Op 16-5-2019 om 18:40 schreef Klaus major-k via use-livecode:

Hi Jerry


Am 16.05.2019 um 18:24 schrieb JJS via use-livecode 
:

Beste Klaus,

:-)

"Beste Klaus" is dutch, german is -> Bester Klaus

Yep, german has a lot of different cases which makes it so hard to learn, sorry 
only know
the latin words for the cases:
Nominativ -> Der beste Mann -> the best man
Genitiv -> des besten Mannes -> (of) the best man
Dativ -> dem besten Mann -> the best man
Akkusativ -> den vbesten Mann -> the best man
:-D


nice that you bring this up. I am working on an app (changing a desktop version 
to mobile) that uses sqlite.
And i was under a same kind of impression, but did not check out on the device 
itself further.
(Because if i remove the app and reinsall it should come up with a question 
when a db does not exist.)
But for android i use "engine and for iphone "home"

Not sure what you mean? If you add the files via the "Copy files" tab in the 
"standalone application settings"
then they will be found in the standalone in -> specialfolderpath("resources"), 
which works on ALL platforms
and also in the IDE!

And need to be copied to -> specialfolderpath("documents") before we can use 
them, at least the database files.


Is it also sqlite that they use?

Yes.


How did they check on the device?

He wrote he used -> Total-Commander
Whatever that is, I do not own any mobile device.


There still was a folder or something left?

Sorry, he did not tell all the details.


Thanks, Jerry

Op 16-5-2019 om 12:20 schreef Klaus major-k via use-livecode:

Hi friends,

this just came up in the german LC forum.
A user wrote that de-installing an app from his Android phone did not
remove database files copied to -> specialfolderpath("documents")?

I always thought that this special folder is just a folder INSIDE of the apk
where we are allowed to write and de-installing the complete apk would
remove everything related to that app. No?

Thanks for any info!

Groetjes

Klaus

--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
use-livecode mailing list
use-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: Innards of an APK

2019-05-16 Thread Klaus major-k via use-livecode
Hi Jerry

> Am 16.05.2019 um 18:24 schrieb JJS via use-livecode 
> :
> 
> Beste Klaus,

:-)

"Beste Klaus" is dutch, german is -> Bester Klaus

Yep, german has a lot of different cases which makes it so hard to learn, sorry 
only know 
the latin words for the cases:
Nominativ -> Der beste Mann -> the best man
Genitiv -> des besten Mannes -> (of) the best man
Dativ -> dem besten Mann -> the best man
Akkusativ -> den vbesten Mann -> the best man
:-D

> nice that you bring this up. I am working on an app (changing a desktop 
> version to mobile) that uses sqlite.
> And i was under a same kind of impression, but did not check out on the 
> device itself further.
> (Because if i remove the app and reinsall it should come up with a question 
> when a db does not exist.)
> But for android i use "engine and for iphone "home"

Not sure what you mean? If you add the files via the "Copy files" tab in the 
"standalone application settings" 
then they will be found in the standalone in -> specialfolderpath("resources"), 
which works on ALL platforms
and also in the IDE!

And need to be copied to -> specialfolderpath("documents") before we can use 
them, at least the database files.

> Is it also sqlite that they use?

Yes.

> How did they check on the device?

He wrote he used -> Total-Commander
Whatever that is, I do not own any mobile device.

> There still was a folder or something left?

Sorry, he did not tell all the details.

> Thanks, Jerry
> 
> Op 16-5-2019 om 12:20 schreef Klaus major-k via use-livecode:
>> Hi friends,
>> 
>> this just came up in the german LC forum.
>> A user wrote that de-installing an app from his Android phone did not
>> remove database files copied to -> specialfolderpath("documents")?
>> 
>> I always thought that this special folder is just a folder INSIDE of the apk
>> where we are allowed to write and de-installing the complete apk would
>> remove everything related to that app. No?
>> 
>> Thanks for any info!

Groetjes

Klaus

--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
use-livecode mailing list
use-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: Innards of an APK

2019-05-16 Thread JJS via use-livecode

Beste Klaus,


nice that you bring this up. I am working on an app (changing a desktop 
version to mobile) that uses sqlite.


And i was under a same kind of impression, but did not check out on the 
device itself further.


(Because if i remove the app and reinsall it should come up with a 
question when a db does not exist.)


But for android i use "engine and for iphone "home"

Is it also sqlite that they use?

How did they check on the device? There still was a folder or something 
left?


Thanks, Jerry


Op 16-5-2019 om 12:20 schreef Klaus major-k via use-livecode:

Hi friends,

this just came up in the german LC forum.
A user wrote that de-installing an app from his Android phone did not
remove database files copied to -> specialfolderpath("documents")?

I always thought that this special folder is just a folder INSIDE of the apk
where we are allowed to write and de-installing the complete apk would
remove everything related to that app. No?

Thanks for any info!


Best

Klaus
--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
use-livecode mailing list
use-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: play sounds in HTML5

2019-05-16 Thread hh via use-livecode
> Thanks Sean.
> I will have to work hard because I am not familiar with Dynamic HTML.

One simple way to do that:

Write, a little bit more as Sean wrote, in your html file:


Then first set in LC newsound, may be randomly:

put "/audio/guitar-melody.wav" into newsound

Then issue from LC:

do "document.getElementById('audio1').src='" & newsound & "'" in widget 
"browser"

That's all, nothing complicated.
___
use-livecode mailing list
use-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: Seeking confirmation of a bug...

2019-05-16 Thread Klaus major-k via use-livecode
Hi Paul,

> Am 16.05.2019 um 16:35 schrieb Paul Dupuis via use-livecode 
> :
> 
> On 5/16/2019 10:26 AM, Klaus major-k via use-livecode wrote:
>> answer file "sdsdds" with type "PNG, JPEG|png,jpg|"
> 
> You only  tested with 1 type. Download the test stack from the bug report or 
> try
> answer file "sdsdds" with type ("PNG Files|png"&"JPEG Files|jpg")
> to actually have more than one "type" specified - it goes by type tags not 
> the extensions listed

since FILETYPES will be meaningless in the current and future versions of 
macOS, I never tried this syntax. :-)

My first script 
...
answer file "sdsdds" with type "PNG, JPEG|png,jpg|"
...
actually ONLY shows PNG and JPEG files in the dialog as exspected!

Your script:
...
answer file "sdsdds" with type ("PNG Files|png"&"JPEG Files|jpg")
...
DOES in fact show the dropdown but lets me select ANY file in the dialog,
no matter what I select in that drop-down list.

Hint:
The correct old-style real Mac FILETYPE would be JPEG and PNGƒ in this case.

I tried different combinations, didn't work either.
Finally this one "kinda" works, but will return the filename in IT AND the 
result:
...
answer file "sdsdds" with type ("PNG,Jpeg" & "|png" & CR & "jpg|")
...
See, I left out the actual FILETYPE parameter, as it it meaningless in current 
macOS versions.
They are leftovers from MascOS <= 9

Looks like the CR in the "extensions" parameter forces the list to appear, 
although I did not 
get it to work correctly.


Best

Klaus
--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
use-livecode mailing list
use-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: Seeking confirmation of a bug...

2019-05-16 Thread Paul Dupuis via use-livecode

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

maybe the dictionary should read: "This list is ONLY displayed on Windows 
systems"?


No it is displayed under OSX IF you specify more than one type (tag) not 
extensions. See my previous reply. Also this fails under LC903 but works 
as expected under LC6.7.11, so this is most definitely a regression bug


(I do not have LC 7 through 9 installed to test)

___
use-livecode mailing list
use-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: Seeking confirmation of a bug...

2019-05-16 Thread Paul Dupuis via use-livecode

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

answer file "sdsdds" with type "PNG, JPEG|png,jpg|"


You only  tested with 1 type. Download the test stack from the bug 
report or try


answer file "sdsdds" with type ("PNG Files|png"&"JPEG Files|jpg")

to actually have more than one "type" specified - it goes by type tags 
not the extensions listed



___
use-livecode mailing list
use-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: Seeking confirmation of a bug...

2019-05-16 Thread Klaus major-k via use-livecode
...
> From the dictionary about "anser file ... with type..."
> ...
> If more than one type is specified, a drop-down list containing the tags will 
> be displayed allowing the user to select which types of files to display. 
> (This list is always displayed on Windows systems).

maybe the dictionary should read: "This list is ONLY displayed on Windows 
systems"?

--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
use-livecode mailing list
use-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: Seeking confirmation of a bug...

2019-05-16 Thread Klaus major-k via use-livecode
Hi Paul,

> Am 16.05.2019 um 16:10 schrieb Paul Dupuis via use-livecode 
> :
> 
> I just filed a serious bug for LC904 that is only under OSX. When using 
> 'asnwer file  with type ' the selected type is supposed to 
> be returned in 'the result'. This works as expected under Windows, but under 
> OSX using LC904 STABLE, 'the result' is the same as the 'it', both contain 
> the file path selected.
> 
> Please see https://quality.livecode.com/show_bug.cgi?id=22070
> If someone running LC904 STABLE under OSX could confirm this? I tested under 
> El Capatan.

tested on macOS 10.14.5 with LC 9.04:

on mouseUp
  answer file "sdsdds" with type "PNG, JPEG|png,jpg|"
  put it & CR & the result
end mouseUp

IT = the filename, but the result = EMPTY!

However I am not sure this is really a bug!?
>From the dictionary about "anser file ... with type..."
...
If more than one type is specified, a drop-down list containing the tags will 
be displayed allowing the user to select which types of files to display. (This 
list is always displayed on Windows systems).
...
This mentioned drop-down list does not appear on macOS!
I never saw it on macOS, only on Windows. 

> Thank you in advance.

Best

Klaus

--
Klaus Major
http://www.major-k.de
kl...@major-k.de


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


Seeking confirmation of a bug...

2019-05-16 Thread Paul Dupuis via use-livecode
I just filed a serious bug for LC904 that is only under OSX. When using 
'asnwer file  with type ' the selected type is 
supposed to be returned in 'the result'. This works as expected under 
Windows, but under OSX using LC904 STABLE, 'the result' is the same as 
the 'it', both contain the file path selected.


Please see https://quality.livecode.com/show_bug.cgi?id=22070

If someone running LC904 STABLE under OSX could confirm this? I tested 
under El Capatan.


Thank you in advance.

___
use-livecode mailing list
use-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: array and revExecuteSQL

2019-05-16 Thread axwald via use-livecode
Hi.

Paul Dupuis via use-livecode wrote
> I believe you need to surround the placeholder with single quotes.

Doesn't work, my LC doesn't do the replacement:
> UPDATE `t_test` SET `Text` = ':11' WHERE `Nummer` = ':22';
and
> UPDATE `t_test` SET `Text` = :'11' WHERE `Nummer` = :'22';
are sent to the db w/o changes.

Interesting:
> put "cText" into myArr[8]
> put "99" into myArr[9]
> put "UPDATE `t_test` SET `Text` = :8 WHERE `Nummer` = :9;" into StrSQL 
doesn't replace, whereas:
> put "cText" into myArr[8]
> put "99" into myArr[9]
> put "UPDATE `t_test` SET `Text` = :1 WHERE `Nummer` = :2;" into StrSQL 
does - according to the order of the numbers ;-)
So the placeholders in the SQL string MUST BE :1 to :9, and MUST BE used in
ascending order. :0 isn't recognized.


Paul Dupuis via use-livecode wrote
> Also you can lose the semicolon as LC will only execute one statement at a
> time. You cannot string statements. 

Well, it doesn't hurt either, and I'm so used to it :)

Have fun!



-
• Livecode programming until the cat hits the fan •
--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
use-livecode mailing list
use-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: play sounds in HTML5

2019-05-16 Thread Alain Vezina via use-livecode
Thanks a  lot Sean,

I think you have the right solution.
I will have to work hard because I am not familiar with Dynamic HTML.
A few trials and errors should solve the problem.

Thanks again

Alain


> Le 15 mai 2019 à 20:56, Pi Digital via use-livecode 
>  a écrit :
> 
> Hi again Alain
> 
> What you are talking about I think is known as a form of Dynamic HTML. 
> Basically you use LiveCode to build your list of audio files (put the files 
> into tFileList) and choose one (random or picked by the user via a 
> mobilePick...) then replace out the source file pointer ( the html file. 
> 
> Because you will not be able to write over the original html file included 
> with your app package you will want to duplicate the contents of the html 
> folder into the (specialFolderPath) “Documents” folder. If you are 
> downloading additional audio have these stored directly into 
> Documents/html/audio/. 
> 
> Once you’ve changed the html file you can either refresh the page or set the 
> htmltext of the browser to the contents of the updated html file (which is 
> the best option. 
> 
> Sean Cole
> Pi Digital Prod Ltd
> 
>> On 15 May 2019, at 21:44, Alain Vezina via use-livecode 
>>  wrote:
>> 
>> Thanks Sean,
>> 
>> You did not misunderstand my request.
>> 
>> You make me go one step forward : now I can call a sound to be played from a 
>> folder where there are several other sound.
>> 
>> Now, how can I played a sound chosen by random your chosen by the user; in 
>> other words, how can I replace "piano-melody.wav" by the name of the chosen 
>> sound, never knowing wich sound will be chosen by the user or by a random 
>> procedure ? How my program can write in an HTML file, considering there is a 
>> list of all the soud files including the extention .WAV or .MP3 or another 
>> one?
>> 
>> Regards
>> 
>> Alain
>> 
>> 
>>> Le 14 mai 2019 à 17:02, Pi Digital via use-livecode 
>>>  a écrit :
>>> 
>>> Hi Alain
>>> 
>>> The key here is in the line
>>> 
>>> 
>>> 
>>> Instead of just piano-melody.wav you would put in the whole path or 
>>> relative path to the file. Example, if your file structure has a folder 
>>> called ‘html’ containing your html file and then another folder called 
>>> ‘audio’ which contains all your audio files including one called 
>>> piano-melody.wav then the code would read
>>> 
>>> 
>>> 
>>> This points to the file in a relative path to the html file itself. 
>>> 
>>> Does this help or have I misunderstood your request?
>>> 
>>> Regards
>>> 
>>> Sean Cole
>>> Pi Digital Prod Ltd
>>> 
 On 14 May 2019, at 20:52, Alain Vezina via use-livecode 
  wrote:
 
 Hi all,
 
 Is there somebody who knows how to play one sound after another using the 
 path of each sound.
 
 I read the lesson [ How do I play sound files in HTML5? ] where I have to 
 type the name the sound in the HTML file and to put the sound file into 
 the standalone folder.
 
 You know, I want to use one of my sounds libraries as I did into a 
 standalone for Mac, PC , IOS or Android : you specify once the path of the 
 library and the name of the sound you want to be played. The sounds 
 library is not in the app and every sound has his proper name. So I can 
 play a sound chosen by random  or chosen by the user.
 
 Alain Vezina
 Logilangue
 www.logilangue.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
> ___
> use-livecode mailing list
> use-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

[ANN] Release 9.0.5 RC-1

2019-05-16 Thread panagiotis merakos via use-livecode
Dear list members,

We are pleased to announce the release of LiveCode 9.0.5 RC-1.


Getting the Release
===
You can get the release at https://downloads.livecode.com/livecode/ or via
the automatic updater.


Release Contents

LiveCode 9.0.5 RC-1 comes with more than 60 bugfixes, including fixes to
several memory leaks that had been around for a long time. Moreover, dozens
of Dictionary entries have been corrected and enhanced.


Known issues

- The Browser widget's native layer is not shown in some Linux distros with
Cinnamon window manager.
- The use of the Browser widget is not supported on Ubuntu 18.04 64 bit LTS
yet.

The full release notes are available from:

http://downloads.livecode.com/livecode/9_0_5/LiveCodeNotes-9_0_5_rc_1.pdf


Feedback

Please report any bugs encountered on our BugZilla at
http://quality.livecode.com/

We have a forum available for discussing LiveCode Builder at
http://forums.livecode.com/viewforum.php?f=93


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


Innards of an APK

2019-05-16 Thread Klaus major-k via use-livecode
Hi friends,

this just came up in the german LC forum.
A user wrote that de-installing an app from his Android phone did not 
remove database files copied to -> specialfolderpath("documents")?

I always thought that this special folder is just a folder INSIDE of the apk
where we are allowed to write and de-installing the complete apk would 
remove everything related to that app. No?

Thanks for any info!


Best

Klaus
--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
use-livecode mailing list
use-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 - Open file dialog?

2019-05-16 Thread scott--- via use-livecode
> Ludovic THEBAULT via use-livecode  wrote:
> Yes it’s work, but if the filename is not short, only the beginning of the 
> filename is displayed with MobilePick (on iPhone, perhaps not on ipad). 


I have been bothered by this also. Is this a bug with LiveCode and has it been 
reported?  (I looked but couldn’t find a bug report)

— Scott Morrow


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