I was reading abou tthat yes. But It seems that I cannot change teh fill color of the square. I know tha tthe events are hitting and I put your example code in teh spots you called out. But its not changing anything. Is there a watch window in debugging that I can see the boolean ‘Connected’ staes?
JIm
the fill color is from the code I just posted
it examines the boolean property that we added to the windows called CONNECTED
that variable is set to TRUE in the TCPSocket1.Connected event when the socket connects
and that variable is set to false in the TCPSocket1.Error event when the socket disconnects or there is some other error
you can put a break statement or set a break point on ay line of code and then poke through the various properties etc for the window and the controls
when in an event that is =art of a control you should see there is a property called “Window” and if you click the blue link it will let you examine the Window and its properties which is where CONNECTED is
I understand the concept, and stepping through it seems to follow your explanation. But when It get to this part:
[code]if self.Connected then
g.DrawingColor = &c00FF00 // depending on what version youre using this may need to be g.drawingcolor
else
g.DrawingColor = &cFF0000 // depending on what version youre using this may need to be g.drawingcolor
end if
g.fillrect 0,0,g.width, g.height[/code]
I can see the app making the decision, but when it hits teh ‘g.fillrect’ line the canvas color does not change from red to green.
Interesting…
If I set a breakpoint at the spot in the TCPsocket connected event fires setting the CONNECTED boolean, and single step through the rectangle flips from red to green.
If I do the same for when the TCPSocket disconnects and single step it changes back to red.
SO the boolean DOES set TRUE or FALSE, and teh IF/THEN also determines correctly. But it cannot do it with out setting a breakpoint(s) and single stepping…
…why? Hmmm
I am going to have to walk away from this for tonight. I cannot get that bloody square to change color for the life of me
EDIT:
If it matters, I am using Version 2019 release 3.1
in the in TCPSOCKET1 CONNECTED and ERROR events add
canvas1.invalidatethis will get the canvas to redraw
basically the boolean gets changed but there’s no reason for the canvas to be redrawn
this gives it one 
YIPPEEE!!! That works! Thank you!
But why does this need to be done? I would think that as a control it would have a priority.
Ok, Theres one final issue to resolve and I think we are good to go and can call this issue resolved.
Issue is I would like to print the error codes(good, bad, or ugly) in a text window. I have set up the text field calling it ‘ErrorArea’,
And I have the following lines in my ERROR handler:
MessageBox(err.Message + err.ErrorNumber.ToString) //this works, but only if I disconnect the Cat5 line
ErrorArea.AddText(err.ErrorNumber.ToString) //does not work. nothing on error output window
I would like to see ALL the errors, in the text field as opposed to the MessageBox Pop up.
Time for more experimenting
EDIT:
I have also noticed that the Error pop Up does not always show up either. I am guessing there must be an error in the setup somewhere.
[quote=485687:@Jim Marquardt]YIPPEEE!!! That works! Thank you!
[/quote]
welcome
Things only redraw when they have reason to
A button redraws if you change the caption etc
We changed nothing about the canvas - so it had no reason to redraw
yeah dont use a msgbox 
they tend to screw up flow of events and focus and so many other things
in this case the text will be added AFTER you respond to the msgbox dialog which is modal
And, that may not redraw the text area immediately because the msgbox is modal
With TCP some things take a while for some errors to be noticed
For instance it can be that the other end has dropped or closed the connection BUT that wont immediately generate an error until you try to send to it and you may get a send timeout or some other error
Some, like pulling the ethernet cable, do generate an error much more quickly
Thats just the nature of TCP/IP
Its not a constantly checked connection and so you have to be prepared to handle that situation
Ok, some more progress. I can get teh test Field to now output an error code by using this:
ErrorArea.AddText(str(Me.LastErrorCode))ALthough it does not refresh teh text field, just adds on, but I think I know how to fix this.
What is rather puzzling is why the error handler is not firing consistently, if at all.
I have noticed two instances where this occurs.
If I disconnect the cat5 connection and try to connect to the device, it takes a good two minutes or more to spit up Error 103, which is that XOJO cannot resolve the address…which makes sense since the device with that address is not there. But why is it taking so long?
The second situation is when I have established a connection, but while the connection is active I pull teh Cat5 connection from teh device. Most of the time I get no error indication at all.
I am stumped at both scenarios
JIm
EDIT:
I see Norman posted while I was typing.
I removed the Message Box, but I would like to see the error codes on fault to appear in the text field. Especially the one for unable to resolve (103) and loss of connection(102) both of which are very important to me.
If that code is in the error event of TCPSocket1 they probably are being added its just not scrolling the text area so you see them
At least thats my suspicion of whats occurring
And note there ARE other events that may be happening - we just havent put any code in them to handle anything
You might want to change the error event handler to
ErrorArea.AddText err.ErrorNumber.ToStringSince in 2019r3.1 Xojo altered the error event and it gets passed in an exception that is all filled out
[quote=485704:@Norman Palardy]You might want to change the error event handler to
ErrorArea.AddText err.ErrorNumber.ToString
Since in 2019r3.1 Xojo altered the error event and it gets passed in an exception that is all filled out[/quote]
I actually saw that and did try it, but I get two errors:
[quote]MainWindow.TCPSocket1.Connected, line 3
This item does not exist
ErrorArea.AddText err.ErrorNumber.ToString
[/quote]
And:
[quote]MainWindow.TCPSocket1.Connected, line 3
Type “Int32” has no member named “ErrorNumber”
ErrorArea.AddText err.ErrorNumber.ToString
[/quote]
one sec
let me fire up 2019r3.1 and check wtf is wrong
in the first error what is highlighted in the error list ?
EDIT : seems to work here. try this
I will take your example for a ride and get back to you asap.
How does one upload a project? like you did?
So, I set up your test program. Changed teh IP and port to my device and hit the button. I received teh CONNECTING/CONNECTED Messages, but when I pulled teh cable and walked away for ten minutes…When I returned there was nothing reported for teh error.
Now when I clicked teh button to disconnect I received a 103 error in teh screen.
This sort of tells me that the Error reporting feature of the TCPSocket does not work as advertised maybe?
JIm
I have a server where I can put them then post a link
Some folks put them on dropbox etc
[quote=485721:@Norman Palardy]I have a server where I can put them then post a link
Some folks put them on dropbox etc[/quote]
Ahhh… I see.
EDIT:
My apologies for mis-spelling ‘THE’ I have been doing this for years and no one knows why. I usually correct this but sometimes I brain fart. Much of the typos are my fingers moving too fast and I do not press the key(s) completely.
Pulling a cable does NOT inherently cause any change in anTCP/ IP socket
You have to be actively talking to the other end to notice such a thing as the SENDING will fail
This is what I meant earlier - TCP/IP is NOT “active” and constantly testing the connection to the other end
Its mostly passive and you get errors when you try to use it and something has gone wrong
Some protocols are chatty like this to constantly know if/when the other end is present or missing
But thats a function of the protocol NOT TCP/IP
AHHH!!! Learn something new. Will have to test that out and report back.
One thing I am futzing with here is the textfield where the errors are reported. Every time an error does appear, its always appended to the last error. The next error does not write over the previous one. I have been trying REFRESH, INVALIDATE etc. But no luck. I t always writes the new text after the last text.
thats what addtext is supposed to do
thats documented in the references
if you just want to replace the entire text that is in there just set the Value property
ErrorArea.Text = err.ErrorNumber.ToStringAnd it does do this. BUT it does not overwrite what is previously written.
For Example:
I start my application, and when I connect in my errorarea I see a ‘0’, which is correct.
I click Disconnect, and then I click Connect, and in the errorarea I see the original ‘0’, and a new ‘0’ to the right of it.
If I get an error, I will also see it after the ‘0’ as well.
The issue is that the text field is not going back to the original starting point, but instead it is just moving right.