Re: Crazy script-only stack question

[Sannyasin Brahmanathaswami via use-livecode]

Jacque wrote:

If you're just using red-dot breakpoints then it isn't as difficult to 
remove them, you can just use the "remove all breakpoints" menu item.

I wonder if a case could be made for the IDE to also search and line in any 
script that = 

breakpoint

and either comment or delete it out?

BR

___
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: Crazy script-only stack question

[J. Landman Gay via use-livecode]

On 1/26/18 3:27 PM, Mark Wieder via use-livecode wrote:

On 01/26/2018 12:42 PM, J. Landman Gay via use-livecode wrote:

The deal is, if the standalone is anywhere near a running copy of the 
IDE, remote debugging will kick in and stop the script (assuming the 
"breakpoint" command works as expected.) To avoid that, you'd need to 
either quit LC, or restart it and refuse the remote connection.


Yes, that's the way it's supposed to work. So maybe I misunderstood... 
you want a standalone app that's launched in the same subnet where 
there's a running IDE? How about if you just disable Script Debug Mode 
from the menubar? That *should* (fingers crossed) cause breakpoints to 
be ignored. It does here, but then again I don't have the Business 
remote debugger.




I forgot about the menu item. You're right, that would be the solution.

--
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: Crazy script-only stack question

[Mark Wieder via use-livecode]

On 01/26/2018 12:42 PM, J. Landman Gay via use-livecode wrote:

The deal is, if the standalone is anywhere near a running copy of the 
IDE, remote debugging will kick in and stop the script (assuming the 
"breakpoint" command works as expected.) To avoid that, you'd need to 
either quit LC, or restart it and refuse the remote connection.


Yes, that's the way it's supposed to work. So maybe I misunderstood... 
you want a standalone app that's launched in the same subnet where 
there's a running IDE? How about if you just disable Script Debug Mode 
from the menubar? That *should* (fingers crossed) cause breakpoints to 
be ignored. It does here, but then again I don't have the Business 
remote debugger.


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


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

Re: Crazy script-only stack question

[J. Landman Gay via use-livecode]

On 1/26/18 1:11 PM, Mark Wieder via use-livecode wrote:

On 01/23/2018 01:15 PM, J. Landman Gay via use-livecode wrote:

On 1/23/18 12:27 PM, Mike Kerner via use-livecode wrote:

@JLG I thought with "breaktpoint" you could debug SOS behaviors


I haven't actually tried that yet. It would be more difficult to avoid 
debugging when you just want to run the stack normally but would be 
better than nothing. I suppose you'd need to remember to remove all 
the breakpoint commands from the SOS files at some point. Have you 
tried it yet?




