France,
Toulouse,
Wednesday, May, 3rd, 2006,
4:07 pm.
Hi Jeff,
About the REALbasic Spirit:
I agree with you that a new mind is required in REALbasic programming.
But it's not specific to REALbasic. It's the same for any other Object
Oriented Programming language like Java, Objective-C and so on.
The only difference between REALbasic and other OOP language is that
REALbasic make learning easier.
So your effort investment in REALbasic will never be lost.
About the ServerSocket class:
Why to create your own TCPSocket in the Project Window instead of
instantiate it in your own window and bind it with a dragged and dropped
ServerSocket instance of this window ?
For a better understanding, I would prefer to tell you the following
metaphor.
Think of ServerSocket as a monster who swallows TCPSocket instances
(instances = objects = clones = New ...) for its future needs.
Once the monster (the ServerSocket) has swallowed the TCPSocket objects, you
have no longer full access to them from outside. Of course, there is the
array of TCPSockets returned by the ServerSocket's method called
"ActiveConnections" that allows you to get informed about all TCPSocket in
use. But that's all and it's very restricted. I means you cannot implement
some code in their events. You cannot access unsused TCPSocket and so on.
Note:
The mouth of the monster is "AddSocket".
So, the idea is to prepare them by creating your own class of TCPSocket
before to send instances of your own TCPSocket class to the ServerSocket
object. This way, you implement some code in the TCPSocket's event handlers
before these TCPSocket objects being swallowed by the ServerSocket object.
Another metaphor consists to think of your TCPSocket objects swallowed by
the monster as probes. Before to send these probes for inspecting the core
of the monster, you have to make them as autonomous as possible. For that,
your TCPSocket objects have to take on board a maximum of code.
If you send your TCPSocket without code implemented by the event handlers,
it's too late. They will be lifeless.
So, here is the design:
- prepare your TCPSocket objects by creating a subclass of TCPSocket.
- open the editor window of this subclass for writing your code. This
code must handle every kind of situation that could meet TCPSocket objects
(HTTP request, or specific commands, file transfert, chatting, and so on).
- drag and drop a ServerSocket on a window.
- double-click on it to open its code editor.
- add some code in the "AddSocket" event handler (to feed the monster
with your succulent TCPSocket instances).
- drag and drop a PushButton on the window.
- double-click on this PushButton to open its code editor.
- add the code that launches the server (the "Listen" method) in the
"Action" event handler.
Run your application.
There is a feature request underlying this subject.
A kind of ServerSocket Editor.
When you double-click a window class in the Project Editor (the project
tab), you usually open a Window Editor.
Why not a ServerSocket Editor ?
Or even better, bindings between ServerSocket, TCPSocket and any other
control object (to monitor the server). The bind between ServerSocket and
TCPSocket both dragged and dropped on a window would be a way to tell
ServerSocket the kind of TCPSocket to implement and duplicate.
Monitoring connections:
Since you have to create your own TCPSocket, everything become possible,
especially connection monitoring.
In the Project Editor (the project tab), create a new class called
"MyOwnTCPSocket".
Double-Click on it to open its Code Editor.
Then create two private properties with the following definition:
MyOwnTCPSocket
theID As Integer
theListBox As ListBox
The purpose of the "theID" property is to uniquely identify the TCPSocket
object. It's a good habit to associate un unique number to every TCPSocket.
"theListBox" point to a displayer. This displayer will receive messages
(reports) from the TCPSocket. The ListBox is responsible in the way the
report will be displayed.
To "MyTCPSocket", add two public methods colled:
MyOwnTCPSocket
SetID( anID As Integer )
SetListBox( aListBox As ListBox )
Where "SetID" implements the following code:
Me.theID = anID
And "SetListBox" implements:
Me.theListBox = aListBox
The purpose of these method is to specify to the TCPSocket object the value
of its ID and which control display its messages.
In the "Connected" event handler, WRITE THE FOLLWOING CODE:
Me.theListBox.Report( Me.theID, "I'm connected !" )
You could implement such code for other event handlers of the MyOwnTCPSocket
class.
In the Project Editor, create a new ListBox class with the additional
method:
MyListBox
Report( anTCPSocketID As Integer, aReport As String )
The purpose of this method is to display the current status of a connected
TCPSocket identied by ID (it is hosted by the ServerSocket).
I let you write the right code.
For example, use the ListBox's "AddRow" method to create a new row and store
the message with the ID of the TCPSocket (and why not the current time).
Or even better, divide the ListBox into two columns labeled "ID" and
"Status". So, there is one row by TCPSocket. Update the row associated to
the TCPSocket reporting its status (look for the right ID in the "ID"
column).
In the main window (usually Window1), drag and drop a MyListBox object and a
ServerSocket object.
Double-click on the window to open its Code Editor.
Create a private property as follow:
Window1
thePreviousID As Integer
In the "AddSocket" event handler of the ServerSocket, write the following
code:
Dim aTCPSocket As MyOwnTCPSocket
aTCPSocket = New MyOwnTCPSocket
Me.previousID = Me.previousID + 1
aTCPSocket.SetID( Me.previousID )
aTCPSocket.SetListBox( Self.ListBoxReport )
Return aTCPSocket
Then run you application.
The content of the ListBox should be updated from time to time: when a
TCPSocket is connected, receive data, send data, and so on.
Note:
It's a better habit to embed the "previousID" into the ServerSocket.
Hence, you are obliged to create your own ServerSocket in the Project
Editor.
So, here a fundamental reason why you are finally almost obliged to create
your own ServerSocket class. You can not associate a property to an object
dragged and dropped into a window.
I recommend you to test the projects located in the "Networking" folder of
the "Example Projects" folder you can download from the REAL Software's Web
site. Especially:
ServerSocketServerTest.rbp
ServerSocketClientTest.rbp
In my opinion, there are the best "first contact" in Networking.
I wrote this long email as fast and accurate as possible, so sorry if there
is some lack of explanation or misspelling.
Anyway, I hope it will help you and let me know if you have questions.
Have a goode day,
Nils
----
Le 3/05/06 4:49, « [NOM] » <[ADRESSE]> a écrit :
> Thanks Brian,
>
> What is the difference between dragging a TCPSocket to the window or
> dragging a subclass of it?
>
> Ideally I am wanting to create a list showing the connection status,
> remote ip and bytes left to send for each of the tcpsockets created
> by the pool. I am stuck a little on the concept of an array of
> tcpsockets and how to use this.
>
> I love RB object style, but coming from 4D it is a bit of a change.
>
> Jeff
>
>
> On 03/05/2006, at 10:37 AM, Brian Rathbone wrote:
>
>>
>> Jeff Edwards wrote:
>>
>>> The documentation I find on the web is for rb5.5 and it says that
>>> I have to subclass the serversocket and the tcpsockets in order
>>> to use the events.
>>>
>>> I am using rb6r2 professional and see the events in these classes
>>> and am wondering why they cannot be used directly.
>>>
>>> The other question is: How do I use the events in a tcpsocket
>>> from the bank of tcpsockets that the serversocket creates.
>>>
>>> I understand that in the 'add socket' event of the serversocket
>>> object, I need to put 'return new TCPSocket'
>>>
>>> but . . I am unsure of how to use the events of the tcpsockets
>>> created. Am I meant to drag the tcpsocket class to the window so
>>> I can see the events (so I can put my methods in the respective
>>> events) or is there another more accurate way that will work.
>>
>>
>> You need to create a custom subclass of tcpsocket (new class then
>> set super to tcpsocket) and in the addsocket event of the server
>> socket return your custom subclass instead of just plain old
>> tcpsockets. Then you can implement the tcpsocket events in your
>> custom subclass.
>>
>> hth,
>>
>> Brian
----
Nils Frisch
http://www.nils-frisch.com/
Toulouse,
France.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
