Re: Encrypting Stack Breaks Field References

[Trevor DeVore via use-livecode]

On Tue, Dec 22, 2020 at 6:23 PM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hmmm… Isn’t Levure almost completely based on script only stacks?


You can use binary or script only stacks with Levure. It doesn’t care one
way or the other.  It’s just reading in stack files you add to your app
folder.

-- 
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: Encrypting Stack Breaks Field References

[Bob Sneidar via use-livecode]

I chose the more likely of the two possibilities. :-)

Bob S


On Dec 22, 2020, at 9:38 PM, J. Landman Gay via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

Rather, I didn't mean the team invented script-only stacks for Trevor in 
particular, but rather than they moved to git and needed text files.

English is such a positional language.
--
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: Encrypting Stack Breaks Field References

[J. Landman Gay via use-livecode]

Rather, I didn't mean the team invented script-only stacks for Trevor in 
particular, but rather than they moved to git and needed text files.


English is such a positional language.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On December 22, 2020 8:51:36 PM "J. Landman Gay via use-livecode" 
 wrote:



Trevor uses git, which is why script-only stacks were invented. The LC team
uses git too.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On December 22, 2020 6:24:22 PM Bob Sneidar via use-livecode
 wrote:


Hmmm… Isn’t Levure almost completely based on script only stacks?

Bob S



On Dec 22, 2020, at 4:09 PM, J. Landman Gay via use-livecode
 wrote:

Unless you specifically need text files for git or some other reason, you
don't really need script-only stacks. Put the script in a button and then
put it in use or use it as a backscript. It will be encrypted when the
stack is. Another advantage to keeping scripts in the stack is that they
work with remote debugging, unlike text based scripts.

Brian Milby's script tracker is also a way to get the best of both worlds.
It saves scripts out to text files for uploading to github while keeping
the advantages of stack-based scripts.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On December 22, 2020 3:24:11 PM Bob Sneidar via use-livecode
 wrote:


What he said. The promise of creating standalones and encrypted stacks
containing code sounds promising, but there are caveats. It begs the
question, how do we encrypt script only stacks or libraries? I don’t use
encrypted stacks because my code is for internal use only, but if I ever
went commercial, this would be something I would need.

Bob S



On Dec 13, 2020, at 4:02 PM, Richard Gaskin via use-livecode
 wrote:

Ron Noice wrote:

? My program (built with LC 9.6.1 Indy Windows) contains a large number
> of references to fields by variables.
...
> only when I encrypt it does it fight back. Here's a simplified example
> of what I'm doing:
>
> create group "grpTree"
> ...
> copy fld "baseBox" to grp "grpTree"

^ that's your issue.

Copying objects is disallowed in an encrypted stack, since of course once
an object is copied it could be pasted into an unencrypted stack, and thus
expose the source.

You might consider moving the code from the encrypted stack to an encrypted
behavior object, leaving the stack where copying must be done unencrypted.

But if these objects are being copied only by script for the purpose of
automatically building out a UI, without a need to alter the user's
clipboard, you might consider using the clone command instead.

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


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





___
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: Encrypting Stack Breaks Field References

[J. Landman Gay via use-livecode]

Trevor uses git, which is why script-only stacks were invented. The LC team 
uses git too.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On December 22, 2020 6:24:22 PM Bob Sneidar via use-livecode 
 wrote:



Hmmm… Isn’t Levure almost completely based on script only stacks?

Bob S


On Dec 22, 2020, at 4:09 PM, J. Landman Gay via use-livecode 
 wrote:


Unless you specifically need text files for git or some other reason, you 
don't really need script-only stacks. Put the script in a button and then 
put it in use or use it as a backscript. It will be encrypted when the 
stack is. Another advantage to keeping scripts in the stack is that they 
work with remote debugging, unlike text based scripts.


Brian Milby's script tracker is also a way to get the best of both worlds. 
It saves scripts out to text files for uploading to github while keeping 
the advantages of stack-based scripts.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On December 22, 2020 3:24:11 PM Bob Sneidar via use-livecode 
 wrote:


What he said. The promise of creating standalones and encrypted stacks 
containing code sounds promising, but there are caveats. It begs the 
question, how do we encrypt script only stacks or libraries? I don’t use 
encrypted stacks because my code is for internal use only, but if I ever 
went commercial, this would be something I would need.


Bob S


On Dec 13, 2020, at 4:02 PM, Richard Gaskin via use-livecode 
 wrote:


Ron Noice wrote:

? My program (built with LC 9.6.1 Indy Windows) contains a large number
> of references to fields by variables.
...
> only when I encrypt it does it fight back. Here's a simplified example
> of what I'm doing:
>
> create group "grpTree"
> ...
> copy fld "baseBox" to grp "grpTree"

^ that's your issue.

Copying objects is disallowed in an encrypted stack, since of course once 
an object is copied it could be pasted into an unencrypted stack, and thus 
expose the source.


You might consider moving the code from the encrypted stack to an encrypted 
behavior object, leaving the stack where copying must be done unencrypted.


But if these objects are being copied only by script for the purpose of 
automatically building out a UI, without a need to alter the user's 
clipboard, you might consider using the clone command instead.


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


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

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





___
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: Encrypting Stack Breaks Field References

[Bob Sneidar via use-livecode]

Hmmm… Isn’t Levure almost completely based on script only stacks? 

Bob S


> On Dec 22, 2020, at 4:09 PM, J. Landman Gay via use-livecode 
>  wrote:
> 
> Unless you specifically need text files for git or some other reason, you 
> don't really need script-only stacks. Put the script in a button and then put 
> it in use or use it as a backscript. It will be encrypted when the stack is. 
> Another advantage to keeping scripts in the stack is that they work with 
> remote debugging, unlike text based scripts.
> 
> Brian Milby's script tracker is also a way to get the best of both worlds. It 
> saves scripts out to text files for uploading to github while keeping the 
> advantages of stack-based scripts.
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com
> On December 22, 2020 3:24:11 PM Bob Sneidar via use-livecode 
>  wrote:
> 
>> What he said. The promise of creating standalones and encrypted stacks 
>> containing code sounds promising, but there are caveats. It begs the 
>> question, how do we encrypt script only stacks or libraries? I don’t use 
>> encrypted stacks because my code is for internal use only, but if I ever 
>> went commercial, this would be something I would need.
>> 
>> Bob S
>> 
>> 
>>> On Dec 13, 2020, at 4:02 PM, Richard Gaskin via use-livecode 
>>>  wrote:
>>> 
>>> Ron Noice wrote:
>>> 
>>> ? My program (built with LC 9.6.1 Indy Windows) contains a large number
>>> > of references to fields by variables.
>>> ...
>>> > only when I encrypt it does it fight back. Here's a simplified example
>>> > of what I'm doing:
>>> >
>>> > create group "grpTree"
>>> > ...
>>> > copy fld "baseBox" to grp "grpTree"
>>> 
>>> ^ that's your issue.
>>> 
>>> Copying objects is disallowed in an encrypted stack, since of course once 
>>> an object is copied it could be pasted into an unencrypted stack, and thus 
>>> expose the source.
>>> 
>>> You might consider moving the code from the encrypted stack to an encrypted 
>>> behavior object, leaving the stack where copying must be done unencrypted.
>>> 
>>> But if these objects are being copied only by script for the purpose of 
>>> automatically building out a UI, without a need to alter the user's 
>>> clipboard, you might consider using the clone command instead.
>>> 
>>> --
>>> Richard Gaskin
>>> Fourth World Systems
>>> Software Design and Development for the Desktop, Mobile, and the Web
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> 
> 
> ___
> 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: Encrypting Stack Breaks Field References

[J. Landman Gay via use-livecode]

Unless you specifically need text files for git or some other reason, you 
don't really need script-only stacks. Put the script in a button and then 
put it in use or use it as a backscript. It will be encrypted when the 
stack is. Another advantage to keeping scripts in the stack is that they 
work with remote debugging, unlike text based scripts.


