Re: The Overflow

[Tom Glod via use-livecode]

thanks for these mark...they will be an interesting read.

On Wed, Oct 30, 2019 at 12:56 PM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Pure heresy! I CAN write perfect code first time every time! I just have
> to try harder!! ;-)
>
> Bob S
>
>
> > On Oct 30, 2019, at 09:22 , Mark Wieder via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > My Most Embarrassing Mistakes as a Programmer (so far)
> >
> https://stackoverflow.blog/2019/10/29/my-most-embarrassing-mistakes-as-a-programmer-so-far/
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>


-- 
Tom Glod
Founder & Developer
MakeShyft R.D.A (www.makeshyft.com)
Office:226-706-9339
Mobile:226-706-9793
___
use-livecode mailing list
use-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: "empty" background in printed pdf is actually grey

[doc hawk via use-livecode]

On Oct 31, 2019, at 5:42 PM, J. Landman Gay via use-livecode 
 wrote:
> 
> A light gray is the system default on OS X windows. You might have better 
> luck setting the stack background to opaque and white. But take that with a 
> grain of salt, I've never done what you're attempting.


But if the background is opaque, it will block the text underneath it for the 
form I’m filling.

I *may* have to go to not even generating a LiveCode pdf, but instead PyPDF2 
commands to place text . . .  [yuckier and yuckier . . .]
 
___
use-livecode mailing list
use-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: "empty" background in printed pdf is actually grey

[J. Landman Gay via use-livecode]

A light gray is the system default on OS X windows. You might have better 
luck setting the stack background to opaque and white. But take that with a 
grain of salt, I've never done what you're attempting.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On October 31, 2019 7:25:37 PM "Dr. Hawkins via use-livecode" 
 wrote:


On Oct 30, 2019, at 10:39 PM, Tom Glod via use-livecode 
 wrote:



Don't things inherit attributes?. so if empty, that means the card
would inherit the stacks background color??



The card and the stack also are set to empty backgroundcolor

I’ve also set the opaque of stack, card, and group to false.

I’ve even checked the effective opaque of the selectedObject,  which is 
false for the group I print it’s pieces.


Yet I get a grey overlay when the pdf is merged into another pdf.



—
Richard E. Hawkins, Esq.
The Hawkins Law Firm
3430 E. Flamingo Rd.
Suite 232
Las Vegas, NV  89121
(702) 508-8462

___
use-livecode mailing list
use-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: "empty" background in printed pdf is actually grey

[Dr. Hawkins via use-livecode]

On Oct 30, 2019, at 10:39 PM, Tom Glod via use-livecode 
 wrote:

> Don't things inherit attributes?. so if empty, that means the card
> would inherit the stacks background color??


The card and the stack also are set to empty backgroundcolor

I’ve also set the opaque of stack, card, and group to false.

I’ve even checked the effective opaque of the selectedObject,  which is false 
for the group I print it’s pieces.

Yet I get a grey overlay when the pdf is merged into another pdf.



— 
Richard E. Hawkins, Esq.
The Hawkins Law Firm
3430 E. Flamingo Rd.
Suite 232
Las Vegas, NV  89121
(702) 508-8462

___
use-livecode mailing list
use-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: cr, lf, and reading in terminals/vim

[Richard Gaskin via use-livecode]

Brian Milby wrote:

> https://github.com/livecode/livecode/pull/7214
>
> We'll see where it goes this time...

Thank you, Brian.  This is a good step forward for the usability of the 
language.


--
 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: cr, lf, and reading in terminals/vim

[Brian Milby via use-livecode]

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

We'll see where it goes this time...

On Thu, Oct 31, 2019 at 12:27 PM Brian Milby  wrote:

> I’ll submit a PR tonight.
>
> Thanks,
> Brian
> On Oct 31, 2019, 12:26 PM -0400, Richard Gaskin via use-livecode <
> use-livecode@lists.runrev.com>, wrote:
>
> Ben Rubinstein wrote:
>
> Brian Milby wrote:
>
> My suggestion is to just bite the bullet and build LC where 'file'
> exports using LF on Mac
>
>
> Oh please yes!
>
>
> Seconded.
>
> Containing the scope of the remedy to text writes should affect very
> few, and those affected will probably welcome the change.
>
> What needs to be done to move this forward?
>
>
> Bob Sneidar wrote:
>
> Upon examining the ascii value of every line terminator I discovered
> something, perhaps the OS or the software itself, converted the
> terminators to something else. I also find this practice to be not
> just confusing, but reprehensible.
>
>
> LC supports two write modes: text and binary. Perhaps the editor you'd
> used supports the equivalent of LC's text mode, where the data is indeed
> altered to provide greater convenience for cross-platform line-endings,
> replacing NULLs with spaces, etc. This is consistent with how HyperTalk
> established writes, and I've seen some text editor packages do similar
> things.
>
> When you need to preserve data as-is, use binary mode.
>
> Thankfully LC provides both. HyperCard provided only text mode, and
> SuperCard only binary mode. I like being able to use each depending on
> what I'm doing.
>
> --
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.com http://www.FourthWorld.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: generating a standalone in v9.x

[Bob Sneidar via use-livecode]

Whoops! I forgot one important thing:

global gBuildingStandalone

Bob S


