Comments Request

[MyndFyre]

Hey...

While I'm writing my bot in C#, I'm trying to keep everything encapsulated as possible.  Part of this is keeping connection procedures out of the actual bot program, and in a separate assembly (DLL).

So essentially, I've been working on writing the equivalent of CSB for .NET developers.  I've begun using NDoc, which reflects through my assembly and gets XML documentation that was emitted at compile-time to generate some nice MSDN-style documentation files.

I'd like to know what you guys think of my framework.  The main classes to look at are NLSConnectionManager and EventHost -- right now, as I've been doing a complete rewrite, those are the only two major connection-oriented classes that work, and they are the only ones I included in this specific build (the OpenConnectionManager will also be released with Alpha 4, but that will be in about 3 weeks).  The HTML documentation can be downloaded at this site.  Just open index.html.  Other classes work as well -- WarcraftStats, all the enumerations, that stuff.  I've noticed some things already, though -- BnlsParse and BnlsParsePacket should not be public!  I'll have to go back and fix that!

Thanks guys.

[Arta]

I like eventhost. It could be very useful. A class diagram would help a lot, if you want comments on design.

Btw, what did you use to generate the documentation? It's uber-sexy.

[dxoigmn]

Btw, what did you use to generate the documentation? It's uber-sexy.

http://ndoc.sourceforge.net/wiki according to his post.

[Arta]

Ah yes, didn't notice that.

[Adron]

Couldn't you make the documentation browseable online?

[MyndFyre]

When it is complete, I will make the documentation available both online and in CHM format.  It's not really worthy of being published yet.  ;-)

[edit]
Allright, allright.  I am uploading it via FTP (we all know how slow Windows Explorer is for uploading via FTP), so it should be done in about 5 minutes.  It is available via this link.

[edit=2]
Also, I'm considering changing the EventHost class around, Arta, so that rather than wiring into events, the event host will be responsible for calling delegates on its own.  For example, rather than how it is now, it will provide:

Code Select Expand


public void RegisterEvent(EventType type, System.MultiCastDelegate callback);

public enum EventType
{
 ChannelListReceived,
 ChatText,
 FriendsListDownloaded,
 // etc.
}


and then having the user wire into the events this way:

Code Select Expand


public void EventHost_ConnectionStatus(ConnectionStatus status)
{
 // ...
 if ((status & ConnectionStatus.ConnectionCompleted) == ConnectionStatus.ConnectionCompleted)
 {
   myConnection.EventHost.RegisterEvent(EventType.ChatText, new ChatEventHandler(this.User_Chatted));
   // other events registered
 }
}


While that isn't the optimal solution, it's much more interface-friendly.  I'd like a single GUI element to be able to open any kind of connection manager, and if I can make a single IConnectionManager and IEventHost interface that the GUI can expect, all the better.

Thoughts?

[Eibro]

I've got a similar project on the go right now in C++. I figure i'll try using doxygen to generate docs similar to yours, though they won't be as pretty. If you're interested in a combined effort of distributing components/docs, gimme a shout.

[MyndFyre]

Per Arta's request for a modified EventHost class:



This will function by passing function pointers into RegisterEvent, which will be called as necessary.