First off, before you start saying chat bots are no longer used blah blah blah. This is just to show someone, wether they are making a binary bot or a chatbot, some basic oop techniques on how to manage things. This is a collection of class modules (yes, an oop designed way of handling events!) that will take the raw data you recieve, do some work on it, then raise the appropriate event and pass an object that contains all the information (already parsed inside properties) to the event.

Download Here: http://www27.brinkster.com/wsckvbupdates/default.html

Here is an example using the Event Handler in a "contained enviornment", meaning its not on battle.net and I pass a string in that would be exactly like something you would receive from battle.net.

[code]
Private WithEvents EventHandler As CEventHandler

Private Sub Form_Load()
Set EventHandler = New CEventHandler
EventHandler.DispatchEvent ("1002 JOIN Dword 0010 [D2XP]")
End Sub

Private Sub EventHandler_OnJoin(ByVal EventJoin As CEventJoin)
Debug.Print EventJoin.EventUser & " has joined the channel as " & EventJoin.EventClient & " (" & EventJoin.EventFlags & ")"
End Sub
[/code]

This may not be done the best way, but it sure as hell is better than spaghetti code and probably better than some other implementations using OOP!

Common guys tell me what you think, whats good, whats bad, and whats ugly? (Seems to have a problem with people compulsively not posting and has to request it! :D)

i dont know about people starting off in programming, but i always go with event handlers when parsing battle.net events.

MesiaH, did you actually download the project and look at it? If not I recommend doing so, for everyone, much more than what you see in the code example.

Looks good.

Should use callbyname for dispatching the messages to event handlers, could cut down on code a lot by doing that.

zorm, it wouldn't make too much of a difference if I hardcode them or not. It might cut down on the code, but I don't think it would speed it up at all, it would probably slow it down. I say this without actual evidence, however, CallByName determines the name at runtime, so i'm sure there is some overhead there. The only benefit _might_ be readability, be even that doesn't help too much.

BTW This is part of a package that will eventually be combined into a full working bot. Stay tuned in because I will be releasing other parts of the bot as time goes by!

ph34r, i am writing a chatbot as well.
chat4life kthnx

Really storm? Would you like to talk to me some time about how yours works? My chatbot isn't to show people how to connect to battle.net, but rather techniques on handling/managing things.

OK.

My bot is written in Python/wxPython (a better windowing environment).

Basically, I have a timer call a special method in my ChatConnection class every 10ms. This method calls select() on a nonblocking socket. If the socket is in the read list, read data and add it to the buffer. If a newline is in the buffer, chop off the newline and everything before and pass it to the parser and dispatcher.

The parser splits it by spaces and quotes. The dispatcher checks its message ID and iterates through a list of Listeners and calls methods in them (on_join, on_leave, etc).

If a socket is in the write list, send the next message in the queue if the antiflood wait time is up. If it's in the error list, we terminate.



ChatConnection can be observed by serveral objects, which makes it very versitile and decoupled from the main window.

[quote author=St0rm.iD link=board=17;threadid=812;start=0#msg6648 date=1048978918]
OK.

My bot is written in Python/wxPython (a better windowing environment).

Basically, I have a timer call a special method in my ChatConnection class every 10ms. This method calls select() on a nonblocking socket. If the socket is in the read list, read data and add it to the buffer. If a newline is in the buffer, chop off the newline and everything before and pass it to the parser and dispatcher.

The parser splits it by spaces and quotes. The dispatcher checks its message ID and iterates through a list of Listeners and calls methods in them (on_join, on_leave, etc).

If a socket is in the write list, send the next message in the queue if the antiflood wait time is up. If it's in the error list, we terminate.



ChatConnection can be observed by serveral objects, which makes it very versitile and decoupled from the main window.
[/quote]Hmm.. Why not setup for some kind of notification for socket events instead of polling it every 10ms? Your method wastes lots of processor time.

Can you explain?

[quote author=St0rm.iD link=board=17;threadid=812;start=0#msg6687 date=1049050655]
Can you explain?
[/quote]There are lots of things which allow you to in some way receive notification of the completion of an asynchronous operation. Perhaps the simplest are the functions WSAAsyncSelect and WSAEventSelect, though I'd recommend you stay away from WSAAsyncSelect as much as possible, as it's got the annoying habit of creating extra threads in your process which don't go away.

If you're really wanting good performance, I'd recommend that you go with overlapped I/O - see ReadFileEx, WriteFileEx, WSARecv, and WSASend. Note that overlapped operations typically require your thread to be alertable - that is, you need to use one of SleepEx, WaitForSingleObjectEx, WaitForMultipleObjectsEx, MsgWaitForMultipleObjectsEx, or SignalObjectAndWait as the thread-blocking function in your main loop.

It is important to note that typical system modal dialog loops are not alertable.

Doesn't that require multithreading?

I thought that it does. But then again I may be wrong.

-:DRivE:-

[quote author=St0rm.iD link=board=17;threadid=812;start=0#msg6691 date=1049052046]
Doesn't that require multithreading?
[/quote]No. BinaryChat uses overlapped I/O and runs everything (the GUI included) in a single thread, and supports any number of bot connections per process.

See... never listen to me when it comes to programming.

-:DRivE:-

I don't understand how that's different from select().

[quote author=St0rm.iD link=board=17;threadid=812;start=15#msg6710 date=1049063402]
I don't understand how that's different from select().
[/quote]It's completely different. If you read the Winsock documentation, select is severely crippled under Win32.

Perhaps I'm writing in Python...;)
What exactly does overlapped I/O do though? select() for me returns a list of channels that are readable at the moment and can do non-blocking reads, I just set the select() value to 5 ms so it has a little waiting time.

[quote author=St0rm.iD link=board=17;threadid=812;start=15#msg6729 date=1049076317]
Perhaps I'm writing in Python...;)
What exactly does overlapped I/O do though? select() for me returns a list of channels that are readable at the moment and can do non-blocking reads, I just set the select() value to 5 ms so it has a little waiting time.
[/quote]Whether you are using Python or not doesn't matter if it's on Win32, which your earlier comments suggested.

Overlapped I/O lets the system perform the I/O operations in dedicated worker threads, returning the result to you when it's completed. In Windows NT, for the most part this is what goes on already, it's just that for example ReadFile by default waits for the I/O operation to complete.

When used with sockets, you eliminate extra copying of data, thus increasing performance. Additionally, it removes the 64-socket limitation; you can have any number of pending overlapped operations per thread.