> On Oct 31, 2019, at 15:12 , Bob Sneidar via use-livecode 
>  wrote:
> 
> Here's what I do. In the stackScript of the mainStack:
> 
> on savingStandalone
>   put true into gBuildingStandAlone
> end savingStandalone


___
use-livecode mailing list
use-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: generating a standalone in v9.x

[Bob Sneidar via use-livecode]

There is a set of commands that in certain scripts like opesStack and 
closeStack that will check to see if the standalone builder is running, and 
then you can abort the handler. 

The reason they do this is because your app could be doing anything at the 
moment the standalone is being built. The standalone has to walk through every 
script to check what add-ons or libraries you use so it can include them. 

Here's what I do. In the stackScript of the mainStack:

on savingStandalone
   put true into gBuildingStandAlone
end savingStandalone

on standaloneSaved
   put false into gBuildingStandAlone
end standaloneSaved

Then in any openStack handler, either in the stack or card, I put this:

   put the environment is "development" and \
 there is a stack "revStandaloneProgress" and \
 the mode of stack "revStandaloneProgress" > 0 into skipLogin
   
   if not skipLogin then
   --- code that borks your standalone building. For me it was calling a login 
dialog as modal. 
   end if

Bob S


> On Oct 31, 2019, at 14:50 , Douglas Ruisaard via use-livecode 
>  wrote:
> 
> I am having an issue with using "any" business version of 9 (9.04, 9.05, 
> 9.5-32bit, 9.5-64bit) to generate a standalone output of my application.  I 
> am using Windows 7 Enterprise SP1 and have tried building the identical 
> script (with the same result) on two different installations of said OS on 
> two different machines.
> 
> LC business v 8.1.10 generates the standalone fine.
> 
> LC business version 9.0.5 (with IDENTICAL settings in the "Standalone 
> Application Settings" as used in the v8.1.10 build) seems to crash LC  just 
> at the point of "closing open stacks" at which point all things LC disappear 
> from my desktop.  An appropriate "destination" directory for the standalone 
> is created as per the settings but it is completely empty.
> 
> The actual application runs fine in all LC business versions... it's just 
> that I can't get the LC v9.x to generated the standalone... and ... I can't 
> find ANY error or log explaining what is wrong!!
> 
> Is there such a log or audit which details the steps that LC is taking and 
> possibly what the issue is that it cannot resolve?  I have checked at the 
> Administrators tools event logging provided by Windows 7 ... but there is no 
> corresponding event which is simultaneous with the LC "crash".
> 
> I follow this user-group quite closely and seem to recall others having 
> issues with LC v9's standalone processes but I cannot seem to find such 
> references within the very large amount of chat this site contains.  I have 
> NOT checked the LC QC bugs since I really don't know what I'm looking for 
> other than potential issues with the standalone builder.
> 
> I'd very much appreciate any tips, pointers, explanations as to how to either 
> resolve this issue or where within my LC environment I can find any logs 
> concerning the standalone processing.
> 
> Cheers!
> Douglas Ruisaard
> Trilogy Software
> (250) 573-3935


___
use-livecode mailing list
use-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: generating a standalone in v9.x

[Brian Milby via use-livecode]

There is a breaking change in 9 where lock messages is no longer issued when 
closing and opening the stacks as a part of the build process.  There is some 
suggested code around.  It revolves around testing for being in the build 
process for the  (pre)openXxx messages.  That May be the issue you are running 
into.

Thanks,
Brian
On Oct 31, 2019, 5:51 PM -0400, Douglas Ruisaard via use-livecode 
, wrote:
> I am having an issue with using "any" business version of 9 (9.04, 9.05, 
> 9.5-32bit, 9.5-64bit) to generate a standalone output of my application. I am 
> using Windows 7 Enterprise SP1 and have tried building the identical script 
> (with the same result) on two different installations of said OS on two 
> different machines.
>
> LC business v 8.1.10 generates the standalone fine.
>
> LC business version 9.0.5 (with IDENTICAL settings in the "Standalone 
> Application Settings" as used in the v8.1.10 build) seems to crash LC just at 
> the point of "closing open stacks" at which point all things LC disappear 
> from my desktop. An appropriate "destination" directory for the standalone is 
> created as per the settings but it is completely empty.
>
> The actual application runs fine in all LC business versions... it's just 
> that I can't get the LC v9.x to generated the standalone... and ... I can't 
> find ANY error or log explaining what is wrong!!
>
> Is there such a log or audit which details the steps that LC is taking and 
> possibly what the issue is that it cannot resolve? I have checked at the 
> Administrators tools event logging provided by Windows 7 ... but there is no 
> corresponding event which is simultaneous with the LC "crash".
>
> I follow this user-group quite closely and seem to recall others having 
> issues with LC v9's standalone processes but I cannot seem to find such 
> references within the very large amount of chat this site contains. I have 
> NOT checked the LC QC bugs since I really don't know what I'm looking for 
> other than potential issues with the standalone builder.
>
> I'd very much appreciate any tips, pointers, explanations as to how to either 
> resolve this issue or where within my LC environment I can find any logs 
> concerning the standalone processing.
>
> Cheers!
> Douglas Ruisaard
> Trilogy Software
> (250) 573-3935
>
>
>
>
> ___
> use-livecode mailing list
> use-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

generating a standalone in v9.x

[Douglas Ruisaard via use-livecode]

I am having an issue with using "any" business version of 9 (9.04, 9.05, 
9.5-32bit, 9.5-64bit) to generate a standalone output of my application.  I am 
using Windows 7 Enterprise SP1 and have tried building the identical script 
(with the same result) on two different installations of said OS on two 
different machines.

LC business v 8.1.10 generates the standalone fine.

LC business version 9.0.5 (with IDENTICAL settings in the "Standalone 
Application Settings" as used in the v8.1.10 build) seems to crash LC  just at 
the point of "closing open stacks" at which point all things LC disappear from 
my desktop.  An appropriate "destination" directory for the standalone is 
created as per the settings but it is completely empty.

The actual application runs fine in all LC business versions... it's just that 
I can't get the LC v9.x to generated the standalone... and ... I can't find ANY 
error or log explaining what is wrong!!

Is there such a log or audit which details the steps that LC is taking and 
possibly what the issue is that it cannot resolve?  I have checked at the 
Administrators tools event logging provided by Windows 7 ... but there is no 
corresponding event which is simultaneous with the LC "crash".

I follow this user-group quite closely and seem to recall others having issues 
with LC v9's standalone processes but I cannot seem to find such references 
within the very large amount of chat this site contains.  I have NOT checked 
the LC QC bugs since I really don't know what I'm looking for other than 
potential issues with the standalone builder.

I'd very much appreciate any tips, pointers, explanations as to how to either 
resolve this issue or where within my LC environment I can find any logs 
concerning the standalone processing.

Cheers!
Douglas Ruisaard
Trilogy Software
(250) 573-3935




___
use-livecode mailing list
use-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: Fun with the templateimage

[Klaus major-k via use-livecode]

Hi Bob,

> Am 31.10.2019 um 20:03 schrieb Bob Sneidar via use-livecode 
> :
> 
> OK New version with error checking, and also addresses the issue where Klaus 
> could not compile:
> 
> on exportScaledImage pSourceFile, pDestFile, pScaleFactor, pFormat
>   -- Validate parameters
>   -- pSourceFile
>   if not there is a file pSourceFile then \
> answer error "Source file does not exist!" as sheet ; exit 
> exportScaledImage 
>   set the itemDelimiter to "/"
> 
>   -- pDestFile
>   if not there is a folder (item 1 to -2 of pDestFile) then \
> answer error "Destination folder does not exist!" as sheet ; exit 
> exportScaledImage
> 
>   -- pScaleFactor
>   if not (pScaleFactor is a number) or not(pScaleFactor <1) then \
> answer error "Scale factor must be a percentage > 0!" as sheet ; exit 
> exportScaledImage
> 
>   -- pFormat
>   if not (pFormat is among the items of "JPEG/BMP/PNG") then \
> answer error "Valid formats are: JPEG, BMP or PNG." as sheet ; exit 
> exportScaledImage
> 
>   -- set the source file as the template image and get dimensions
>   set the filename of the templateimage to pSourceFile
>   put the formattedwidth of the templateimage into tFW
>   put the formattedheight of the templateimage into tFH
> 
>   -- scale the image to a round value
>   set the width of the templateimage to round(tFW * (pScaleFactor /100))
>   set the height of the templateimage to round(tFH * (pScaleFactor /100))

## Just tested with DO, this does work WITHOUT switch 8-)
put "export the templateimage to file " & quote & pDestFile & quote & " as" && 
pFormat into tCommand

>   do tCommand
>   -- reset
>   reset the templateimage
> end exportScaledImage

Best

Klaus

--
Klaus Major
https://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: Fun with the templateimage

[Bob Sneidar via use-livecode]

OK New version with error checking, and also addresses the issue where Klaus 
could not compile:

on exportScaledImage pSourceFile, pDestFile, pScaleFactor, pFormat
   -- Validate parameters
   -- pSourceFile
   if not there is a file pSourceFile then \
 answer error "Source file does not exist!" as sheet ; exit 
exportScaledImage 
   set the itemDelimiter to "/"
   
   -- pDestFile
   if not there is a folder (item 1 to -2 of pDestFile) then \
 answer error "Destination folder does not exist!" as sheet ; exit 
exportScaledImage
   
   -- pScaleFactor
   if not (pScaleFactor is a number) or not(pScaleFactor <1) then \
 answer error "Scale factor must be a percentage > 0!" as sheet ; exit 
exportScaledImage
   
   -- pFormat
   if not (pFormat is among the items of "JPEG/BMP/PNG") then \
 answer error "Valid formats are: JPEG, BMP or PNG." as sheet ; exit 
exportScaledImage
   
   -- set the source file as the template image and get dimensions
   set the filename of the templateimage to pSourceFile
   put the formattedwidth of the templateimage into tFW
   put the formattedheight of the templateimage into tFH
   
   -- scale the image to a round value
   set the width of the templateimage to round(tFW * (pScaleFactor /100))
   set the height of the templateimage to round(tFH * (pScaleFactor /100))
   
   -- convert file
   switch pFormat
  case "JPEG"
 put "export the templateimage to file " & quote & pDestFile & quote & 
" as JPEG" into tCommand
 break
  case "BMP"
 put "export the templateimage to file " & quote & pDestFile & quote & 
" as BMP" into tCommand
 break
  case "PNG"
 export the templateimage to file (pDestFile) as PNG
 put "export the templateimage to file " & quote & pDestFile & quote & 
" as PNG" into tCommand
 break
   end switch
   
   do tCommand
   
   -- reset
   reset the templateimage
end exportScaledImage

> On Oct 31, 2019, at 08:00 , Bob Sneidar  wrote:
> 
> Or better yet: -- No error checking, assumes parameters are correct. Also not 
> tested. :-)
> 
> on exportScaledImage pSourceFile, pDestFile, pScaleFactor, pFormat
>   ## My good ol' banana, older users of MC might remember that one :-D
>   set the filename of the templateimage to pSourceFile
> 
>   ## This was a know (to me) feature
>   put the formattedwidth of the templateimage into tFW
>   put the formattedheight of the templateimage into tFH
>   ## Now you can apply some "rule of three" to scale the image while 
> preserving its ratio
>   ## I'll leave that up to you... :-)
> 
>   ## I cheated a bit:
>   set the width of the templateimage to round(tFW * (pScaleFactor /100))
>   set the height of the templateimage to round(tFH * (pScaleFactor /100))
> 
>   ## But this one really suprised me:
>   switch pFormat
>  case "JPEG"
> export the templateimage to file (pDestFile) as JPEG
> break
>  case "BMP"
> export the templateimage to file (pDestFile) as BMP
> break
>  case "PNG"
> export the templateimage to file (pDestFile) as PNG
> break
>   end switch
> 
>   reset the templateimage
> end exportScaledImage
> 
> 
>> On Oct 30, 2019, at 13:13 , Klaus major-k via use-livecode 
>>  wrote:
>> 
>> Hi all,
>> 
>> we know that "the templatexx" is a very helpful thingie.
>> 
>> But I was really surprised that we can even EXPORT something
>> from the templateimage until I tried 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: Fun with the templateimage

[Bob Sneidar via use-livecode]

I should put a disclaimer in the comments of any code I write:

Note: The Author is not responsible for the loss of functionality or any 
consequences derived from to the alteration of any segment of this code. 

:-)
Bob S


> On Oct 31, 2019, at 10:37 , Bob Sneidar  wrote:
> 
> You removed the parenthesis. PUT 'EM BACK!  LOL! 
> 
> Bob S
> 
> 
>> On Oct 31, 2019, at 10:34 , Klaus major-k via use-livecode 
>>  wrote:
>> 
>> Hi all,
>> 
>>> On Oct 31, 2019, at 10:01 , Klaus major-k via use-livecode 
>>>  wrote:
 
 Hi Bob,
 
> Am 31.10.2019 um 16:00 schrieb Bob Sneidar via use-livecode 
> :
> 
> Or better yet: -- No error checking, assumes parameters are correct. Also 
> not tested. :-)
> 
> on exportScaledImage pSourceFile, pDestFile, pScaleFactor, pFormat
> ...
> switch pFormat
>  case "JPEG"
> export the templateimage to file (pDestFile) as JPEG
> break
>  case "BMP"
> export the templateimage to file (pDestFile) as BMP
> break
>  case "PNG"
> export the templateimage to file (pDestFile) as PNG
> break
> end switch
> ...
 
 too bad LC does not like a variable for the target format:
 ...
 export the templateimage to file pDestFile as pFormat
 ...
 -> Compile error
