Computer Science Canada :: View topic

import GUI
const Port : int := 5055
var choice : int
var Done : int := 0
var ChatBox : int
var ChatEnter : int
View.Set ("graphics:max;max,nobuttonbar")

/*loop
put "Enter 1 to run server"
put "Enter 2 to join server"
put "Choice: " ..
get choice
exit when choice = 1 or choice = 2
end loop
var netStream : int
var netAddress : string

if choice = 1 then
put Net.LocalAddress
netStream := Net.WaitForConnection (Port, netAddress)

else
put "Enter the address to connect to: " ..
get netAddress
netStream := Net.OpenConnection (netAddress, Port)
if netStream <= 0 then
put "Unable to connect to ", netAddress
return
end if
end if
Draw.Cls*/

procedure ChatEntered (text : string)
GUI.AddLine (ChatBox, "Me: " + GUI.GetText (ChatEnter))
%put : netStream, GUI.GetText (ChatEnter)
GUI.SetText (ChatEnter, "")
GUI.SetSelection (ChatEnter, 0, 0)
GUI.SetActive (ChatEnter)
end ChatEntered

%process Chat
% loop
% if Net.LineAvailable (netStream) then
% var line : string
% get : netStream, line : *
% GUI.AddLine (ChatBox, "Enemy:" + line)
% end if
% end loop
%end Chat

%fork Chat

ChatBox := GUI.CreateTextBox (10, 25, 400, 200)
ChatEnter := GUI.CreateTextField (10, 5, 400, "", ChatEntered)

loop
exit when GUI.ProcessEvent
end loop

Author:	DemonWasp [ Mon Dec 01, 2014 10:31 pm ]
Post subject:	RE:Turing Chat Program
This one is kind of interesting. I found that if you remove the text box entirely (comment out its creation) then your program 'works' -- in that it doesn't immediately crash. I didn't test the rest of the program. I used Turing 4.10 for this investigation (it says Turing 4.1 in the help window). As far as I can tell, you're running into a bug in Turing's implementation of text fields. The technical description is: the TextBox class (in TextBoxClass.tu) fails to implement ConsiderKeystroke(ch : char). Other classes, like TextField, implement that method just fine. That means that when you press a key, Turing goes through all of the widgets and asks them if they want that keystroke or not -- if they do, then they get asked to process it; if not, then it gets offered to the next widget in sequence. As an interesting consequence of that implementation, you can work around this bug by making sure you create the text field last. If you just reverse the order of initialization, I think your program works fine. This programming practice isn't great, because it's a silly workaround to an underlying problem, but it's also (unfortunately) not likely to ever be fixed. As a side note, it is curious that Turing lets you declare a deferred procedure and then not implement it.