Brian Milby's script tracker is also a way to get the best of both worlds. 
It saves scripts out to text files for uploading to github while keeping 
the advantages of stack-based scripts.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On December 22, 2020 3:24:11 PM Bob Sneidar via use-livecode 
 wrote:


What he said. The promise of creating standalones and encrypted stacks 
containing code sounds promising, but there are caveats. It begs the 
question, how do we encrypt script only stacks or libraries? I don’t use 
encrypted stacks because my code is for internal use only, but if I ever 
went commercial, this would be something I would need.


Bob S


On Dec 13, 2020, at 4:02 PM, Richard Gaskin via use-livecode 
 wrote:


Ron Noice wrote:

? My program (built with LC 9.6.1 Indy Windows) contains a large number
> of references to fields by variables.
...
> only when I encrypt it does it fight back. Here's a simplified example
> of what I'm doing:
>
> create group "grpTree"
> ...
> copy fld "baseBox" to grp "grpTree"

^ that's your issue.

Copying objects is disallowed in an encrypted stack, since of course once 
an object is copied it could be pasted into an unencrypted stack, and thus 
expose the source.


You might consider moving the code from the encrypted stack to an encrypted 
behavior object, leaving the stack where copying must be done unencrypted.


But if these objects are being copied only by script for the purpose of 
automatically building out a UI, without a need to alter the user's 
clipboard, you might consider using the clone command instead.


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


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

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





___
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: Encrypting Stack Breaks Field References

[Curry Kenworthy via use-livecode]

Bob:

> The promise of creating standalones and encrypted stacks
> containing code sounds promising, but there are caveats.

Just like anything else - you have to learn the ropes. First time at any 
task can present some challenges. For those in the habit of encrypting 
stacks, it comes more naturally.


Script-only would require the most discipline, so start with UI+script 
projects and work your way up from there.


(Bug-reporting as you go, if necessary. The history of LC protection, 
like LC everything else, has not been without hiccups along the way.)


Also

No idea if it happened in this particular case, but I see plenty of 
similar problems people have due to the copy/paste LC coding culture.


By which I mean: How do I do X in LC? Ah, here's some code - presto!

The problem SEEMS solved. Learning SEEMS to have happened.

The perfect Acme solution. Then a different context comes along, maybe a 
different OS, or an encrypted stack and - wham - coyote hits a wall. 
Road runner zooms away.


People don't realize (and someone may pipe up and argue against) the 
fact that just because code works once, in one context, doesn't mean 
it's good code that should be liberally pasted. Or promoted as sample 
code. There is so much sample code out there, but the quality really 
varies. Bad sample code can hurt people.


So to all coders in general and Livecoders in particular - be careful 
what you paste. Have realistic expectations and a cautious approach. 
Take the time to understand the code you're working with and the LC 
keywords involved.


Good code has some extra qualities, such as: robust, efficient, modular, 
easy to maintain, and widely applicable. Bonus for heavily tested.


Likewise, copy/paste coding does not result in the same level of coding 
proficiency as fluency to think and write in the LC language. You have 
to exercise your LC-cep just like any other muscle.


(Here I would anticipate a smart aleck asking why don't I post all the 
perfect samples; there is always some pushback against both common sense 
and less-frequent posters on this list. But as usual, I've already 
answered that question before it was asked. Sorry coyote. Beep beep.)


Hope everyone is doing well!

Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.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: Encrypting Stack Breaks Field References

[Trevor DeVore via use-livecode]

On Tue, Dec 22, 2020 at 3:23 PM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> What he said. The promise of creating standalones and encrypted stacks
> containing code sounds promising, but there are caveats. It begs the
> question, how do we encrypt script only stacks or libraries? I don’t use
> encrypted stacks because my code is for internal use only, but if I ever
> went commercial, this would be something I would need.