>> 
>> i filed an enhancement request:
>> 
>> 
>> 
>> Best
>> 
>> Klaus
>> --
>> Klaus Major
>> https://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: Fun with the templateimage

[Bob Sneidar via use-livecode]

You removed the parenthesis. PUT 'EM BACK!  LOL! 

Bob S


> On Oct 31, 2019, at 10:34 , Klaus major-k via use-livecode 
>  wrote:
> 
> Hi all,
> 
>> On Oct 31, 2019, at 10:01 , Klaus major-k via use-livecode 
>>  wrote:
>>> 
>>> Hi Bob,
>>> 
 Am 31.10.2019 um 16:00 schrieb Bob Sneidar via use-livecode 
 :
 
 Or better yet: -- No error checking, assumes parameters are correct. Also 
 not tested. :-)
 
 on exportScaledImage pSourceFile, pDestFile, pScaleFactor, pFormat
 ...
 switch pFormat
   case "JPEG"
  export the templateimage to file (pDestFile) as JPEG
  break
   case "BMP"
  export the templateimage to file (pDestFile) as BMP
  break
   case "PNG"
  export the templateimage to file (pDestFile) as PNG
  break
 end switch
 ...
>>> 
>>> too bad LC does not like a variable for the target format:
>>> ...
>>> export the templateimage to file pDestFile as pFormat
>>> ...
>>> -> Compile error
> 
> i filed an enhancement request:
> 
> 
> 
> Best
> 
> Klaus
> --
> Klaus Major
> https://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: Fun with the templateimage