I can't say anything definitive about the Business-level remote 
debugging mechanism, but I can say that with PowerDebug you can ship a 
standalone app with breakpoints intact without problems. Breakpoints 
have (almost) no effect in standalone apps unless there is a debugger 
waiting around to catch the traceBreak etc messages. (The 'almost' in 
that sentence is because each invocation of a breakpoint command will 
issue a traceBreak message, but the effect is the same as dispatching 
any message that doesn't get handled, and is too small to be measured. 
Since the built-in remote debugger works in a similar fashion over a 
socket connection, I can't imagine there would be any difference.




The deal is, if the standalone is anywhere near a running copy of the 
IDE, remote debugging will kick in and stop the script (assuming the 
"breakpoint" command works as expected.) To avoid that, you'd need to 
either quit LC, or restart it and refuse the remote connection.


If you're just using red-dot breakpoints then it isn't as difficult to 
remove them, you can just use the "remove all breakpoints" menu item.


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

Reloading script-only stacks

[Geoff Canyon via use-livecode]

With version control, switching branches switches out SoS files. Is it 
best/necessary to then run through the stackfiles and set the destroystack of 
each to true and close/reopen them? Or is there a better way?

gc
___
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: is it safe to rely on the hash of a livecode variable from a character encoding standpoint?

[Tom Glod via use-livecode]

wow i am glad I asked..thanks for the detailed answer Mark.

On Fri, Jan 26, 2018 at 1:31 PM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2018-01-26 18:50, Tom Glod via use-livecode wrote:
>
>> Hi Everyone,
>>
>> I want to ask how likely it is that at some point in the future some
>> change
>> in character encoding could start producing a different hash for the same
>> sentence? just thinking about the nightmare scenarios facing a project
>> that
>> heavily uses hashing to verify and address content..in international
>> characters..to boot.
>>
>
> The hash/digest functions (e.g. sha1Digest) operate on binary data. So if
> you do:
>
>   put sha1Digest("foobar")
>
> Then "foobar" is first converted to binary data using the native encoding
> (i.e. the backwards-compatibility rule we have), then that is hashed.
>
> In every case where you produce a hash you have to explicitly choose an
> encoding - so pick you favourite (unicode friendly!) encoding and do:
>
>   get sha1Digest(textEncode(tMyString, tMyEncoding))
>
> If you are generating hashes of strings to send to existing things, then
> it should say *somewhere* in the docs of the thing you are sending what
> encoding to use before applying the hash.
>
> Also be aware that unicode allows the 'same' string to be encoded in
> multiple ways - so its probably wise to choose a normalization form first
> too (see normalizeText) - otherwise you could have two strings which look
> the same (e.g. e,acute / e-acute) but hash to a different value.
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
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: Crazy script-only stack question

[Mark Wieder via use-livecode]

On 01/23/2018 01:15 PM, J. Landman Gay via use-livecode wrote:

On 1/23/18 12:27 PM, Mike Kerner via use-livecode wrote:

@JLG I thought with "breaktpoint" you could debug SOS behaviors


I haven't actually tried that yet. It would be more difficult to avoid 
debugging when you just want to run the stack normally but would be 
better than nothing. I suppose you'd need to remember to remove all the 
breakpoint commands from the SOS files at some point. Have you tried it 
yet?




I can't say anything definitive about the Business-level remote 
debugging mechanism, but I can say that with PowerDebug you can ship a 
standalone app with breakpoints intact without problems. Breakpoints 
have (almost) no effect in standalone apps unless there is a debugger 
waiting around to catch the traceBreak etc messages. (The 'almost' in 
that sentence is because each invocation of a breakpoint command will 
issue a traceBreak message, but the effect is the same as dispatching 
any message that doesn't get handled, and is too small to be measured. 
Since the built-in remote debugger works in a similar fashion over a 
socket connection, I can't imagine there would be any difference.


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

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

Re: is it safe to rely on the hash of a livecode variable from a character encoding standpoint?

[Mark Waddingham via use-livecode]

On 2018-01-26 18:50, Tom Glod via use-livecode wrote:

Hi Everyone,

I want to ask how likely it is that at some point in the future some 
change
in character encoding could start producing a different hash for the 
same
sentence? just thinking about the nightmare scenarios facing a project 
that
heavily uses hashing to verify and address content..in 
international

characters..to boot.


The hash/digest functions (e.g. sha1Digest) operate on binary data. So 
if you do:


  put sha1Digest("foobar")

Then "foobar" is first converted to binary data using the native 
encoding (i.e. the backwards-compatibility rule we have), then that is 
hashed.


In every case where you produce a hash you have to explicitly choose an 
encoding - so pick you favourite (unicode friendly!) encoding and do:


  get sha1Digest(textEncode(tMyString, tMyEncoding))

If you are generating hashes of strings to send to existing things, then 
it should say *somewhere* in the docs of the thing you are sending what 
encoding to use before applying the hash.


Also be aware that unicode allows the 'same' string to be encoded in 
multiple ways - so its probably wise to choose a normalization form 
first too (see normalizeText) - otherwise you could have two strings 
which look the same (e.g. e,acute / e-acute) but hash to a different 
value.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

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

is it safe to rely on the hash of a livecode variable from a character encoding standpoint?

[Tom Glod via use-livecode]

Hi Everyone,

I want to ask how likely it is that at some point in the future some change
in character encoding could start producing a different hash for the same
sentence? just thinking about the nightmare scenarios facing a project that
heavily uses hashing to verify and address content..in international
characters..to boot.

Any thoughts on this would really help me out to not make a mistake in my
approach.

Thanks,

Tom
___
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: "clear" a command?

[Klaus major-k via use-livecode]

Hi Paul,

> Am 26.01.2018 um 18:16 schrieb Paul Hibbert via use-livecode 
> :
> 
> Because “clear” is also a synonym of “delete”. :-)

I came to exact the same conclusion! :-D

> Paul
> 
>> On Jan 26, 2018, at 3:41 AM, Klaus major-k via use-livecode 
>>  wrote:
>> Hi friends,
>> I just saw a code snippet in the german LC forum,
>> did not believe it would work, tested it and in fact it DID?
>> Here the line in question:
>> ...
>> clear the last word in field 1
>> ...
>> That actually deletes the last word of a field!? Holy Moses!
>> According to the docs "clear" is just one of the many INK blendmodes.

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: "clear" a command?

[Paul Hibbert via use-livecode]

Because “clear” is also a synonym of “delete”. :-)

