LC Server & Server Based Stack?
bonnmike at gmail.com
Sat Jan 21 12:10:30 EST 2017
Yeah, thats what I'm saying. Think of it this way. If you make 2
standalones, run both, and have 1 standalone try to put text into a field
of the other, it won't work because they are each running their own engine
instance. If one engine instance opens several stacks they're able to talk
because its all through one instance of the engine, and they're all
interconnected through the engine.
Lc server is an instance, and the standalone, or ide that has your open
stack is an instance. So there is no direct connection between the 2. It
would be like opening the same text file twice in 2 separate text editors.
If you type in 1, the change doesn't appear in the other. You'd have to
type in 1, save the changes then reload the text in the other to see the
changes that were made.
If using a file to update will work, it should be simple enough.. (and not
require stacks on the server side.) Have the server write the necessary
info, and have an update button on your stack that will grab the new info,
or have the stack keep checking for changes every so often, and update as
As far as sockets, chatrev is a pretty awesome example. If you click
"resources" in the main toolbar, then select "sample projects" on the lower
left, there is an "internet chat" that you can poke around with to get a
handle on things.
If you decide to go the socket way and the cgi (non lc server) method, i'll
be little help. I'm not even sure which versions of the lc engine will
work for this, but you said you already looked at jacques page, so are on
the right track.
I have mentioned it before, but there is the revhttpd stack.. If you don't
need multithreading, it would make a great starting base. (and another way
to explore sockets too) I love the thing, especially the ability to add
commands to the stack that are then callable using a get request of the
On Sat, Jan 21, 2017 at 8:47 AM, Rick Harrison via use-livecode <
use-livecode at lists.runrev.com> wrote:
> Hi Mike,
> This seems a little crazy to me.
> I can have two stacks open in memory in LiveCode, and I
> can send a message such as “mouseUp” from one stack
> to a button in the other stack. The button in the other stack
> outputs some messages to the message box and puts a
> message in a field on that stack and that all works just fine.
> I’m able to view both stacks on the screen at the same time.
> (This is as it should be.)
> I send the same message from the server to the button
> and the messages which normally go into the message box
> end up in the display of my browser which seems a little strange but Ok
> I can accept that. The other message which was supposed to
> go into the field never gets to the field which makes it look
> like the button ignored that statement completely although
> it executed everything else it was asked to perform. That
> message doesn’t seem to go anywhere as it doesn’t even
> end up being displayed in the browser and ends up in the
> bit bucket in the sky. (Again, I can see the open stack
> on the screen at the time that I tell my browser to execute
> the server code.) Shouldn’t a message be a valid message
> no matter where it comes from? (Hence my crazy feeling
> about the whole thing.)
> So you are telling me that I can send a message to closed
> stack to modify it, that I should save it after the change, and
> then reopen the stack to view the change - yes?
> The file communication idea makes things a little more
> complex but is certainly doable.
> I’ve never done anything with sockets - are there any good
> examples out there you can point me to for this?
> > On Jan 20, 2017, at 10:20 PM, Mike Bonner via use-livecode <
> use-livecode at lists.runrev.com> wrote:
> > You can modify a stack using lc server, and save it, but that won't
> > an already open stack in memory. And if you don't add code to save the
> > stack from lc server, even if you do reload the stack, the change won't
> > there.
> > One way to update a field in an open stack would be to have the stack
> > running a send in time loop that checks for changes to a file. (text
> > or whatever) If the last modified stamp has changed (or if the file
> > exists, or however you want to do it) read and parse the file, to get
> > info and put it wherever it goes then clear or delete the file. You'd
> > still have to think about concurrency issues, but it should work.
> > the jacque standalone cgi method (as I mentioned in a different email)
> > would be cool because you could hit the webserver, open a socket to your
> > open stack to pass data from the server to the running stack.
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
More information about the Use-livecode