[Klaus major-k via use-livecode]

Hi all,

> On Oct 31, 2019, at 10:01 , Klaus major-k via use-livecode 
>  wrote:
>> 
>> Hi Bob,
>> 
>>> Am 31.10.2019 um 16:00 schrieb Bob Sneidar via use-livecode 
>>> :
>>> 
>>> Or better yet: -- No error checking, assumes parameters are correct. Also 
>>> not tested. :-)
>>> 
>>> on exportScaledImage pSourceFile, pDestFile, pScaleFactor, pFormat
>>> ...
>>> switch pFormat
>>>case "JPEG"
>>>   export the templateimage to file (pDestFile) as JPEG
>>>   break
>>>case "BMP"
>>>   export the templateimage to file (pDestFile) as BMP
>>>   break
>>>case "PNG"
>>>   export the templateimage to file (pDestFile) as PNG
>>>   break
>>> end switch
>>> ...
>> 
>> too bad LC does not like a variable for the target format:
>> ...
>> export the templateimage to file pDestFile as pFormat
>> ...
>> -> Compile error

i filed an enhancement request:



Best

Klaus
--
Klaus Major
https://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: Fun with the templateimage

[Klaus major-k via use-livecode]

> Am 31.10.2019 um 18:22 schrieb Bob Sneidar via use-livecode 
> :
> 
> BTW do you use strict variables?