Paul



> On Jan 26, 2018, at 3:41 AM, Klaus major-k via use-livecode 
>  wrote:
> 
> Hi friends,
> 
> I just saw a code snippet in the german LC forum,
> did not believe it would work, tested it and in fact it DID?
> 
> Here the line in question:
> ...
> clear the last word in field 1
> ...
> That actually deletes the last word of a field!? Holy Moses!
> 
> According to the docs "clear" is just one of the many INK blendmodes.
> I'm completely puzzled! 
> 
> Any comment appreciated. :-)
> 
> 
> 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: Preserving Detailed Field Content

[Roger Guay via use-livecode]

Don’t mean to clutter this list, but I want to be sure to thank Ralph and Klaus 
and Bob for responses within 5 minutes of my posting.

What a great resource this list is!!

Roger

> On Jan 26, 2018, at 9:01 AM, Roger Guay via use-livecode 
>  wrote:
> 
> And thanks to you too, Bob.
> 
>> On Jan 26, 2018, at 9:00 AM, Bob Sneidar via use-livecode 
>>  wrote:
>> 
>> Get and set the rtftext of the field. 
>> 
>> Bob S
>> 
>> 
>>> On Jan 26, 2018, at 07:56 , Roger Guay via use-livecode 
>>>  wrote:
>>> 
>>> I have a multiple line field with some lines of different color and 
>>> strikeout textStyle. If I set the custom property, the cContent, of that 
>>> field to the field itself, the textColor and TextStyle of each line is 
>>> lost. Is there a simple way to capture the contents of a field with varied 
>>> textColor and textStyle preserved?
>>> 
>>> Sorry if this sounds confusing.
>>> 
>>> Thanks very much,
>>> 
>>> Roger
>> 
>> 
>> ___
>> 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: Preserving Detailed Field Content

[Roger Guay via use-livecode]

And thanks to you too, Bob.

> On Jan 26, 2018, at 9:00 AM, Bob Sneidar via use-livecode 
>  wrote:
> 
> Get and set the rtftext of the field. 
> 
> Bob S
> 
> 
>> On Jan 26, 2018, at 07:56 , Roger Guay via use-livecode 
>>  wrote:
>> 
>> I have a multiple line field with some lines of different color and 
>> strikeout textStyle. If I set the custom property, the cContent, of that 
>> field to the field itself, the textColor and TextStyle of each line is lost. 
>> Is there a simple way to capture the contents of a field with varied 
>> textColor and textStyle preserved?
>> 
>> Sorry if this sounds confusing.
>> 
>> Thanks very much,
>> 
>> Roger
> 
> 
> ___
> 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: Preserving Detailed Field Content