It is possible to convert script only stacks to binary, encrypted stacks
and save them using the same file name. The Levure app packaging  scripts
will do this when you package up an app. So you get the benefit of script
only stacks during development and the protection of encrypted 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: Encrypting Stack Breaks Field References

[Bob Sneidar via use-livecode]

What he said. The promise of creating standalones and encrypted stacks 
containing code sounds promising, but there are caveats. It begs the question, 
how do we encrypt script only stacks or libraries? I don’t use encrypted stacks 
because my code is for internal use only, but if I ever went commercial, this 
would be something I would need. 

Bob S


> On Dec 13, 2020, at 4:02 PM, Richard Gaskin via use-livecode 
>  wrote:
> 
> Ron Noice wrote:
> 
> ? My program (built with LC 9.6.1 Indy Windows) contains a large number
> > of references to fields by variables.
> ...
> > only when I encrypt it does it fight back. Here's a simplified example
> > of what I'm doing:
> >
> > create group "grpTree"
> > ...
> > copy fld "baseBox" to grp "grpTree"
> 
> ^ that's your issue.
> 
> Copying objects is disallowed in an encrypted stack, since of course once an 
> object is copied it could be pasted into an unencrypted stack, and thus 
> expose the source.
> 
> You might consider moving the code from the encrypted stack to an encrypted 
> behavior object, leaving the stack where copying must be done unencrypted.
> 
> But if these objects are being copied only by script for the purpose of 
> automatically building out a UI, without a need to alter the user's 
> clipboard, you might consider using the clone command instead.
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web

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

Re: Encrypting Stack Breaks Field References

[Ron Noice via use-livecode]

Thanks everyone for your suggestions and help. I _guess_ I see the problem as 
creating fields inside an encrypted stack and referencing them to set 
properties, etc. So the new plan is to have an unencrypted stack in which I 
build the tree and connectors using code from the encrypted stack. This has 
turned into a mini-nightmare of its own -- but it keeps me off the street. 
Thanks.
... Ron
___
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: Encrypting Stack Breaks Field References

[Richard Gaskin via use-livecode]

Mark Waddingham wrote:

On 12/13/20 6:02 PM, Richard Gaskin via use-livecode wrote:
>>
>> Copying objects is disallowed in an encrypted stack, since of course
>> once an object is copied it could be pasted into an unencrypted
>> stack, and thus expose the source.
>
> Its not the copy that will be failing - but the create. In general you
> can't do anything to an encrypted stack which might cause a script to
> move from where its encrypted to somewhere else or vice-versa. (The
> reason create is disallowed is that you could create a new script via
> setting props of the template object).

Would the copy action not fall under the rubric of "anything to an 
encrypted stack which might cause a script to move from where its 
encrypted to somewhere else or vice-versa"?


If I receive a protected stack and copy an object out into an 
unprotected stack, I would then have access to the object's script.


--
 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: Encrypting Stack Breaks Field References

[Mark Waddingham via use-livecode]

On 2020-12-14 06:03, J. Landman Gay via use-livecode wrote:

On 12/13/20 6:02 PM, Richard Gaskin via use-livecode wrote:

Copying objects is disallowed in an encrypted stack, since of course 
once an object is copied it could be pasted into an unencrypted stack, 
and thus expose the source.


Except, copying via script using "copy x to y" doesn't involve the
clipboard. I think this could be categorized as a bug, the original
script should work.


Its not the copy that will be failing - but the create. In general you 
can't do anything to an encrypted stack which might cause a script to 
move from where its encrypted to somewhere else or vice-versa. (The 
reason create is disallowed is that you could create a new script via 
setting props of the template object).


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

Re: Encrypting Stack Breaks Field References

[J. Landman Gay via use-livecode]

On 12/13/20 6:02 PM, Richard Gaskin via use-livecode wrote:

Copying objects is disallowed in an encrypted stack, since of course once an object is copied 
it could be pasted into an unencrypted stack, and thus expose the source.


Except, copying via script using "copy x to y" doesn't involve the clipboard. I think this 
could be categorized as a bug, the original script should work.