NEVER! :-)

> Bob S
> 
>> On Oct 31, 2019, at 10:20 , Bob Sneidar via use-livecode 
>>  wrote:
>> 
>> Me too. I just tested it and got a 50% scaled image as a JPEG file. Let me 
>> try sending it to you again private email. 
>> 
>> Bob S
--
Klaus Major
https://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: Fun with the templateimage

[Bob Sneidar via use-livecode]

BTW do you use strict variables?

Bob S


> On Oct 31, 2019, at 10:20 , Bob Sneidar via use-livecode 
>  wrote:
> 
> Me too. I just tested it and got a 50% scaled image as a JPEG file. Let me 
> try sending it to you again private email. 
> 
> Bob S


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

Re: Fun with the templateimage

[Bob Sneidar via use-livecode]

Me too. I just tested it and got a 50% scaled image as a JPEG file. Let me try 
sending it to you again private email. 

Bob S


> On Oct 31, 2019, at 10:07 , Klaus major-k via use-livecode 
>  wrote:
> 
> 
> 
>> Am 31.10.2019 um 18:04 schrieb Bob Sneidar via use-livecode 
>> :
>> 
>> When you call the command or when you save the script?
> 
> when hitting ENTER in the script editor = compiling
> 
>> Mine compiled.
> 
> ???
> I use LC 9.5 on macOS 10.14.6
> 
>> In any case I'll update it to use DO. 
>> 
>> Bob S
>> ...
>>> 
 on exportScaledImage pSourceFile, pDestFile, pScaleFactor, pFormat
 ...
 switch pFormat
   case "JPEG"
  export the templateimage to file (pDestFile) as JPEG
  break
   case "BMP"
  export the templateimage to file (pDestFile) as BMP
  break
   case "PNG"
  export the templateimage to file (pDestFile) as PNG
  break
 end switch
 ...
>>> too bad LC does not like a variable for the target format:
>>> ...
>>> export the templateimage to file pDestFile as pFormat
>>> ...
>>> -> Compile error
> 
> Best
> 
> Klaus
> 
> --
> Klaus Major
> https://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: Fun with the templateimage

[Klaus major-k via use-livecode]

> Am 31.10.2019 um 18:04 schrieb Bob Sneidar via use-livecode 
> :
> 
> When you call the command or when you save the script?

when hitting ENTER in the script editor = compiling

> Mine compiled.

???
I use LC 9.5 on macOS 10.14.6

> In any case I'll update it to use DO. 
> 
> Bob S
> ...
>> 
>>> on exportScaledImage pSourceFile, pDestFile, pScaleFactor, pFormat
>>> ...
>>> switch pFormat
>>>case "JPEG"
>>>   export the templateimage to file (pDestFile) as JPEG
>>>   break
>>>case "BMP"
>>>   export the templateimage to file (pDestFile) as BMP
>>>   break
>>>case "PNG"
>>>   export the templateimage to file (pDestFile) as PNG
>>>   break
>>> end switch
>>> ...
>> too bad LC does not like a variable for the target format:
>> ...
>> export the templateimage to file pDestFile as pFormat
>> ...
>> -> Compile error

Best

Klaus

--
Klaus Major
https://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: Fun with the templateimage

[Bob Sneidar via use-livecode]

When you call the command or when you save the script? Mine compiled. In any 
case I'll update it to use DO. 

Bob S


> On Oct 31, 2019, at 10:01 , Klaus major-k via use-livecode 
>  wrote:
> 
> Hi Bob,
> 
>> Am 31.10.2019 um 16:00 schrieb Bob Sneidar via use-livecode 
>> :
>> 
>> Or better yet: -- No error checking, assumes parameters are correct. Also 
>> not tested. :-)
>> 
>> on exportScaledImage pSourceFile, pDestFile, pScaleFactor, pFormat
>> ...
>>  switch pFormat
>> case "JPEG"
>>export the templateimage to file (pDestFile) as JPEG
>>break
>> case "BMP"
>>export the templateimage to file (pDestFile) as BMP
>>break
>> case "PNG"
>>export the templateimage to file (pDestFile) as PNG
>>break
>>  end switch
>> ...
> 
> too bad LC does not like a variable for the target format:
> ...
> export the templateimage to file pDestFile as pFormat
> ...
> -> Compile error
> 
> 
> Best
> 
> Klaus
> 
> --
> Klaus Major
> https://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: cr, lf, and reading in terminals/vim

[Bob Sneidar via use-livecode]

Possibly, but then where is the original file? And why make a new file when 
closed without saving? 

Bob S


