Actually, I think the opposite is true: If the callback script is NOT in the button script, it won't ever fire. At least that's the way I read the docs.
As to changing the port #, that's out of the question since it is a "well known" port (502 is MODBUS/TCP) and the serial <-> Ethernet box will only talk on this port. This however is not the problem since I'm on a local private network so the ISP never sees any of the data. However, I (reluctantly) have good news to report. The kind that just makes you feel stupid: The problem I was having was because my computer (the one I'm trying to talk to the MODBUS box with) uses DHCP to get it's address. The S<->E box needs to have the IP address that it's talking to programmed into it. It was yesterday and I've always gotten the same IP address on my computer for months. Well, last night we had a little lightning storm and lost power so when I logged in this morning, I got a brand new (and different) IP address so my S<->E box was talking to a computer that wasn't even there any more. Once I figured that out, things started working just the way they were supposed to. :-) Thanks for everyones' comments on this! len > Another thought... your "connected" handler is in your stack script and > not your button script, right? If it's in the button script, it'll never > be executed. > > Phil Davis > > > > [email protected] wrote: >> I tried with port 80 and got the same result. In other words, my >> "connected" routine never gets called. >> >> >>> Len Morgan wrote: >>> >>>> I'm trying to create a listening socket and something is not quite >>>> right. I've created a button: >>>> >>>> on mouseUp >>>> accept connections on port 502 with message "connected" >>>> end mouseUp >>>> >>>> on connect s >>>> put "Connect to" && s after fld "test" >>>> read from socket s for 1 line >>>> put lne 1 of it after fld "test" >>>> end connect >>>> >>>> The problem is I'm never getting the "connect" message. Have I missed >>>> something? I have firewall turned off so it's not getting blocked >>>> (I'm pretty sure). >>>> >>>> len >>>> >>> If you have any doubt about port 502 being blocked, try testing it with >>> a more common port number, like 80 or 8080. Just a thought - >>> >>> Phil Davis > _______________________________________________ > use-revolution mailing list > [email protected] > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution > _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