--
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: Encrypting Stack Breaks Field References

[Peter Bogdanoff via use-livecode]

Hi Ron,

About ‘it’ — is that supposed to be the name of the new field or something 
else? You can always use “last” to refer to a new control, “the last field” is 
“any object whose number property is equal to the number of objects of that 
type." ‘It’ might have been changed to something else in the meantime…

Peter

> On Dec 13, 2020, at 12:15 PM, Ron Noice via use-livecode 
>  wrote:
> 
> My program (built with LC 9.6.1 Indy Windows) contains a large number of 
> references to fields by variables. For example, instead of refering to [fld 
> "abc"] I refer to [fld tName] where tName is a variable containing "abc" (no 
> quotes).
> 
> This has worked perfectly until I *encrypted* the stack (through the 
> standalone settings). The standalone itself works with no problem; only when 
> I encrypt it does it fight back. Here's a simplified example of what I'm 
> doing:
> 
> create group "grpTree"
> ...
> copy fld "baseBox" to grp "grpTree"
> set the name of it to tName
> set the visible of fld tName to true
> ...
> 
> This gives me a "no such object" error on the "set the visible" line. Through 
> testing, I've determined that
> - tName holds the correct value 
> - a field named with the value of tName has been correctly created
> - but it still seems to be the reference to [fld tName] that is the problem
> 
> This is about building family trees on-the-fly. The largest I've worked with 
> so far has over 450 boxes (fields) in the tree all with connecting lines and 
> all based on the ability to use variables to refer to the fields. At the 
> moment I'm just leaving the stack unencrypted. But inquiring minds would like 
> to know what the problem is. I know others have used this syntax for naming 
> and am sure some of them must have encrypted their stacks. Clearly I'm 
> missing something. 
> 
> Thanks for any brilliant suggestions you may have.
> 
> ... Ron
> ___
> 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: Encrypting Stack Breaks Field References

[Richard Gaskin via use-livecode]

Ron Noice wrote:

? My program (built with LC 9.6.1 Indy Windows) contains a large number
> of references to fields by variables.
...
> only when I encrypt it does it fight back. Here's a simplified example
> of what I'm doing:
>
> create group "grpTree"
> ...
> copy fld "baseBox" to grp "grpTree"

^ that's your issue.

Copying objects is disallowed in an encrypted stack, since of course 
once an object is copied it could be pasted into an unencrypted stack, 
and thus expose the source.


You might consider moving the code from the encrypted stack to an 
encrypted behavior object, leaving the stack where copying must be done 
unencrypted.


But if these objects are being copied only by script for the purpose of 
automatically building out a UI, without a need to alter the user's 
clipboard, you might consider using the clone command instead.


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

Encrypting Stack Breaks Field References

[Ron Noice via use-livecode]

My program (built with LC 9.6.1 Indy Windows) contains a large number of 
references to fields by variables. For example, instead of refering to [fld 
"abc"] I refer to [fld tName] where tName is a variable containing "abc" (no 
quotes).

This has worked perfectly until I *encrypted* the stack (through the standalone 
settings). The standalone itself works with no problem; only when I encrypt it 
does it fight back. Here's a simplified example of what I'm doing:

create group "grpTree"
...
copy fld "baseBox" to grp "grpTree"
set the name of it to tName
set the visible of fld tName to true
...

This gives me a "no such object" error on the "set the visible" line. Through 
testing, I've determined that
- tName holds the correct value 
- a field named with the value of tName has been correctly created
- but it still seems to be the reference to [fld tName] that is the problem

This is about building family trees on-the-fly. The largest I've worked with so 
far has over 450 boxes (fields) in the tree all with connecting lines and all 
based on the ability to use variables to refer to the fields. At the moment I'm 
just leaving the stack unencrypted. But inquiring minds would like to know what 
the problem is. I know others have used this syntax for naming and am sure some 
of them must have encrypted their stacks. Clearly I'm missing something. 

Thanks for any brilliant suggestions you may have.

... Ron
___
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