> On Oct 31, 2019, at 09:54 , J. Landman Gay via use-livecode 
>  wrote:
> 
> Or could this be a result of OS Xs decision to save iterative versions of a 
> file whether you want it to or not?
> 
> --
> 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: Fun with the templateimage

[Klaus major-k via use-livecode]

Hi Bob,

> Am 31.10.2019 um 16:00 schrieb Bob Sneidar via use-livecode 
> :
> 
> Or better yet: -- No error checking, assumes parameters are correct. Also not 
> tested. :-)
> 
> on exportScaledImage pSourceFile, pDestFile, pScaleFactor, pFormat
>  ...
>   switch pFormat
>  case "JPEG"
> export the templateimage to file (pDestFile) as JPEG
> break
>  case "BMP"
> export the templateimage to file (pDestFile) as BMP
> break
>  case "PNG"
> export the templateimage to file (pDestFile) as PNG
> break
>   end switch
> ...

too bad LC does not like a variable for the target format:
...
export the templateimage to file pDestFile as pFormat
...
-> Compile error


Best

Klaus

--
Klaus Major
https://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: cr, lf, and reading in terminals/vim

[J. Landman Gay via use-livecode]

Or could this be a result of OS Xs decision to save iterative versions of a 
file whether you want it to or not?


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On October 31, 2019 11:46:29 AM Richard Gaskin via use-livecode 
 wrote:



Bob Sneidar wrote:

> I would expect I could open a file to look at it, close it without
> saving, and absolutely nothing would change. But it does.
>
> I know this because I tested it with one of the aforementioned Address
> Book Export files. I exported the file, then imported it without
> opening it in any MacOS app. Worked fine. Opened the file in Word,
> closed without saving, copier refused to import the file.
>
> That sort of thing is what I meant was reprehensible. Developers
> should not be taking those liberties.

When read-only tasks write, head should roll.

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

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

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





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

Re: cr, lf, and reading in terminals/vim

[Richard Gaskin via use-livecode]

Bob Sneidar wrote:

> I would expect I could open a file to look at it, close it without
> saving, and absolutely nothing would change. But it does.
>
> I know this because I tested it with one of the aforementioned Address
> Book Export files. I exported the file, then imported it without
> opening it in any MacOS app. Worked fine. Opened the file in Word,
> closed without saving, copier refused to import the file.
>
> That sort of thing is what I meant was reprehensible. Developers
> should not be taking those liberties.

When read-only tasks write, head should roll.

--
 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: Fun with the templateimage

[Richard Gaskin via use-livecode]

The "import snapshot" command had an "at size" option added several 
versions ago to facilitate some scaling tasks:


   import snapshot from the selectedObject at size 100,100

But oddly, no such option has been added to the "export snapshot" command.

--
 Richard Gaskin
 Fourth World Systems


Bob Sneidar wrote:

Or better yet: -- No error checking, assumes parameters are correct. Also not 
tested. :-)

on exportScaledImage pSourceFile, pDestFile, pScaleFactor, pFormat
   ## My good ol' banana, older users of MC might remember that one :-D
   set the filename of the templateimage to pSourceFile
   
   ## This was a know (to me) feature

   put the formattedwidth of the templateimage into tFW
   put the formattedheight of the templateimage into tFH
   ## Now you can apply some "rule of three" to scale the image while 
preserving its ratio
   ## I'll leave that up to you... :-)
   
   ## I cheated a bit:

   set the width of the templateimage to round(tFW * (pScaleFactor /100))
   set the height of the templateimage to round(tFH * (pScaleFactor /100))
   
   ## But this one really suprised me:

   switch pFormat
  case "JPEG"
 export the templateimage to file (pDestFile) as JPEG
 break
  case "BMP"
 export the templateimage to file (pDestFile) as BMP
 break
  case "PNG"
 export the templateimage to file (pDestFile) as PNG
 break
   end switch
   
   reset the templateimage

end exportScaledImage



___
use-livecode mailing list
use-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: cr, lf, and reading in terminals/vim

[Bob Sneidar via use-livecode]

I gave the wrong impression. I was saying that other apps and it perhaps the OS 
X system itself takes liberties with conversion of line endings. For instance, 
Mocrosoft Word and Excel. I would expect I could open a file to look at it, 
close it without saving, and absolutely nothing would change. But it does. 

I know this because I tested it with one of the aforementioned Address Book 
Export files. I exported the file, then imported it without opening it in any 
MacOS app. Worked fine. Opened the file in Word, closed without saving, copier 
refused to import the file. 

That sort of thing is what I meant was reprehensible. Developers should not be 
taking those liberties. 

Bob S


> On Oct 31, 2019, at 09:24 , Richard Gaskin via use-livecode 
>  wrote:
> 
> Bob Sneidar  wrote:
> > Upon examining the ascii value of every line terminator I discovered
> > something, perhaps the OS or the software itself, converted the
> > terminators to something else. I also find this practice to be not
> > just confusing, but reprehensible.
> 
> LC supports two write modes: text and binary.  Perhaps the editor you'd used 
> supports the equivalent of LC's text mode, where the data is indeed altered 
> to provide greater convenience for cross-platform line-endings, replacing 
> NULLs with spaces, etc.  This is consistent with how HyperTalk established 
> writes, and I've seen some text editor packages do similar things.
> 
> When you need to preserve data as-is, use binary mode.
> 
> Thankfully LC provides both.  HyperCard provided only text mode, and 
> SuperCard only binary mode.  I like being able to use each depending on what 
> I'm doing.