[Bob Sneidar via use-livecode]

Get and set the rtftext of the field. 

Bob S


> On Jan 26, 2018, at 07:56 , Roger Guay via use-livecode 
>  wrote:
> 
> I have a multiple line field with some lines of different color and strikeout 
> textStyle. If I set the custom property, the cContent, of that field to the 
> field itself, the textColor and TextStyle of each line is lost. Is there a 
> simple way to capture the contents of a field with varied textColor and 
> textStyle preserved?
> 
> Sorry if this sounds confusing.
> 
> Thanks very much,
> 
> Roger


___
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: Preserving Detailed Field Content

[Klaus major-k via use-livecode]

Hi Roger,

> Am 26.01.2018 um 16:56 schrieb Roger Guay via use-livecode 
> :
> 
> I have a multiple line field with some lines of different color and strikeout 
> textStyle. If I set the custom property, the cContent, of that field to the 
> field itself, the textColor and TextStyle of each line is lost. Is there a 
> simple way to capture the contents of a field with varied textColor and 
> textStyle preserved?
> 
> Sorry if this sounds confusing.

it doesn't! :-)

Just set the custom property to the HTMLTEXT of the field!
And restore THAT later.

> Thanks very much,
> 
> Roger

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: Preserving Detailed Field Content

[Ralph DiMola via use-livecode]

Roger,

The htmltext will preserve all of that.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net

-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Roger Guay via use-livecode
Sent: Friday, January 26, 2018 10:56 AM
To: use-livecode@lists.runrev.com
Cc: Roger Guay
Subject: Preserving Detailed Field Content

I have a multiple line field with some lines of different color and
strikeout textStyle. If I set the custom property, the cContent, of that
field to the field itself, the textColor and TextStyle of each line is lost.
Is there a simple way to capture the contents of a field with varied
textColor and textStyle preserved?

Sorry if this sounds confusing.

Thanks very much,

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

Preserving Detailed Field Content

[Roger Guay via use-livecode]

I have a multiple line field with some lines of different color and strikeout 
textStyle. If I set the custom property, the cContent, of that field to the 
field itself, the textColor and TextStyle of each line is lost. Is there a 
simple way to capture the contents of a field with varied textColor and 
textStyle preserved?

Sorry if this sounds confusing.

Thanks very much,

Roger
___
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: "clear" a command?

[Bob Sneidar via use-livecode]

I used to play the Cabaret in high school. ;-)

Bob S


> On Jan 26, 2018, at 04:55 , Klaus major-k via use-livecode 
>  wrote:
> 
> Hi Hermann,
> 
>> Am 26.01.2018 um 13:51 schrieb hh via use-livecode 
>> :
>> 
>> Klaus wrote: ... I only looked for "clear".
>> 
>> You never used that?
> 
> no, never even heard of that in the last 18 years of using MC and Rev and LC.
> 
>> This is a symptom for ... (forgot the name of that disease).
> 
> "Malmsheimer", like in Jochen M., the german cabaret artist, I think...? 8-)
> 
> 
> Best
> 
> Klaus (or was it Shirley?)
> --
> Klaus Major


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

Re: What Env Variable set when saving standalone?

[Bob Sneidar via use-livecode]

Thanks Jacque. I'm sure I could do some kind of workaround like that, but I 
actually use the app while in dev mode, which is the main way I debug it, and 
need the login stack to open modally in that environment to get what I need to 
function. Maybe what I will do is check for a modifier key like the optionKey 
down to open modally in dev env. 

Bob S


