Using Standalones vs Stacks.

[jsburnett]

Preview: Using Standalones vs Stacks.
Hi,
I am having problems with stack/standalone behaviours (if that is the correct term).
I have 2 stacks that 'interact' with each other.
Basically there are 5 buttons on each stack. All start with backGroundColor 'Green'. A mouseUp message in a button changes that button to "Red" and the same, corresponding button on the other stack to "Red" ( i.e., button 1 of stack "a" turns 'red' and button 1 of stack "b" turns 'red').
The buttons work great as stacks.
However when change them to standalones or even use a splash stack to open them the buttons don't interact.

I've done some investigating and:
I am using : set the backgroundcolor of button "Room 1" of stack "b" to "green"
If I open one stack as a stack and the other as a standalone or with a splash stack, I get :
button "Room 1": execution error at line 14 (Chunk: can't find stack), char 37

So I am not sure if using 'Stack "b"' is correct when it is a standalone or opened with a splash stack.

Any ideas? Need more information?

Thanks in advance.
John

[dunbarx]

Hi.

Are you sure that when you made the standalone, both stacks were included in the "stacks in the selected stackfile" field of the "stacks" pane? Remember that a file contains one or more stacks, so that you should have a minimum of three (including the splash).

I came from a background where the stack WAS the file. This is no longer the case.

Craig Newman

[sturgis]

Seems like if both stacks are opened by the same splashstack they're then running in the same enginespace (made up a word!) so things should work fine. 2 separate standalones this would not be the case and you'd have to work otu some other method for them to communciate (such as send to program on mac, or using sockets)

The splashstack method should work though, or even having 1 stack be the master that opens the other stack as a simple stackfile then we're back to being in the same enginespace so it should be possible to set and get properties or whatever across stacks.

The main thing here though is making sure they are both running under the same engine, if not they can't talk to each other.

It works in the IDE because the same engine behind the IDE handles the stack interactions.

[jsburnett]

Thanks for the replies!
Not the answers I was hoping for, but I will try a different approach.
Yes, I wanted 2 seperate standalones.
I really don't know much about sockets. Is this a hard topic to tackle? I am true an amateur (my day job is a family physician).
Thanks again.
John

[sturgis]

Not nearly so hard to handle sockets as you might think. \

If you click the "resources" button on the tool bar it'll open up a screen. On the left open "sample projects"

Then grab the internet chat application. Its pretty straightforward how things work, plus if you read in the dictionary you can learn about named sockets, etc and get more useful info to help fill out what you learn from the sample stack.

Specifically look at open socket, close socket, the opensockets, socketclosed, write to socket, read from socket, the various error messages related to sockets, accept connections.. Etc.

If _I_ can get a simple socket based application working (from scratch) anyone can.

[jsburnett]

sturgis,

Thanks for the encouragment. I will try to tackle it.
I've been looking on examples from BYU (http://livecode.byu.edu/internet/...socketClient.rev and socketClient.rev).

On the 'Simplest Socket Client' , the connect button uses 'localHost:8080' where localHost, I believe is the IP address of the 'Server" and 8080 is the port on the 'Server'. Is this true? I tried putting in the local IP address of my computer where the server and client were 'running' and it did not 'connect' - although what really happenned is that there was no communication between the stacks.

Is there a basic explanation somewhere? I tried reviewing the lesson "How to communicate withother applications using sockets" and this seemed to generate more questions than answers.

John

[sturgis]

Yep, localhost stands for 127.0.0.1 which is the loopback interface (a dummy network interface that talks to itself)

You could put in the actual address and it "should" work. I have it running here, client and server on both machines.


When you click and start the server does it seem to work?

In the message box if you "put the opensockets" does it show anything?
If it does that most likely means the accept worked and its listening for connections.

Just found a small bug that occurs when disconnecting. The server keeps an array of connected "chatters" and when there is a disconnect it removes the entry for that chatter. The line needs to be changed from:

Code: Select all

deletelChatterArray[s]

to:

Code: Select all

delete local lChatterArray[s]

Ok, so if the server is listening and there is an opensocket, try to connect to the server.

Does it think it connects? Is there a message logged in the server box? Should say "username connected."

If not, but the server did show that it was listening I suspect a firewall is in the way. You might turn it off for a few seconds and see if you can connect to eliminate it as a possibility. Might also add some answer dialogs at strategic locations in the client script to see if there are any errors occurring.

My gut feeling though, since it works so well out of the box here for me (other than the small bug I noted above), firewall is the most likely issue.

[jsburnett]

Thanks again for the tips.

I was able to save the stacks as standalones in seperate files, put clients files (now standalones) on 2 seperate computers and 1 server file on 1 computer and was able 'to chat'. Very interesting!

I will have to 'read' through the scripts careful, and experiment with them to learn how to adapt this to my current project.

I really appreciate your feed back.

Give me a few days, as I said, sometimes my day job keeps my from my hobbie.

John

[jsburnett]

Here is a question regarding sockets.

The following code which is triggered by the mouse to accept connections, and then 'triggered' again after a connection is made, seems to me, in the newMessage handler it should 'call' itself again - see below please. Also see question about 2 read commands.

on mouseUp
accept connections on port 8080 with message "someoneConnected"
end mouseUp

on someoneConnected theIP
read from socket theIP until return with message "newMessage"
end someoneConnected

on newMessage theIp theMessage
put theIP & ":" && theMessage & return after field "text"
read from socket theIP until return with message "newMessage" -- why is the read command needed here, since the read command already passed the variable theMessage in the someoneConnected handler. Whys doesn't this trigger the newMessage handler again? Does this have to do with 'blocking' and 'nonblocking' read commands?
end newMessage

Thanks,

John

[sturgis]

ChatConnected is for the initial connection between the 2 systems. If you look at the code in the simple chat stacks it reads from socket s for 1 line. This line contains the connection info into the chat array variable so that the server can keep track of who is connected from where.

It then broadcasts the info (username has connected blah blah blah) to everyone in the chat array by cycling through each entry and sending to the port that was negotiated on initial connection.

It then initiates a read from the port in question pulling any data that is sitting there waiting and use "chatMessage" to process it. chatmessage is the standard distribution handler while chatConnected just does the initial set up and tracking of the socket information for that connection.

Then looking at the chatmessage handler from the simple chat script..

it is passed the port (s) and the data that they sent (data)
It logs to the server (put data & return after field serverstatus)
it broadcasts the new message to all the connected clients

then it initiates a new read waiting for new data to come in, and referencing itself to handle a message when it appears.

all broadcastclients does is take the passed message and loop through the connected clients writing the newest message out to them.

So in effect, each system that connects hits "chatConnected" 1 time and then a simple form of read loop is initiated for that client/socket that runs into perpetuity or until disconnect.

EDIT:
It is likely that you can simplify things a little if you only have direct single machine to single machine connections. (or same machine connections) but will still need read loops running to "catch" any incoming messages.

[jsburnett]

Stugis,
Thanks for your reply,

I have been busy with my 'day job' but have been reading the dictonary, reviewing the lessons and 'playing' with the chat scripts (all with regards to how to use sockets and share information between 2 or more networked computers). Now it is starting to make a little sense to me.

In a way the handlers do 'call' themselvse with the read command and a call back message, but only after new data is 'read'. (I have been busy examining and experimenting with the chat scripts so as to actually try to learn and understand each statement.)

This is really interesting! I am even learning how to 'debug' scripts and place pauses in the script to 'watch' how each step affects the behavior of the handler.

Now I am trying to figure how to check when the 'connection' is lost... ie, how to handle error messages (pun intended).

Still working on my scripts, thanks for the encouragment.

John