___
use-livecode mailing list
use-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: cr, lf, and reading in terminals/vim

[Brian Milby via use-livecode]

I’ll submit a PR tonight.

Thanks,
Brian
On Oct 31, 2019, 12:26 PM -0400, Richard Gaskin via use-livecode 
, wrote:
> Ben Rubinstein wrote:
>
> > Brian Milby wrote:
> > > My suggestion is to just bite the bullet and build LC where 'file'
> > > exports using LF on Mac
> >
> > Oh please yes!
>
> Seconded.
>
> Containing the scope of the remedy to text writes should affect very
> few, and those affected will probably welcome the change.
>
> What needs to be done to move this forward?
>
>
> Bob Sneidar wrote:
> > Upon examining the ascii value of every line terminator I discovered
> > something, perhaps the OS or the software itself, converted the
> > terminators to something else. I also find this practice to be not
> > just confusing, but reprehensible.
>
> LC supports two write modes: text and binary. Perhaps the editor you'd
> used supports the equivalent of LC's text mode, where the data is indeed
> altered to provide greater convenience for cross-platform line-endings,
> replacing NULLs with spaces, etc. This is consistent with how HyperTalk
> established writes, and I've seen some text editor packages do similar
> things.
>
> When you need to preserve data as-is, use binary mode.
>
> Thankfully LC provides both. HyperCard provided only text mode, and
> SuperCard only binary mode. I like being able to use each depending on
> what I'm doing.
>
> --
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.com http://www.FourthWorld.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: cr, lf, and reading in terminals/vim

[Richard Gaskin via use-livecode]

Ben Rubinstein wrote:

> Brian Milby wrote:
>> My suggestion is to just bite the bullet and build LC where 'file'
>> exports using LF on Mac
>
> Oh please yes!

Seconded.

Containing the scope of the remedy to text writes should affect very 
few, and those affected will probably welcome the change.


What needs to be done to move this forward?


Bob Sneidar  wrote:
> Upon examining the ascii value of every line terminator I discovered
> something, perhaps the OS or the software itself, converted the
> terminators to something else. I also find this practice to be not
> just confusing, but reprehensible.

LC supports two write modes: text and binary.  Perhaps the editor you'd 
used supports the equivalent of LC's text mode, where the data is indeed 
altered to provide greater convenience for cross-platform line-endings, 
replacing NULLs with spaces, etc.  This is consistent with how HyperTalk 
established writes, and I've seen some text editor packages do similar 
things.


When you need to preserve data as-is, use binary mode.

Thankfully LC provides both.  HyperCard provided only text mode, and 
SuperCard only binary mode.  I like being able to use each depending on 
what I'm doing.


--
 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: cr, lf, and reading in terminals/vim

[Klaus major-k via use-livecode]

Hi Ben,

> Am 31.10.2019 um 16:16 schrieb Ben Rubinstein via use-livecode 
> :
> 
>> My suggestion is to just bite the bullet and build LC where 'file' exports
>> using LF on Mac
> Oh please yes!
> It's been 18 years since the Mac standardised on LF. (And AFAIK Metacard only 
> started supporting the Mac eight years before that, so 
> Metacard/Revolution/LiveCode has already been writing the 'wrong' files for 
> twice as long as it was writing the 'right' ones.)

The first Mac and Win version of Metacard came out in 1999.

> ...
> 
> Ben

Best

Klaus

--
Klaus Major
https://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: cr, lf, and reading in terminals/vim

[Ben Rubinstein via use-livecode]

My suggestion is to just bite the bullet and build LC where 'file' exports
using LF on Mac


Oh please yes!

It's been 18 years since the Mac standardised on LF. (And AFAIK Metacard only 
started supporting the Mac eight years before that, so 
Metacard/Revolution/LiveCode has already been writing the 'wrong' files for 
twice as long as it was writing the 'right' ones.)


As you say, it's moot on import to LC; so the only instance where this change 
could cause a compatibility issue would be where an LC-based tool is 
generating files for consumption by some other system which is dependent on 
them being CR format. Such a tool is presumably going to be Mac based - a 
Windows or *nix system would be more likely to reject that format than depend 
on it, if it accepts the format it's probably sophisticated enough to accept 
LF as well. So we're talking about a Mac based system which is still running 
but which in 18 years hasn't been updated to at least also accept the native 
format of the OS that it runs on. And this will only be an issue if someone 
updates their app producing these files to the latest version of LC (in which 
case they will surely anyway be having to take special precautions and write 
the file as binary to avoid confusing an ancient system with UTF8??). I don't 
know if such a case exists; I certainly doubt if there are very many such.


Brian - what would be required before you could submit your work as a PR again?

Ben


On 31/10/2019 03:26, Brian Milby via use-livecode wrote:

My suggestion is to just bite the bullet and build LC where 'file' exports
using LF on Mac.  The change required is literally a couple of characters
in one file (maybe two files to include the server default, but you can
already change it there on demand).  Leave the constants as they are (LF).
It could be announced as something for 9.6 to give the community time to
test.  The only way it would be a problem is if you were exporting a text
file on a Mac that was going to be consumed by a program that depended on
CR line endings.

Since LC consumes all 3 formats equally well, it would be no issue on the
read side.