> On Jan 25, 2018, at 18:32 , J. Landman Gay via use-livecode 
>  wrote:
> 
> I might not have been clear. You'd keep the login stack a toplevel stack all 
> the time. In whatever handler actually launches that stack, you'd check the 
> environment and only open it as modal if the environment is "standalone".
> 
> During development the login stack is toplevel. It should be able to retrieve 
> db info normally in that mode. The reason you want a modal is so that users 
> can't click away until the data loads, but as the developer you'd know not to 
> do that. You'd just wait for the data and then proceed normally.
> 
> Seems like the simplest solution to me. A toplevel stack won't hinder 
> development or standalone builds, and it will show up as modal if the 
> environment is "standalone" (or if it's not "development", or whatever other 
> test you want to apply.)
> 
> On 1/25/18 7:02 PM, Bob Sneidar via use-livecode wrote:
>> I assume because it's opened modally, and the builder obviously needs to 
>> open another stack but can't because the modal stack is blocking the 
>> progress of the script that told my app to open it. (I know it's confisung 
>> but that is how modality works I guess).
>> Bob S
>>> On Jan 25, 2018, at 16:24 , J. Landman Gay via use-livecode 
>>>  wrote:
>>> 
>>> Regardless of the stack mode, why wouldn't it retrieve info? As the 
>>> developer you'd know not to click elsewhere until the data is there, right?
>>> 
>>> --
>>> Jacqueline Landman Gay | jac...@hyperactivesw.com
>>> HyperActive Software   | http://www.hyperactivesw.com
> 
> 
> -- 
> Jacqueline Landman Gay | jac...@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: Question about script-only stacks

[Trevor DeVore via use-livecode]

On Fri, Jan 26, 2018 at 6:16 AM Rolf Kocherhans via use-livecode <
use-livecode@lists.runrev.com> wrote:

> There seems a lot of hype recently about script-only stacks.
> I agree that they are cool vor GIT and work perfectly, but
> it came to my mind - how are you go about it when you want to
> protect your scripts.
>
> Are they also encrypted by a password when you compile a stack,
> and if not what would be the best way to d it ?


You would need to convert the script only stacks to regular stacks and set
the password when you deploy your app.

The Levure framework packager will perform this conversion for you when you
build standalones with it. This gives you the benefit of source control
while you develop but password protection when you distribute.

Trevor DeVore
ScreenSteps

>
___
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: "clear" a command?

[Klaus major-k via use-livecode]

Hi Hermann,

> Am 26.01.2018 um 13:51 schrieb hh via use-livecode 
> :
> 
> Klaus wrote: ... I only looked for "clear".
> 
> You never used that?

no, never even heard of that in the last 18 years of using MC and Rev and LC.

> This is a symptom for ... (forgot the name of that disease).

"Malmsheimer", like in Jochen M., the german cabaret artist, I think...? 8-)


Best

Klaus (or was it Shirley?)
--
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: "clear" a command?

[hh via use-livecode]

Klaus wrote: ... I only looked for "clear".

You never used that?
This is a symptom for ... (forgot the name of that disease).



___
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: "clear" a command?

[Klaus major-k via use-livecode]

Hi Hermann,

> Am 26.01.2018 um 13:43 schrieb hh via use-livecode 
> :
> 
> According to dictionary:
> "clear chunk" is a synonym to "delete chunk".

ah, yes, sorry, I only looked for "clear".
Thanks for the hint!


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: "clear" a command?

[hh via use-livecode]

According to dictionary:
"clear chunk" is a synonym to "delete chunk".


___
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

Question about script-only stacks

[Rolf Kocherhans via use-livecode]

There seems a lot of hype recently about script-only stacks.
I agree that they are cool vor GIT and work perfectly, but
it came to my mind - how are you go about it when you want to
protect your scripts.

Are they also encrypted by a password when you compile a stack,
and if not what would be the best way to d it ?

Cheers
Rolf

___
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

"clear" a command?

[Klaus major-k via use-livecode]

Hi friends,

I just saw a code snippet in the german LC forum,
did not believe it would work, tested it and in fact it DID?

Here the line in question:
...
clear the last word in field 1
...
That actually deletes the last word of a field!? Holy Moses!

According to the docs "clear" is just one of the many INK blendmodes.
I'm completely puzzled! 

Any comment appreciated. :-)


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