J. Landman Gay wrote:
> On 12/13/16 9:43 AM, Richard Gaskin wrote:
>> If a binary stack can be used from memory only, it should not be
>> necessary to write a script-only stack to disk.
>>
>> Such a requirement prevents us from using script-only stacks in
>> secure zero-footprint apps, such as th
On 12/13/16 9:43 AM, Richard Gaskin wrote:
If a binary stack can be used from memory only, it should not be
necessary to write a script-only stack to disk.
Such a requirement prevents us from using script-only stacks in secure
zero-footprint apps, such as those with the securityPermissions for
"
Ideally there would be nothing on disk,. But the, main goal was to keep all
my development and testing handlers out of the working stack. So writing
the stack to disk isn't horrible though it wasn't my original intention.
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive
J. Landman Gay wrote:
> On 12/12/16 11:08 PM, Mike Bonner wrote:
>> I haven't tried it but, perhaps you could-- put url "
>> https://www.domain.com/folder/stack.livecodescript"; into url
("binfile:" &
>> specialfolderpath("temp") & "/thestack.livecodescript"
>> Then start using it from there.
>
On 12/12/2016 09:39 PM, J. Landman Gay wrote:
On 12/12/16 11:08 PM, Mike Bonner wrote:
I haven't tried it but, perhaps you could-- put url "
https://www.domain.com/folder/stack.livecodescript"; into url
("binfile:" &
specialfolderpath("temp") & "/thestack.livecodescript"
Then start using it from
Still hope they fix it so the other way works, but any workaround in a
storm.
On Mon, Dec 12, 2016 at 10:39 PM, J. Landman Gay
wrote:
> On 12/12/16 11:08 PM, Mike Bonner wrote:
>
>> I haven't tried it but, perhaps you could-- put url "
>> https://www.domain.com/folder/stack.livecodescript"; into
On 12/12/16 11:08 PM, Mike Bonner wrote:
I haven't tried it but, perhaps you could-- put url "
https://www.domain.com/folder/stack.livecodescript"; into url ("binfile:" &
specialfolderpath("temp") & "/thestack.livecodescript"
Then start using it from there.
Hey, it works! Binary or script-only
I haven't tried it but, perhaps you could-- put url "
https://www.domain.com/folder/stack.livecodescript"; into url ("binfile:" &
specialfolderpath("temp") & "/thestack.livecodescript"
Then start using it from there.
On Mon, Dec 12, 2016 at 9:52 PM, J. Landman Gay
wrote:
> On 12/12/16 5:38 AM, p
On 12/12/16 5:38 AM, pink wrote:
Since "it" is the downloaded script, what if you tried this with a hidden
button:
get "https://www.domain.com/folder/stack.livecodescript";
set the script of button "hiddenGems" to it
insert the script of button "hiddenGems" into front
That would probably work
J. Landman Gay wrote:
> Correction: I have to "go" before I can "start using". Like Mike
> Bonner said. Hmph.
When I was first setting up my "streaming app" framework years ago I did
extensive testing with using a library downloaded from a server.
Ultimately the best I could come up with was
On 12/12/2016 03:38 AM, pink wrote:
Since "it" is the downloaded script, what if you tried this with a hidden
button:
get "https://www.domain.com/folder/stack.livecodescript";
set the script of button "hiddenGems" to it
insert the script of button "hiddenGems" into front
Heh. I need caffeine.
this message in context:
http://runtime-revolution.278305.n4.nabble.com/Start-using-remote-stack-tp4711000p4711013.html
Sent from the Revolution - User mailing list archive at Nabble.com.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visi
On 12/12/16 1:10 AM, J. Landman Gay wrote:
On 12/12/16 12:56 AM, J. Landman Gay wrote:
So I tried plain old "go stack url " and got "error in statement".
It's an https URL on Dropbox, and a script-only stack besides. Maybe one
of those things matters.
It looks like script-only stacks don't wor
On 12/12/16 12:56 AM, J. Landman Gay wrote:
So I tried plain old "go stack url " and got "error in statement".
It's an https URL on Dropbox, and a script-only stack besides. Maybe one
of those things matters.
It looks like script-only stacks don't work remotely. I made a new
binary stack and p
On 12/11/16 9:51 PM, Mark Wieder wrote:
On 12/11/2016 12:55 PM, J. Landman Gay wrote:
I have a script-only stack on a server I want to use as a library. The
handler does this:
get "https://www.domain.com/folder/stack.livecodescript";
start using stack it
The text file comes in fine and the tex
On 12/11/2016 12:55 PM, J. Landman Gay wrote:
I have a script-only stack on a server I want to use as a library. The
handler does this:
get "https://www.domain.com/folder/stack.livecodescript";
start using stack it
The text file comes in fine and the text content is in the "it"
variable. When t
oh DOH. Yep I see what you did there.
I can't get it to work here either, but if you go to the stack invisible,
THAT works. Then you can start using it. Does seem like it should work.
On Sun, Dec 11, 2016 at 3:29 PM, J. Landman Gay
wrote:
> The handler is doing basically the same thing, I ju
The handler is doing basically the same thing, I just put the string
into a variable first. But originally I used your method and got the
same error.
I also tried:
put url "https:blah blah" into tFile
start using stack tFile
Same error.
On 12/11/16 3:09 PM, Mike Bonner wrote:
By using get i
By using get its just text in the it variable. I wonder if you can-- start
using stack URL "https://youraddress.com/folder/stack.livecodescript";
(just like go, but start using instead)
On Sun, Dec 11, 2016 at 1:55 PM, J. Landman Gay
wrote:
> I have a script-only stack on a server I want to us
I have a script-only stack on a server I want to use as a library. The
handler does this:
get "https://www.domain.com/folder/stack.livecodescript";
start using stack it
The text file comes in fine and the text content is in the "it"
variable. When the "start using" line executes, I get the err
ays looks like a new hit due to the #1235124561 (At
> least I think it works with just a figmentary anchor)
> On Sat, Nov 8, 2014 at 12:17 PM, J. Landman Gay
> wrote:
>> On 11/8/2014, 8:31 AM, Ethan Lish wrote:
>>
>>> How can one control the cache or force the relo
. Landman Gay
wrote:
> On 11/8/2014, 8:31 AM, Ethan Lish wrote:
>
>> How can one control the cache or force the reload of a remote stack?
>>
>> Using the algorithm defined in this lesson
>> http://lessons.runrev.com/m/4071/l/78702-opening-a-stack-from-the-server
On 11/8/2014, 8:31 AM, Ethan Lish wrote:
How can one control the cache or force the reload of a remote stack?
Using the algorithm defined in this lesson
http://lessons.runrev.com/m/4071/l/78702-opening-a-stack-from-the-server
When the client is restarted it does not reload the changed stack
How can one control the cache or force the reload of a remote stack?
Using the algorithm defined in this lesson
http://lessons.runrev.com/m/4071/l/78702-opening-a-stack-from-the-server
When the client is restarted it does not reload the changed stack from the
server
E
—
Ethan
Swami,
Are they saved in legacy format?
What is the version of the engine that is trying to open them?
Om
andre
On Tue, Mar 15, 2011 at 8:03 AM, Sivakatirswami wrote:
> In house I serve a lot of stacks from our big XServer on the LAN.
>
> I issue small players to desktops and then call the a
Looks like the previously announced file format change has failed it's
backward-compatibility test. Something about this was in the latest beta
notes.
This appears to be an item that should be discussed on the Improve list and
the team should know about this asap.
This is why "they" tell us that
In house I serve a lot of stacks from our big XServer on the LAN.
I issue small players to desktops and then call the actual apps for
production with
I recently updated a stack with Livecode 4.6 dp7; put it back on the
server and then call it as usual:
on mouseUp
go stack url "http://v
27 matches
Mail list logo