Internally the concern is the build tools/environment.  I've built LC with
it changed (actually submitted it as part of a PR, but had to reverse it)
before 9 was GM.  It passed the automated tests when I did it.

On Wed, Oct 30, 2019 at 10:28 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:


Brian Milby wrote:

  > The reason for the difficulty is that internally LC uses LF as the
  > line ending.  The cr, lf, and return constants all actually map to LF.
  > When you write a text file, LC will convert line endings to the native
  > format.  So for Windows you get CRLF, Linux gets LF, and Mac gets CR.
  > I take issue with this because as of OS X the native line ending for
  > the OS is actually now LF...

Agreed.

The hard question is: What shall we do about it?

On the one hand, we have millions of lines of code in our community that
use CR, and a certain percentage of those are dependent on CR having a
specific value (even if that value is inconsistent with the true ASCII
value).

On the other hand, we have a constant that suggests it's one thing when
it's really something else, and at this point that design decision
benefits no one and confuses many.

Favor backward compatibility, or language learnability/usability?

--
   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: Fun with the templateimage

[Bob Sneidar via use-livecode]

Or better yet: -- No error checking, assumes parameters are correct. Also not 
tested. :-)

on exportScaledImage pSourceFile, pDestFile, pScaleFactor, pFormat
   ## My good ol' banana, older users of MC might remember that one :-D
   set the filename of the templateimage to pSourceFile
   
   ## This was a know (to me) feature
   put the formattedwidth of the templateimage into tFW
   put the formattedheight of the templateimage into tFH
   ## Now you can apply some "rule of three" to scale the image while 
preserving its ratio
   ## I'll leave that up to you... :-)
   
   ## I cheated a bit:
   set the width of the templateimage to round(tFW * (pScaleFactor /100))
   set the height of the templateimage to round(tFH * (pScaleFactor /100))
   
   ## But this one really suprised me:
   switch pFormat
  case "JPEG"
 export the templateimage to file (pDestFile) as JPEG
 break
  case "BMP"
 export the templateimage to file (pDestFile) as BMP
 break
  case "PNG"
 export the templateimage to file (pDestFile) as PNG
 break
   end switch
   
   reset the templateimage
end exportScaledImage


> On Oct 30, 2019, at 13:13 , Klaus major-k via use-livecode 
>  wrote:
> 
> Hi all,
> 
> we know that "the templatexx" is a very helpful thingie.
> 
> But I was really surprised that we can even EXPORT something
> from the templateimage until I tried 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: cr, lf, and reading in terminals/vim

[Bob Sneidar via use-livecode]

Not to disagree, but just to mention this is not exclusive to LC. If I download 
the address book of a Toshiba copier, then just OPEN it with Microsoft Office 
ot TextEdit, then close without saving, I can no longer import that file into 
the copier again. 

Upon examining the ascii value of every line terminator I discovered something, 
perhaps the OS or the software itself, converted the terminators to something 
else. I also find this practice to be not just confusing, but reprehensible. 
I'm sure it was done as an easy fix to some other text display problem, but 
developers have no license to change the data in a file without the user's 
knowledge and approval. 

That being said, I also use open binary for write to get around this 
limitation. As long as I don't put data into a text field as temporary storage, 
in other words just memory, then the line endings are preserved no matter what 
OS I run on. 

Bob S


> On Oct 30, 2019, at 19:27 , Richard Gaskin via use-livecode 
>  wrote:
> 
> Brian Milby wrote:
> 
> > The reason for the difficulty is that internally LC uses LF as the
> > line ending.  The cr, lf, and return constants all actually map to LF.
> > When you write a text file, LC will convert line endings to the native
> > format.  So for Windows you get CRLF, Linux gets LF, and Mac gets CR.
> > I take issue with this because as of OS X the native line ending for
> > the OS is actually now LF...
> 
> Agreed.
> 
> The hard question is: What shall we do about it?
> 
> On the one hand, we have millions of lines of code in our community that use 
> CR, and a certain percentage of those are dependent on CR having a specific 
> value (even if that value is inconsistent with the true ASCII value).
> 
> On the other hand, we have a constant that suggests it's one thing when it's 
> really something else, and at this point that design decision benefits no one 
> and confuses many.
> 
> Favor backward compatibility, or language learnability/usability?
> 
> -- 
> Richard Gaskin


___
use-livecode mailing list
use-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: cr, lf, and reading in terminals/vim

[Bob Sneidar via use-livecode]

Interesting. This may be why when I copy code from the SE and paste it into an 
email I get double line spacing. 

Bob S


> On Oct 30, 2019, at 19:08 , Brian Milby via use-livecode 
>  wrote:
> 
> The reason for the difficulty is that internally LC uses LF as the line
> ending.  The cr, lf, and return constants all actually map to LF.  When you
> write a text file, LC will convert line endings to the native format.  So
> for Windows you get CRLF, Linux gets LF, and Mac gets CR.  I take issue
> with this because as of OS X the native line ending for the OS is actually
> now LF (although most of the stuff built in will handle either LF or CR).
> As a result, I always will generate my text files using binary mode,
> encoded as UTF8 on the Mac.  I will read everything using file to get the
> automatic conversion to LF though.  This does complicate making cross
> platform code that generates text files since you have to check the OS and
> either handle Windows or Mac differently.


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