BNSharp
Designates a callback method that can be used to parse a specific packet. This delegate is not CLS-compliant.
The contents of the packet.
This delegate should only be used by advanced developers when registering custom packet handlers with BN#.
When overriding default behavior, the implementer should be careful to ensure to free the parse data. This can be done by, when
bubbling the event, by setting the BaseEventArgs.EventData property. Otherwise, call
BufferPool.FreeBuffer on the BattleNetClientResources.IncomingBufferPool.
Completes a DataBuffer implementation with the additional
data used by the BNCS protocol.
The following example illustrates creating a buffer that contains only the
SID_NULL packet:
Note: this example assumes you have a
Socket object called "sck" in the
current context.
[C#]
BncsPacket pckNull = new BncsPacket(0);
sck.Send(pckNull.GetData(), 0, pckNull.Count, SocketFlags.None);
[Visual Basic]
Dim pckNull As New BncsPacket(0)
sck.Send(pckNull.GetData(), 0, pckNull.Count, SocketFlags.None)
[C++]
BncsPacket ^pckNull = gcnew BncsPacket(0);
sck->Send(pckNull->GetData(), 0, pckNull->Count, SocketFlags.None);
The following example illustrates calculating the revision check (SID_AUTH_ACCONTLOGON) of Warcraft III:
Note: this example assumes you have a
Socket object called "sck" in the
current context.
[C#]
BncsPacket pckLogin = new BncsPacket(0x53);
NLS nls = new NLS(userName, password);
nls.LoginAccount(pckLogin);
sck.Send(pckLogin.GetData(), 0, pckLogin.Count, SocketFlags.None);
[Visual Basic]
Dim pckLogin As New BncsPacket(&H51)
Dim nls As New NLS(userName, password)
nls.LoginAccount(pckLogin)
sck.Send(pckLogin.GetData(), 0, pckLogin.Count, SocketFlags.None)
[C++]
// NOTE that userName and password must be System::String^, not char*!
BncsPacket ^pckLogin = gcnew BncsPacket(0x51);
NLS ^nls = gcnew NLS(userName, password);
nls->LoginAccount(pckLogin)
sck->Send(pckLogin->GetData(), 0, pckLogin->Count, SocketFlags.None);
Operates as a data buffer for network and file output.
This class does not read data in any manner; for reading or receiving data,
use the DataReader or derived classes.
This class always uses little-endian byte ordering.
This class no longer supports operator overloading in C# via the binary addition (+)
operator.
Creates a new DataBuffer.
Inserts the specified Boolean value into the buffer.
The value to insert.
This method inserts a 32-bit value of 1 or 0 based on the value of the
parameter: 1 if the value is true, or otherwise 0.
Inserts the specified Boolean value into the buffer.
The value to insert.
This method inserts a 32-bit value of 1 or 0 based on the value of the
parameter: 1 if the value is true, or otherwise 0.
Inserts the specified value into the buffer.
The value to insert.
Inserts the specified value into the buffer.
The value to insert.
Inserts the specified value into the buffer.
This method is not CLS-compliant.
The value to insert.
Inserts the specified value into the buffer.
This method is not CLS-compliant.
The value to insert.
Inserts the specified byte array into the buffer.
The value to insert.
Inserts the specified byte array into the buffer.
The value to insert.
Inserts the specified byte array into the buffer.
The value to insert.
This method is not CLS-compliant.
Inserts the specified byte array into the buffer.
The value to insert.
This method is not CLS-compliant.
Inserts the specified value into the buffer.
The value to insert.
Inserts the specified value into the buffer.
The value to insert.
Inserts the specified value into the buffer.
This method is not CLS-compliant.
The value to insert.
Inserts the specified value into the buffer.
This method is not CLS-compliant.
The value to insert.
Inserts the specified 16-bit data array into the buffer.
The value to insert.
Inserts the specified 16-bit data array into the buffer.
The value to insert.
Inserts the specified 16-bit data array into the buffer.
The value to insert.
This method is not CLS-compliant.
Inserts the specified 16-bit data array into the buffer.
The value to insert.
This method is not CLS-compliant.
Inserts the specified value into the buffer.
The value to insert.
Inserts the specified value into the buffer.
The value to insert.
Inserts the specified value into the buffer.
The value to insert.
This method is not CLS-compliant.
Inserts the specified value into the buffer.
The value to insert.
This method is not CLS-compliant.
Inserts the specified 32-bit data array into the buffer.
The value to insert.
Inserts the specified 32-bit data array into the buffer.
The value to insert.
Inserts the specified 32-bit data array into the buffer.
The value to insert.
This method is not CLS-compliant.
Inserts the specified 32-bit data array into the buffer.
The value to insert.
This method is not CLS-compliant.
Inserts the specified value into the buffer.
The value to insert.
Inserts the specified value into the buffer.
The value to insert.
Inserts the specified value into the buffer.
The value to insert.
This method is not CLS-compliant.
Inserts the specified value into the buffer.
The value to insert.
This method is not CLS-compliant.
Inserts the specified 64-bit data array into the buffer.
The value to insert.
Inserts the specified 64-bit data array into the buffer.
The value to insert.
Inserts the specified 64-bit data array into the buffer.
The value to insert.
This method is not CLS-compliant.
Inserts the specified 64-bit data array into the buffer.
The value to insert.
This method is not CLS-compliant.
Inserts the specified value into the buffer as a C-style null-terminated
ASCII string.
The string value to insert.
This method inserts a string terminated by a single null (0) byte.
Either str or enc were null (Nothing in Visual Basic).
Inserts the specified value into the buffer as a C-style null-terminated
string using the specified encoding.
The byte encoding to use.
The string value to insert.
This method inserts a string terminated by a null character. For
8-bit character encodings such as ASCII, this null character is also 8 bits.
For 16-bit character encodings such as Unicode, this null character is also
16 bits.
Either str or enc were null (Nothing in Visual Basic).
Inserts the specified value into the buffer as a pascal-style ASCII string.
The string value to insert.
This method inserts a string prefixed by the total number of characters
in the string. At most a string may be 255 characters.
Either str or enc were null (Nothing in Visual Basic).
The length of str was too great; maximum string length is 255 characters.
Inserts the specified value into the buffer as a pascal-style string using
the specified encoding.
The encoding to use.
The string value to insert.
This method inserts a string prefixed by the total number of characters
in the string. At most a string may be 255 characters.
Either str or enc were null (Nothing in Visual Basic).
The length of str was too great; maximum string length is 255 characters.
Inserts the specified value into the buffer as a wide-pascal-style ASCII
string.
The string value to insert.
This method inserts a string prefixed by the total number of characters
in the string. At most a string may be 65,535 characters.
Either str or enc were null (Nothing in Visual Basic).
The length of str was too great; maximum string length is 65,535 characters.
Inserts the specified value into the buffer as a wide-pascal-style string
using the specified encoding.
The encoding to use.
The string value to insert.
This method inserts a string prefixed by the total number of characters
in the string. At most a string may be 65,535 characters.
Either str or enc were null (Nothing in Visual Basic).
The length of str was too great; maximum string length is 65,535 characters.
Inserts the specified value into the buffer as a 32-bit-style string using
null bytes as the default padding.
This method inserts a string with the maximum length of 4 into the
buffer, reversed. This mimics the C-style declarations of 4-character
integer literals:
unsigned long int star_product = 'STAR';
which results in RATS being in memory.
The string which may be at most 4 characters.
The str parameter was null (Nothing in Visual Basic).
The length of str was too great; maximum string length is 4 characters.
Inserts the specified value into the buffer as a 32-bit-style string using
the specified byte as padding.
This method inserts a string with the maximum length of 4 into the
buffer, reversed. This mimics the C-style declarations of 4-character
integer literals:
unsigned long int star_product = 'STAR';
which results in RATS being in memory.
The string which may be at most 4 characters.
The byte which shall be used to pad the string if it is less than 4 characters long.
The str parameter was null (Nothing in Visual Basic).
The length of str was too great; maximum string length is 4 characters.
Gets the data currently contained in the buffer.
A byte array representing the data in the buffer.
Writes the data currently contained in the buffer to the specified stream.
The stream to which to write the data.
The number of bytes written to the stream.
Gets a hex representation of this buffer.
A string representing this buffer's contents in hexadecimal notation.
Disposes the object, freeing any unmanaged and managed resources.
Disposes the object, freeing any unmanaged and optionally managed resources.
to dispose managed resources; otherwise to only
dispose unmanaged resources.
Gets the contents of the underlying buffer.
Gets the length of data in the buffer.
Creates a new BNCS packet with the specified packet ID.
The BNCS packet ID.
Gets the data in this packet, including the four-byte header.
A byte array containing the packet data.
Gets the contents of the underlying buffer.
Gets or sets the ID of the packet as it was specified when it was created.
Implements a client connection to Battle.net.
This is the primary class that should be used when implementing a Battle.net client. To implement one, you only need to implement
the IBattleNetSettings interface, which provides information about a connection to Battle.net. Once this interface is implemented
and this object is created, the client should register for events and that's it.
Represents a TCP/IP connection.
Creates a new instance of the ConnectionBase class.
The URI of the server to connect to.
The port of the server to connect to.
Connects the connection to the remote host.
True if the connection completed successfully; otherwise false.
The OnError method is called when an error takes place, but no
behavior is defined by default. Inheriting classes should provide an implementation
to handle errors.
This method may return false if the connection is already established. To check whether the
connection is established, check the IsConnected property.
When overridden by a derived class, provides error information from the current connection.
Human-readable information about the error.
An internal exception containing the error details.
Closes the connection and prepares for a new connection.
For derived classes, sends the specified binary data to the server.
The data to send.
For derived classes, sends part of the specified binary data to the server.
The data to send.
The start index of the data.
The amount of data to send.
Receives the specified number of bytes.
This method blocks in a loop until all of the data comes through. For that reason, it
is recommended that this method is only used in a background thread.
The amount of data to receive.
A byte array containing the specified data.
Receives the specified number of bytes into the provided buffer.
The buffer to receive the data.
The starting index to place the data.
The amount of data to receive.
A reference to if the operation completed successfully, or else
.
Thrown if is
Thrown if the combination of and
point to invalid positions in the buffer.
Retrieves an arbitrarily-sized byte array of data.
An array of bytes of data that have been received from the server.
Disposes the specified object.
Disposes the object, freeing unmanaged and optionally managed resources.
Whether to free managed resources.
Gets whether the connection is alive or not.
Once the connection is established, gets the local endpoint to which the client is bound.
Once the connection is established, gets the remote endpoint to which the client is bound.
If the client is logged on as a clan Chieftan or Shaman, sets the clan message-of-the-day.
The new message-of-the-day.
Begins searching for clan candidates in the channel and friends list, and checks the availability of the specified clan tag.
The clan tag to check for availability.
The request ID assigned to the request.
This method will return immediately, but will cause the ClanCandidatesSearchCompleted event to be fired. That event does not
specifically indicate that the proper number of candidates were found, simply that Battle.net responded. The event arguments sent
as part of the event indicate the success or failure of the request.
Thrown if is .
Invites the specified number of users to form a new clan.
The name of the clan to form.
The tag of the clan to form.
The list of users to invite. This parameter must be exactly 9 items long.
The request ID assigned to this request.
Thrown if , ,
, or any of the strings in the array of
is .
Thrown if is not exactly 9 items long.
Responds to the invitation to form a new clan.
The request ID, provided by the ClanFormationInvitationEventArgs.
The clan tag.
The user who invited the client to the clan.
Whether to accept the invitation.
Disbands the clan to which the client belongs.
The request ID assigned to the request.
The client must be the leader of the clan in order to send this command.
Designates a user as a new clan chieftan (leader).
The unique request ID assigned to the request.
The name of the new clan chieftan.
Begins the process of inviting a user to join a clan.
The name of the user to invite.
A unique request identifier.
Begins the process for removing a member from the clan.
The name of the clan member to remove.
The request ID assigned to this request.
Thrown if is or zero-length.
Responds to a clan invitation received via the ClanInvitationReceived event.
The arguments that accompanied the invitation.
to accept the invitation and join the clan; otherwise .
Following the acceptance of an invitation, the client should receive ClanMembershipReceived and automatically respond by requesting clan
membership information.
Registers a custom handler for a specific packet ID. This method is not CLS-compliant.
The packet to register to handle.
A callback that will handle the data.
A previous parser, or if no parser was set to handle such a packet.
A sink to fire off BattleNetClient events.
Thrown if is .
Thrown if refers to the Warden value, or if the
value is greater than 255 or less than 0.
This method can be used to replace the default BN# packet handlers or to augment them with new handlers. For example, BN# does
not and will not likely ever support Diablo II Realms and Realm Character login. However, third-party developers can augment BN# to
handle those packets and support events on their own.
The IBattleNetEvents sink is the same for subsequent calls to this method per-instance of BattleNetClient,
so you don't need to do anything special with the return value each time you call this method.
Unregisters a custom handler for a specific packet ID, restoring the previous handler. This method is not CLS-compliant.
The packet ID for which to unregister.
The previous parser. If none was provided during registration, this value may be .
Thrown if refers to the Warden value, or if the
value is greater than 255 or less than 0.
Registers a custom packet priority list for consideration during packet parsing.
The new priority provider to use for priority lookups.
Thrown if is .
Unregisters a custom packet priority list from consideration during packet parsing.
The priority provider to remove from consideration.
Thrown if is
.
Registers for notification of the UserJoined event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the UserJoined event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the UserJoined event.
Only high-priority events are invoked immediately; others are deferred. For more information, see UserJoined.
The event arguments.
Registers for notification of the UserLeft event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the UserLeft event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the UserLeft event.
Only high-priority events are invoked immediately; others are deferred. For more information, see UserLeft.
The event arguments.
Registers for notification of the UserShown event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the UserShown event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the UserShown event.
Only high-priority events are invoked immediately; others are deferred. For more information, see UserShown.
The event arguments.
Registers for notification of the UserFlagsChanged event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the UserFlagsChanged event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the UserFlagsChanged event.
Only high-priority events are invoked immediately; others are deferred. For more information, see UserFlagsChanged.
The event arguments.
Registers for notification of the ServerBroadcast event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the ServerBroadcast event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the ServerBroadcast event.
Only high-priority events are invoked immediately; others are deferred. For more information, see ServerBroadcast.
The event arguments.
Registers for notification of the JoinedChannel event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the JoinedChannel event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the JoinedChannel event.
Only high-priority events are invoked immediately; others are deferred. For more information, see JoinedChannel.
The event arguments.
Registers for notification of the ChannelWasFull event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the ChannelWasFull event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the ChannelWasFull event.
Only high-priority events are invoked immediately; others are deferred. For more information, see ChannelWasFull.
The event arguments.
Registers for notification of the ChannelDidNotExist event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the ChannelDidNotExist event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the ChannelDidNotExist event.
Only high-priority events are invoked immediately; others are deferred. For more information, see ChannelDidNotExist.
The event arguments.
Registers for notification of the ChannelWasRestricted event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the ChannelWasRestricted event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the ChannelWasRestricted event.
Only high-priority events are invoked immediately; others are deferred. For more information, see ChannelWasRestricted.
The event arguments.
Registers for notification of the InformationReceived event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the InformationReceived event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the InformationReceived event.
Only high-priority events are invoked immediately; others are deferred. For more information, see InformationReceived.
The event arguments.
Registers for notification of the ServerErrorReceived event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the ServerErrorReceived event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the ServerErrorReceived event.
Only high-priority events are invoked immediately; others are deferred. For more information, see ServerErrorReceived.
The event arguments.
Registers for notification of the WhisperSent event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the WhisperSent event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the WhisperSent event.
Only high-priority events are invoked immediately; others are deferred. For more information, see WhisperSent.
The event arguments.
Registers for notification of the WhisperReceived event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the WhisperReceived event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the WhisperReceived event.
Only high-priority events are invoked immediately; others are deferred. For more information, see WhisperReceived.
The event arguments.
Registers for notification of the UserSpoke event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the UserSpoke event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the UserSpoke event.
Only high-priority events are invoked immediately; others are deferred. For more information, see UserSpoke.
The event arguments.
Registers for notification of the UserEmoted event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the UserEmoted event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the UserEmoted event.
Only high-priority events are invoked immediately; others are deferred. For more information, see UserEmoted.
The event arguments.
Registers for notification of the MessageSent event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the MessageSent event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the MessageSent event.
Only high-priority events are invoked immediately; others are deferred. For more information, see MessageSent.
The event arguments.
Registers for notification of the CommandSent event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the CommandSent event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the CommandSent event.
Only high-priority events are invoked immediately; others are deferred. For more information, see CommandSent.
The event arguments.
Registers for notification of the ClientCheckPassed event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the ClientCheckPassed event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the ClientCheckPassed event.
Only high-priority events are invoked immediately; others are deferred. For more information, see ClientCheckPassed.
The event arguments.
Registers for notification of the ClientCheckFailed event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the ClientCheckFailed event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the ClientCheckFailed event.
Only high-priority events are invoked immediately; others are deferred. For more information, see ClientCheckFailed.
The event arguments.
Registers for notification of the LoginSucceeded event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the LoginSucceeded event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the LoginSucceeded event.
Only high-priority events are invoked immediately; others are deferred. For more information, see LoginSucceeded.
The event arguments.
Registers for notification of the LoginFailed event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the LoginFailed event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the LoginFailed event.
Only high-priority events are invoked immediately; others are deferred. For more information, see LoginFailed.
The event arguments.
Registers for notification of the EnteredChat event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the EnteredChat event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the EnteredChat event.
Only high-priority events are invoked immediately; others are deferred. For more information, see EnteredChat.
The event arguments.
Registers for notification of the AccountCreated event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the AccountCreated event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the AccountCreated event.
Only high-priority events are invoked immediately; others are deferred. For more information, see AccountCreated.
The event arguments.
Registers for notification of the AccountCreationFailed event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the AccountCreationFailed event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the AccountCreationFailed event.
Only high-priority events are invoked immediately; others are deferred. For more information, see AccountCreationFailed.
The event arguments.
Registers for notification of the ChannelListReceived event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the ChannelListReceived event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the ChannelListReceived event.
Only high-priority events are invoked immediately; others are deferred. For more information, see ChannelListReceived.
The event arguments.
Registers for notification of the Error event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the Error event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the Error event.
Only high-priority events are invoked immediately; others are deferred. For more information, see Error.
The event arguments.
Registers for notification of the Information event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the Information event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the Information event.
Only high-priority events are invoked immediately; others are deferred. For more information, see Information.
The event arguments.
Registers for notification of the Connected event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the Connected event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the Connected event.
Only high-priority events are invoked immediately; others are deferred. For more information, see Connected.
The event arguments.
Registers for notification of the Disconnected event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the Disconnected event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the Disconnected event.
Only high-priority events are invoked immediately; others are deferred. For more information, see Disconnected.
The event arguments.
Registers for notification of the WardentUnhandled event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the WardentUnhandled event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the WardentUnhandled event.
Only high-priority events are invoked immediately; others are deferred. For more information, see WardentUnhandled.
The event arguments.
Registers for notification of the ServerNews event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the ServerNews event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the ServerNews event.
Only high-priority events are invoked immediately; others are deferred. For more information, see ServerNews.
The event arguments.
Registers for notification of the ClanMemberListReceived event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the ClanMemberListReceived event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the ClanMemberListReceived event.
Only high-priority events are invoked immediately; others are deferred. For more information, see ClanMemberListReceived.
The event arguments.
Registers for notification of the ClanMemberStatusChanged event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the ClanMemberStatusChanged event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the ClanMemberStatusChanged event.
Only high-priority events are invoked immediately; others are deferred. For more information, see ClanMemberStatusChanged.
The event arguments.
Registers for notification of the ClanMemberQuit event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the ClanMemberQuit event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the ClanMemberQuit event.
Only high-priority events are invoked immediately; others are deferred. For more information, see ClanMemberQuit.
The event arguments.
Registers for notification of the ClanMemberRemoved event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the ClanMemberRemoved event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the ClanMemberRemoved event.
Only high-priority events are invoked immediately; others are deferred. For more information, see ClanMemberRemoved.
The event arguments.
Registers for notification of the ClanMessageOfTheDay event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the ClanMessageOfTheDay event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the ClanMessageOfTheDay event.
Only high-priority events are invoked immediately; others are deferred. For more information, see ClanMessageOfTheDay.
The event arguments.
Registers for notification of the ClanRankChanged event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the ClanRankChanged event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the ClanRankChanged event.
Only high-priority events are invoked immediately; others are deferred. For more information, see ClanRankChanged.
The event arguments.
Registers for notification of the ClanMembershipReceived event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the ClanMembershipReceived event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the ClanMembershipReceived event.
Only high-priority events are invoked immediately; others are deferred. For more information, see ClanMembershipReceived.
The event arguments.
Registers for notification of the ClanCandidatesSearchCompleted event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the ClanCandidatesSearchCompleted event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the ClanCandidatesSearchCompleted event.
Only high-priority events are invoked immediately; others are deferred. For more information, see ClanCandidatesSearchCompleted.
The event arguments.
Registers for notification of the ClanFormationCompleted event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the ClanFormationCompleted event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the ClanFormationCompleted event.
Only high-priority events are invoked immediately; others are deferred. For more information, see ClanFormationCompleted.
The event arguments.
Registers for notification of the ClanFormationInvitationReceived event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the ClanFormationInvitationReceived event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the ClanFormationInvitationReceived event.
Only high-priority events are invoked immediately; others are deferred. For more information, see ClanFormationInvitationReceived.
The event arguments.
Registers for notification of the ClanDisbandCompleted event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the ClanDisbandCompleted event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the ClanDisbandCompleted event.
Only high-priority events are invoked immediately; others are deferred. For more information, see ClanDisbandCompleted.
The event arguments.
Registers for notification of the ClanChangeChieftanCompleted event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the ClanChangeChieftanCompleted event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the ClanChangeChieftanCompleted event.
Only high-priority events are invoked immediately; others are deferred. For more information, see ClanChangeChieftanCompleted.
The event arguments.
Registers for notification of the ClanInvitationReceived event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the ClanInvitationReceived event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the ClanInvitationReceived event.
Only high-priority events are invoked immediately; others are deferred. For more information, see ClanInvitationReceived.
The event arguments.
Registers for notification of the LeftClan event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the LeftClan event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the LeftClan event.
Only high-priority events are invoked immediately; others are deferred. For more information, see LeftClan.
The event arguments.
Registers for notification of the ClanInvitationResponseReceived event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the ClanInvitationResponseReceived event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the ClanInvitationResponseReceived event.
Only high-priority events are invoked immediately; others are deferred. For more information, see ClanInvitationResponseReceived.
The event arguments.
Registers for notification of the ClanRemovalResponse event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the ClanRemovalResponse event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the ClanRemovalResponse event.
Only high-priority events are invoked immediately; others are deferred. For more information, see ClanRemovalResponse.
The event arguments.
Registers for notification of the FriendListReceived event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the FriendListReceived event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the FriendListReceived event.
Only high-priority events are invoked immediately; others are deferred. For more information, see FriendListReceived.
The event arguments.
Registers for notification of the FriendUpdated event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the FriendUpdated event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the FriendUpdated event.
Only high-priority events are invoked immediately; others are deferred. For more information, see FriendUpdated.
The event arguments.
Registers for notification of the FriendAdded event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the FriendAdded event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the FriendAdded event.
Only high-priority events are invoked immediately; others are deferred. For more information, see FriendAdded.
The event arguments.
Registers for notification of the FriendRemoved event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the FriendRemoved event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the FriendRemoved event.
Only high-priority events are invoked immediately; others are deferred. For more information, see FriendRemoved.
The event arguments.
Registers for notification of the FriendMoved event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the FriendMoved event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the FriendMoved event.
Only high-priority events are invoked immediately; others are deferred. For more information, see FriendMoved.
The event arguments.
Registers for notification of the UserProfileReceived event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority at which to register.
The event handler that should be registered for this event.
Unregisters for notification of the UserProfileReceived event at the specified priority.
The event system in the JinxBot API supports normal event registration and prioritized event registration. You can use
normal syntax to register for events at Normal priority, so no special registration is needed; this is
accessed through normal event handling syntax (the += syntax in C#, or the in Visual Basic.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
To be well-behaved within JinxBot, plugins should always unregister themselves when they are being unloaded or when they
otherwise need to do so. Plugins may opt-in to a Reflection-based event handling registration system which uses attributes to
mark methods that should be used as event handlers.
The priority from which to unregister.
The event handler that should be unregistered for this event.
Raises the UserProfileReceived event.
Only high-priority events are invoked immediately; others are deferred. For more information, see UserProfileReceived.
The event arguments.
Creates a new BattleNetClient with the specified settings.
An object containing the settings for a Battle.net connection.
Thrown if is .
Sends a data buffer to the server.
The buffer to send.
Use of this method is preferred when sending binary messages because, after sending the buffer, it frees the buffer from the outgoing buffer pool. If you
are only sending a text command, you should use Send(string); it not only automatically creates the packet, but uses the speed delay provider,
if any, assigned to the CommandQueueProvider property.
Begins the connection to Battle.net.
if the connection succeeded; otherwise .
Closes the connection.
Sends a textual message to the server.
The message to send.
Thrown if the client is not connected.
Thrown if is longer than 223 characters.
Thrown if is .
Creates a new account, attempting to use the login information provided in the settings.
Allows the client to continue logging in if the login has stopped due to a non-existent username or password.
If a LoginFailed event occurs, the client is not automatically disconnected. The UI can then present an interface
by which the user may modify the client's Settings instance with proper login information. Once this has been done, the
user may then call this method to attempt to log in again.
This method does not need to be called after the AccountCreated event.
Requests a user's profile.
The name of the user for whom to request information.
The profile request, which should contain the keys to request.
Raises the EventExceptionThrown event.
The event arguments.
This is the listening thread. All it does is loop on receive.
This is the parsing thread.
Gets or sets the Warden module currently in use.
The warden implementation must use this property to set itself before beginning the connection
Informs listeners that a user joined the client's current channel.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterUserJoinedNotification and
UnregisterUserJoinedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that a user left the client's current channel.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterUserLeftNotification and
UnregisterUserLeftNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners a user was already in the channel when the client joined it.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterUserShownNotification and
UnregisterUserShownNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that a user's flags changed.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterUserFlagsChangedNotification and
UnregisterUserFlagsChangedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that the server sent a broadcast message.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterServerBroadcastNotification and
UnregisterServerBroadcastNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that the client joined a new channel.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterJoinedChannelNotification and
UnregisterJoinedChannelNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that a channel join failed because the channel was full.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterChannelWasFullNotification and
UnregisterChannelWasFullNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners a channel view failed because the channel did not exist.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterChannelDidNotExistNotification and
UnregisterChannelDidNotExistNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that a channel join failed because the channel was restricted.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterChannelWasRestrictedNotification and
UnregisterChannelWasRestrictedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that the server has sent an informational message to the client.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterInformationReceivedNotification and
UnregisterInformationReceivedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that an error message was received from the server.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterServerErrorReceivedNotification and
UnregisterServerErrorReceivedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that a whisper was sent from the client to another user.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterWhisperSentNotification and
UnregisterWhisperSentNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that a whisper was received from another user.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterWhisperReceivedNotification and
UnregisterWhisperReceivedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that a user spoke in the channel.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterUserSpokeNotification and
UnregisterUserSpokeNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that a user emoted in the current channel.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterUserEmotedNotification and
UnregisterUserEmotedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that the client has sent a message to Battle.net.
The event handlers should check the EventType property of the event arguments to
determine whether this event was an emote or a standard talk command and present the text appropriately.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterMessageSentNotification and
UnregisterMessageSentNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that a command was sent to the server.
This event is fired whenever the user sends a slash command to the server, except for /me or /emote commands. The /me and
/emote commands are informed through the MessageSent event.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterCommandSentNotification and
UnregisterCommandSentNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that the client versioning check was successful.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterClientCheckPassedNotification and
UnregisterClientCheckPassedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that the client versioning check failed.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterClientCheckFailedNotification and
UnregisterClientCheckFailedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that the client login succeeded.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterLoginSucceededNotification and
UnregisterLoginSucceededNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that the client login failed.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterLoginFailedNotification and
UnregisterLoginFailedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that the client has entered chat.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterEnteredChatNotification and
UnregisterEnteredChatNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that a new account has been created.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterAccountCreatedNotification and
UnregisterAccountCreatedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that an attempt to create an account has failed.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterAccountCreationFailedNotification and
UnregisterAccountCreationFailedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that the channel list has been provided by the server.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterChannelListReceivedNotification and
UnregisterChannelListReceivedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that a general or connection error has occurred.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterErrorNotification and
UnregisterErrorNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners about a general informational message.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterInformationNotification and
UnregisterInformationNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that the application has connected to the server.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterConnectedNotification and
UnregisterConnectedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that the client has disconnected.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterDisconnectedNotification and
UnregisterDisconnectedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that the server has challenged the client with a warden handshake, but that the client did not have a
Warden plugin enabled.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterWardentUnhandledNotification and
UnregisterWardentUnhandledNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that the server has provided news items to view.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterServerNewsNotification and
UnregisterServerNewsNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that the user's clan member list has been received.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterClanMemberListReceivedNotification and
UnregisterClanMemberListReceivedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that a clan member's status has changed.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterClanMemberStatusChangedNotification and
UnregisterClanMemberStatusChangedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that a clan member has quit the clan.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterClanMemberQuitNotification and
UnregisterClanMemberQuitNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that a clan member has been removed from the clan.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterClanMemberRemovedNotification and
UnregisterClanMemberRemovedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners of the clan's message-of-the-day.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterClanMessageOfTheDayNotification and
UnregisterClanMessageOfTheDayNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that the client's user's clan rank has changed.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterClanRankChangedNotification and
UnregisterClanRankChangedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that the client's user belongs to a clan.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterClanMembershipReceivedNotification and
UnregisterClanMembershipReceivedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that a clan candidates search has completed.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterClanCandidatesSearchCompletedNotification and
UnregisterClanCandidatesSearchCompletedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that an attempt to form a clan has completed.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterClanFormationCompletedNotification and
UnregisterClanFormationCompletedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that the client has been invited to join a clan as it is forming.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterClanFormationInvitationReceivedNotification and
UnregisterClanFormationInvitationReceivedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that an attempt to disband the clan has been completed.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterClanDisbandCompletedNotification and
UnregisterClanDisbandCompletedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that a request to change the clan chieftan has completed.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterClanChangeChieftanCompletedNotification and
UnregisterClanChangeChieftanCompletedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that the client has received an invitation to join an existing clan.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterClanInvitationReceivedNotification and
UnregisterClanInvitationReceivedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that the client has either left the clan or been forcibly removed.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterLeftClanNotification and
UnregisterLeftClanNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that an invitation to join a clan has been responded to and that the response has been received.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterClanInvitationResponseReceivedNotification and
UnregisterClanInvitationResponseReceivedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that a request to remove a clan member has completed.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterClanRemovalResponseNotification and
UnregisterClanRemovalResponseNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that the client's friend list has been received.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterFriendListReceivedNotification and
UnregisterFriendListReceivedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that a friend on the client's friend list has had its status changed.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterFriendUpdatedNotification and
UnregisterFriendUpdatedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that a new friend has been added to the client's friends list.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterFriendAddedNotification and
UnregisterFriendAddedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that a friend has been removed from the client's friends list.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterFriendRemovedNotification and
UnregisterFriendRemovedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that a friend on the user's friends list has changed position on the list.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterFriendMovedNotification and
UnregisterFriendMovedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Informs listeners that a user profile has been received.
Registering for this event with this member will register with Normal priority. To register for
High or Low priority, use the RegisterUserProfileReceivedNotification and
UnregisterUserProfileReceivedNotification methods.
Events in the JinxBot API are never guaranteed to be executed on the UI thread. Events that affect the user interface should
be marshaled back to the UI thread by the event handling code. Generally, high-priority event handlers are
raised on the thread that is parsing data from Battle.net, and lower-priority event handler are executed from the thread pool.
JinxBot guarantees that all event handlers will be fired regardless of exceptions raised in previous event handlers. However,
if a plugin repeatedly raises an exception, it may be forcefully unregistered from events.
Gets the settings associated with this connection.
Gets a read-only list of all of the users in the current channel.
Gets the name of the current channel.
Informs listeners that a client-oriented event handler has thrown an exception.
Contains data from the receive thread that needs to be used by the parsing thread.
To maximize efficiency, this class does not protect any of its members through properties. It should only be used when
implementing a custom handler for one or more messages.
Contains the packet ID associated with this data.
Contains the length specified by Battle.net for this data, minus the four bytes used in the header.
Contains the literal data sent from Battle.net.
Provided by the BN# Plugins Infrastructure to enable custom packet handlers to fire events.
THIS IS PRELIMINARY SUPPORT FOR CUSTOM PACKET HANDLING! New events will be introduced before this is completed.
Fires the AccountCreated event.
The event arguments.
Fires the AccountCreationFailed event.
The event arguments.
Fires the ChannelDidNotExist event.
The event arguments.
Fires the ChannelListReceived event.
The event arguments.
Fires the ChannelWasFull event.
The event arguments.
Fires the ChannelWasRestricted event.
The event arguments.
Fires the ClanCandidatesSearchCompleted event.
The event arguments.
Fires the ClanChangeChieftanCompleted event.
The event arguments.
Fires the ClanDisbandCompleted event.
The event arguments.
Fires the ClanFormationCompleted event.
The event arguments.
Fires the ClanFormationInvitationReceived event.
The event arguments.
Fires the ClanInvitationReceived event.
The event arguments.
Fires the ClanInvitationResponseReceived event.
The event arguments.
Fires the ClanMemberListReceived event.
The event arguments.
Fires the ClanMemberQuit event.
The event arguments.
Fires the ClanMemberRemoved event.
The event arguments.
Fires the ClanMembershipReceived event.
The event arguments.
Fires the ClanMemberStatusChanged event.
The event arguments.
Fires the ClanMessageOfTheDay event.
The event arguments.
Fires the ClanRankChanged event.
The event arguments.
Fires the ClanRemovalResponse event.
The event arguments.
Fires the LeftClan event.
The event arguments.
Fires the ClientCheckFailed event.
The event arguments.
Fires the ClientCheckPassed event.
The event arguments.
Fires the CommandSent event.
The event arguments.
Fires the EnteredChat event.
The event arguments.
Fires the FriendAdded event.
The event arguments.
Fires the FriendListReceived event.
The event arguments.
Fires the FriendMoved event.
The event arguments.
Fires the FriendRemoved event.
The event arguments.
Fires the FriendUpdated event.
The event arguments.
Fires the Error event.
The event arguments.
Fires the Information event.
The event arguments.
Fires the InformationReceived event.
The event arguments.
Fires the JoinedChannel event.
The event arguments.
Fires the LoginFailed event.
The event arguments.
Fires the LoginSucceeded event.
The event arguments.
Fires the MessageSent event.
The event arguments.
Fires the ServerBroadcast event.
The event arguments.
Fires the ServerErrorReceived event.
The event arguments.
Fires the WhisperSent event.
The event arguments.
Fires the UserEmoted event.
The event arguments.
Fires the UserFlagsChanged event.
The event arguments.
Fires the UserJoined event.
The event arguments.
Fires the UserLeft event.
The event arguments.
Fires the UserProfileReceived event.
The event arguments.
Fires the UserShown event.
The event arguments.
Fires the UserSpoke event.
The event arguments.
Fires the WhisperReceived event.
The event arguments.
Fires the WhisperSent event.
The event arguments.
Specifies types of chat events that may occur.
Specifies an invalid chat event type.
Indicates that another user was already in the current channel when it was joined by the client.
Indicates that another user has joined the current channel.
Indicates that another user has left the current channel.
Indicates that another user has whispered the client.
Indicates that a user in the current channel spoke.
Indicates that a server operator has broadcast a message.
Indicates that the client joined a new channel.
Indicates that a user's channel properties have been updated.
Indicates that a whisper was sent.
Indicates that a channel join failed because the channel is full.
Indicates that a channel view failed because the channel does not exist.
Indicates that a channel join failed because the channel is restricted.
Indicates that the server is relaying information, perhaps from a command.
Indicates that there was a command error.
Indicates that a user has performed an emote.
Specifies additional information about a person on your friend list.
No additional information is provided.
The user also listed you as a friend.
The user has flagged themselves as do-not-disturb.
The user is away.
Specifies the event arguments for a clan member's status change event.
Provides the base class from which all BN# event argument class should derive.
Creates a new instance of BaseEventArgs.
Gets a new empty BaseEventArgs object for a specified event data object. This method is not CLS-compliant.
The client parsing data.
An empty instance with the specified client parsing data.
This method is provided as infrastructure code for WCF services. This allows inheritence
to function correctly on all types derived from BaseEventArgs that are known to the server.
For more information, see the MSDN Library article "Data Contract Known Types" at
http://msdn.microsoft.com/en-us/library/ms730167.aspx
Gets or sets the underlying connection data that was used to drive this event. This property is not CLS-compliant.
Creates a new ClanMemberStatusEventArgs.
The members whose status has changed.
Gets the associated clan member.
When exposed under a WCF data contract, this property's backing store is given the name Member.
Specifies the contract for handlers of clan member status events.
The BattleNetClient that originated the event.
The event arguments.
A strongly-typed resource class, for looking up localized strings, etc.
Returns the cached ResourceManager instance used by this class.
Overrides the current thread's CurrentUICulture property for all
resource lookups using this strongly typed resource class.
Looks up a localized string similar to The account '{0}' does not exist. Attempting to create....
Looks up a localized string similar to Battle.net specified an invalid packet size..
Looks up a localized string similar to Invalid username and/or password..
Looks up a localized string similar to The server rejected your password..
Looks up a localized string similar to The server rejected your password with a specific error message: '{0}'.
Looks up a localized string similar to Logon success! Battle.net has requested that you register an e-mail address with this account. You will not be notified again..
Looks up a localized string similar to The server was unable to verify that it knew your password; you may be connecting to a malicious server..
Looks up a localized string similar to Logon success! Entering chat....
Looks up a localized string similar to The specified user name contained too few alphanumeric characters..
Looks up a localized string similar to The specified user name contained too many adjacent punctuation characters..
Looks up a localized string similar to The specified user name contained too many punctuation characters..
Looks up a localized string similar to The specified user name was too short or blank. User names should be at least 3 characters long..
Looks up a localized string similar to The specified user name contained one or more illegal characters..
Looks up a localized string similar to The specified user name contained one or more illegal words..
Looks up a localized string similar to The specified user name already exists..
Looks up a localized string similar to Successfully created account name '{0}'. Logging in....
Looks up a localized string similar to Chat client.
Looks up a localized string similar to Diablo II (Retail).
Looks up a localized string similar to Diablo 2: Shareware.
Looks up a localized string similar to Diablo II: The Lord of Destruction.
Looks up a localized string similar to Diablo Classic (Retail).
Looks up a localized string similar to Diablo Classic (Shareware).
Looks up a localized string similar to Japan Starcraft.
Looks up a localized string similar to Starcraft: Brood War.
Looks up a localized string similar to Starcraft: Shareware.
Looks up a localized string similar to Starcraft (Retail).
Looks up a localized string similar to An Unknown Product or Client.
Looks up a localized string similar to Warcraft II: Battle.net Edition.
Looks up a localized string similar to Warcraft III: The Frozen Throne.
Looks up a localized string similar to Warcraft III: The Reign of Chaos.
Looks up a localized string similar to Battle.net has sent a packet that exceeds the maximum length supported..
Looks up a localized string similar to The connection was unable to complete a connection to {0}:{1} ('{2}'). More information is available in the exception..
Looks up a localized string similar to Your computer was unable to resolve host name '{0}'. If necessary, add an entry to %SystemRoot%\system32\drivers\etc\hosts, or flush your DNS resolver cache, and try again..
Looks up a localized string similar to Battle.net has requested that your account be upgraded, but this is not supported. Please upgrade your account via the official Warcraft III client..
Looks up a localized string similar to The Warcraft 3 server validation check failed. You may not be connecting to a legitimate Battle.net server..
Provides access to the loading and unloading of MPQ archives. This class cannot be instantiated or inherited.
Opens an MPQ archive at the specified path.
The path to the MPQ archive.
An MpqArchive instance representing the archive.
Thrown if there is an error with the MPQ archive.
Closes an MPQ archive.
The archive to close.
Specifies symbolic name IDs for Battle.net binary protocol messages.
Specifies SID_NULL (0x00)
Specifies SID_STOPADV (0x02)
Specifies SID_STARTADVEX (0x08)
Specifies SID_GETADVLISTEX (0x09)
Specifies SID_ENTERCHAT (0x0a)
Specifies SID_GETCHANNELLIST (0x0b)
Specifies SID_JOINCHANNEL (0x0c)
Specifies SID_CHATCOMMAND (0x0e)
Specifies SID_CHATEVENT (0x0f)
Specifies SID_LEAVECHAT (0x10)
Specifies SID_FLOODDETECTED (0x13)
Specifies SID_UDPPINGRESPONSE (0x14)
Specifies SID_CHECKAD (0x15)
Specifies SID_CLICKAD (0x16)
Specifies SID_MESSAGEBOX (0x19)
Specifies SID_STARTADVEX3 (0x1c)
Specifies SID_LOGONCHALLENGEEX (0x1d)
Specifies SID_LEAVEGAME (0x1f)
Specifies SID_DISPLAYAD (0x21)
Specifies SID_NOTIFYJOIN (0x22)
Specifies SID_PING (0x25)
Specifies SID_READUSERDATA (0x26)
Specifies SID_WRITEUSERDATA (0x27)
Specifies SID_LOGONCHALLENGE (0x28)
Specifies SID_LOGONRESPONSE (0x29)
Specifies SID_CREATEACCOUNT (0x2a)
Specifies SID_GAMERESULT (0x2c)
Specifies SID_GETICONDATA (0x2d)
Specifies SID_GETLADDERDATA (0x2e)
Specifies SID_FINDLADDERUSER (0x2f)
Specifies SID_CDKEY (0x30)
Specifies SID_CHANGEPASSWORD (0x31)
Specifies SID_QUERYREALMS (0x34)
Specifies SID_PROFILE (0x35)
Specifies SID_CDKEY2 (0x36)
Specifies SID_LOGONRESPONSE2 (0x3a)
Specifies SID_CREATEACCOUNT2 (0x3d)
Specifies SID_LOGONREALMEX (0x3e)
Specifies SID_QUERYREALMS2 (0x40)
Specifies SID_QUERYADURL (0x41)
Specifies SID_WARCRAFTGENERAL (0x44)
Specifies SID_NETGAMEPORT (0x45)
Specifies SID_NEWSINFO (0x46)
Specifies SID_OPTIONALWORK (0x4a)
Specifies SID_EXTRAWORK (0x4b)
Specifies SID_REQUIREDWORK (0x4c)
Specifies SID_AUTHINFO (0x50)
Specifies SID_AUTHCHECK (0x51)
Specifies SID_AUTHACCOUNTCREATE (0x52)
Specifies SID_AUTHACCOUNTLOGON (0x53)
Specifies SID_AUTHACCOUNTLOGONPROOF (0x54)
Specifies SID_AUTHACCOUNTCHANGE (0x55)
Specifies SID_AUTHACCOUNTCHANGEPROOF (0x56)
Specifies SID_AUTHACCOUNTUPGRADE (0x57)
Specifies SID_AUTHACCOUNTUPGRADEPROOF (0x58)
Specifies SID_SETEMAIL (0x59)
Specifies SID_RESETPASSWORD (0x5a)
Specifies SID_CHANGEEMAIL (0x5b)
Specifies SID_SWITCHPRODUCT (0x5c)
Specifies SID_WARDEN (0x5e)
Specifies SID_GAMEPLAYERSEARCH (0x60)
Specifies SID_FRIENDSLIST (0x65)
Specifies SID_FRIENDUPDATED (0x66)
Specifies SID_FRIENDADDED (0x67)
Specifies SID_FRIENDREMOVED (0x68)
Specifies SID_FRIENDPOSITION (0x69).
Specifies SID_CLANFINDCANDIDATES (0x70)
Specifies SID_CLANINVITEMULTIPLE (0x71)
Specifies SID_CLANCREATIONINVITATION (0x72)
Specifies SID_CLANDISBAND (0x73)
Specifies SID_CLANMAKECHEIFTAN (0x74)
Specifies SID_CLANINFO (0x75)
Specifies SID_CLANQUITNOTIFY (0x76)
Specifies SID_CLANINVITATION (0x77)
Specifies SID_CLANREMOVEMEMBER (0x78)
Specifies SID_CLANINVITATIONRESPONSE (0x79)
Specifies SID_CLANRANKCHANGE (0x7a)
Specifies SID_CLANSETMOTD (0x7b)
Specifies SID_CLANMOTD (0x7c)
Specifies SID_CLANMEMBERLIST (0x7d)
Specifies SID_CLANMEMBERREMOVED (0x7e)
Specifies SID_CLANMEMBERSTATUSCHANGED (0x7f)
Specifies SID_CLANMEMBERRANKCHANGE (0x81)
Specifies SID_CLANMEMBERINFORMATION (0x82)
Represents metadata about an icon from a Starcraft or Warcraft II: Battle.net Edition .BNI file. This class cannot be inherited.
To obtain an instance of this class, use the BniFileParser class.
Gets a string representation of this icon.
A string containing flags and product information.
Disposes the object, freeing any unmanaged and managed resources.
Gets the icon.
Gets the user flags that should be set in order for a user to display this icon.
If this value is None then the user should receive his or her product-defined icon,
available in the SoftwareProductCodes property.
Gets a list of the product codes that are eligible for this icon. If this list is empty, the icon is determined based on the
user's flags.
When implemented, provides the necessary settings to establish a Battle.net client connection.
Gets or sets the client product code.
There are seven clients that may be currently emulated using BN#:
Product Name
Product Code
-
Starcraft (Retail)
STAR
-
Starcraft: Brood War
SEXP
-
Warcraft II: Battle.net Edition
W2BN
-
Diablo II (Retail)
D2DV
-
Diablo II: The Lord of Destruction
D2XP
-
Warcraft III: The Reign of Chaos
WAR3
-
Warcraft III: The Frozen Throne
W3XP
Gets or sets the version byte.
The version byte is a value that cannot be reliably retrieved from game files. It can be found on most
web sites, or is generally updated on the JinxBot Wiki.
Gets or sets the Product CD key.
This property is required for all products.
Gets or sets the Expansion Product CD key, if applicable.
This property is only required when emulating Warcraft III: The Frozen Throne or Diablo II: Lord of Destruction. However,
when emulating the down-level clients, it will still be used if it is supported (for example, when logging onto Warcraft III: The
Reign of Chaos even though you have Warcraft III: The Frozen Throne installed).
Gets or sets the full or relative path to the executable file used for revision checking.
This file varies by client.
Product
File
-
Starcraft; Starcraft: Brood War
Starcraft.exe
-
Warcraft II: Battle.net Edition
Warcraft II BNE.exe
-
Diablo II; Diablo II: Lord of Destruction
Game.exe
-
Warcraft III: The Reign of Chaos; Warcraft III: The Frozen Throne
War3.exe
Gets or sets the full or relative path to the second file used for revision checking.
This file varies by client.
Product
File
-
Starcraft; Starcraft: Brood War; Warcraft II: Battle.net Edition;
Warcraft III: The Reign of Chaos; Warcraft III: The Frozen Throne
Storm.dll
-
Diablo II; Diablo II: Lord of Destruction
Bnclient.dll
Gets or sets the full or relative path to the third file used for revision checking.
This file varies by client.
Product
File
-
Starcraft; Starcraft: Brood War; Warcraft II: Battle.net Edition
Battle.snp
-
Diablo II; Diablo II: Lord of Destruction
D2Client.dll
-
Warcraft III: The Reign of Chaos; Warcraft III: The Frozen Throne
Game.dll
Gets or sets the name of the account that should be used to connect.
Gets or sets the full or relative path to the file used for Lockdown revision checking.
This property is not required for products other than Starcraft and Warcraft II: Battle.net Edition.
Gets or sets the password of the account used to connect.
Gets or sets the name or IP address of the server used to connect.
Gets or sets the port that should be used to connect.
The default port for Battle.net is 6112.
Gets or sets the name of the CD Key Owner.
This name is the one that appears if you attempt to log in with the CD key while it is already logged in.
Gets or sets the type of ping that should be used for the connection.
Handles the encryption and decryption of Warden modules for a given connection.
Creates a new WardenEncryptionContext with the specified seed.
The value with which to seed the encryption keys.
Encrypts an entire array.
The data to encrypt.
Thrown if is .
A new, encrypted array.
Encrypts a block of data using the current encryption key.
The data to encrypt.
The starting 0-based index to begin encryption.
The amount of data to encrypt.
Thrown if is .
Thrown if is negative, or if and
sum to greater than the length of .
A new, encrypted array.
Decrypts an entire array.
The data to encrypt.
Thrown if is .
A new, decrypted array.
Decrypts a block of data using the current decryption key.
The data to decrypt.
The starting 0-based index to begin decryption.
The amount of data to decrypt.
Thrown if is .
Thrown if is negative, or if and
sum to greater than the length of .
A new, decrypted array.
Specifies the contract for an event handler that wishes to handle the server news event.
The object that raised the event.
The event arguments.
Represents a single news entry.
Creates a new instance of ServerNewsEventArgs.
The entry for this news event.
Gets the news entry that triggered the event..
Specifies that a friend's status has been updated.
Creates a new FriendUpdatedEventArgs.
The friend that was updated.
Gets a reference to the friend that was updated.
When this property's backing store is serialized as part of a WCF data contract,
it is given the name Friend.
Specifies the contract for handlers wishing to listen for friend updated events.
The object that originated the event.
The event arguments.
Represents a Battle.net Clan member.
This class cannot be directly instantiated. Rather, it is provided when you log on via the TODO event.
Creates a new ClanMember for a user who is currently offline.
The clan member's user name.
The clan member's rank.
Creates a new ClanMember for a user who is online or offline.
The clan member's user name.
The clan member's rank.
The clan member's current status.
The name of the member's current location (such as a channel or game name).
Gets the user's name.
When exposed under a WCF data contract, this property's backing store is given the name Username.
Gets, and in derived classes sets, the user's current rank within the clan.
When exposed under a WCF data contract, this property's backing store is given the name Rank.
Gets, and in derived classes sets, the current location and status of the clan member.
When exposed under a WCF data contract, this property's backing store is given the name OnlineStatus.
Gets, and in derived classes sets, the user's current Battle.net location, if the user is online.
This property will return if the user is not online.
When exposed under a WCF data contract, this property's backing store is given the name Location.
Specifies the result of a search for clan candidates.
Creates a new ClanCandidatesSearchEventArgs for a request that was unsuccessful.
The status reported by Battle.net.
Creates a new ClanCandidatesSearchEventArgs for a request that was successful.
The status reported by Battle.net.
The list of candidate names provided by Battle.net.
Gets a read-only list of the candidate names returned as a result of the search.
When exposed under a WCF data contract, this property's backing store is given the name CandidateNames.
Gets the functional result of the search.
When exposed under a WCF data contract, this property's backing store is given the name Status.
Specifies the contract for event handlers that want to listen to clan candidates search events.
The object that originated the event.
The event arguments.
Specifies the flags that can be related to user-specific chat events.
Indicates that the user is normal.
Indicates that the user is a Blizzard representative.
Indicates that the user is a channel operator.
Indicates that the user has a Speaker icon.
Indicates that the user is a Battle.net Administrator.
Indicates that the user's client expects UDP support but lacks it.
Indicates that the user is currently squelched by the client.
Indicates a channel special guest.
Represented when the client had "beep" enabled, a client-side setting. No longer supported on Battle.net.
Represented PGL players. No longer seen on Battle.net.
Represented PGL officials. No longer seen on Battle.net.
Represented KBK players. No longer seen on Battle.net.
The flag for WCG officials.
Represented KBK singles players. No longer seen on Battle.net.
Represented beginner KBK players. No longer seen on Battle.net.
Represented a single bar for KBK players. No longer seen on Battle.net.
The flag for GF officials.
The flag for GF players.
The current flag for PGL players.
Implements a basic priority queue.
The type of item to queue.
Creates a new PriorityQueue.
Enqueues an item at the specified priority.
The Priority at which to enqueue the item.
The item to enqueue.
Thrown if is not a valid enumeration value.
Gets an item from the queue.
The next highest-priority item in the queue.
Thrown if the queue is empty.
Gets the current number of items in the queue.
When implemented, allows a class to provide custom packet parsing priorities for BN# via the
RegisterCustomPacketPriorities method.
BN# uses a layered approach to custom packet priorities. By default, all packet priorities
are Normal. Registering a new packet priority provider will allow the new provider to allow High or Low
priorities to be defined without needing to define priorities for all packets.
Once a lookup is performed for a given packet ID, the result is cached and reused. Consequently, changing
the priority value returned across multiple calls will only be reflected if the registered priority providers
change across calls, at which point the cache is invalidated.
The priority providers are checked in the most-recently-registered order; so consequently, if three
priority providers are registered in the order A, B, then C, then C will be checked first.
Determines whether the packet provider specifies a priority for the given packet ID.
The ID of the packet to look up.
if the packet ID is supported by this priority provider; otherwise
.
Gets a priority for the specified packet ID.
The packet ID to look up.
A Priority for the specified packet ID that determines its parse order.
Calculates the lockdown checkrevision.
The first game file
The second game file
The third game file
The value calculation string from the server
The version
The checksum
The result
The name of the lockdown file
The path to the screen dump
When implemented in a derived class, allows a custom image codec to be parsed to retrieve a .NET Image object.
Because of differences in file type and purpose, this class does not support working with images from .BNI files found in
Starcraft or Warcraft II: Battle.net Edition. To use those files, use the BniFileParser class instead.
Creates a new ImageParser.
Gets the size of the mipmap at the specified index.
The mipmap index. This value must be non-negative and less than the value reported by
the NumberOfMipmaps property.
A Size containing the dimensions of the mipmap at that index.
Thrown if is out of bounds.
Gets a new Image of the mipmap at the specified index.
The mipmap index. This value must be non-negative and less than the value reported by
the NumberOfMipmaps property.
An Image representation of the mipmap at the specified index.
Thrown if is out of bounds.
Disposes the parser, cleaning up managed and unmanaged resources.
Disposes the parser, cleaning up unmanaged and optionally managed resources.
Specifies whether to clean up managed resources.
Creates a new ImageParser for the file at the specified path.
The file to open.
An ImageParser ready to present images.
Thrown if is not found.
Thrown if the user does not have permission to open the file at
.
Thrown if the file format was invalid.
Thrown if is .
Creates a new ImageParser for the specified stream.
The stream to read.
An ImageParser ready to present images.
Thrown if the specified stream cannot seek.
Thrown if the file format was invalid.
Thrown if is .
Gets the number of mipmaps contained in this image.
Encompasses any revision check functionality for all Battle.net games.
This class cannot be inherited.
This class provides all CheckRevision-related support,
including file checksumming and EXE version information.
This type is safe for multithreaded operations.
These are the hashcodes for the various .mpq files.
Extracts the MPQ number from the MPQ specified by the Battle.net server.
For older CheckRevision calls, the MPQ number is a required parameter of the CheckRevision function. Note that the MPQ number is simply the number represented
in string format in the 8th position (index 7) of the string -- for example, in "IX86ver1.mpq", 1 is the version number.
The name of the MPQ file specified in the SID_AUTH_INFO message.
The number from 0 to 7 specifying the number in the MPQ file.
Thrown if the name of the MPQ version file is less than 8 characters long.
Thrown if the mpqName parameter is null (Nothing in Visual Basic).
Thrown if the mpqName parameter indicates a Lockdown DLL.
Calculates the revision check for the specified files.
The value string for the check revision function specified by Battle.net's SID_AUTH_INFO message.
The list of files for the given game client. This parameter must be exactly three files long.
The number of the MPQ file. To extract this number, see the
ExtractMPQNumber method.
The checksum value.
Thrown if the valueString or files parameters are null
(Nothing in Visual Basic).
Thrown if the files parameter is not a 3-string array.
Thrown if one of the specified game files is not found.
Thrown in the event of a general I/O error.
The file list for this is product-specific and order-specific:
Product
File list
-
Starcraft; Starcraft: Brood War
-
Starcraft.exe
-
storm.dll
-
battle.snp
-
Warcraft II: Battle.net Edition
-
Warcraft II BNE.exe
-
storm.dll
-
battle.snp
-
Diablo II; Diablo II: Lord of Destruction
-
Game.exe
-
Bnclient.dll
-
D2Client.dll
-
Warcraft III: The Reign of Chaos; Warcraft III: The Frozen Throne
-
War3.exe
-
storm.dll
-
Game.dll
Performs the Lockdown revision check.
The value string parameter, not including the null terminator.
The three game files. This parameter must be exactly three files long.
The path to the lockdown file requested.
The path to the screen dump.
[return value] The EXE version.
[return value] The EXE hash.
The "EXE Information" data. This value should be null-terminated when being inserted into the authorization packet.
The file list for this is product-specific and order-specific:
Product
File list
-
Starcraft; Starcraft: Brood War
-
Starcraft.exe
-
storm.dll
-
battle.snp
-
Warcraft II: Battle.net Edition
-
Warcraft II BNE.exe
-
storm.dll
-
battle.snp
Gets EXE information for the specified file.
The name of the file.
Returns the file's timestamp and other information.
The file's version.
Thrown if the fileName parameter is null (Nothing in Visual Basic).
Thrown if the file specified by fileName does not exist in the specified path.
Gets the current "version byte" for the specified product.
Only the following product IDs can be used with the web service: STAR, SEXP, W2BN, D2DV, D2XP,
WAR3, and W3XP. Other product IDs will result an a NotSupportedException
being thrown.
This method is new and currently in testing. W2BN, D2DV, and D2XP are currently
unsupported.
The four-character product ID for the product in question.
Thrown in all cases.
The version byte of the product.
Specifies the known reasons for a login failure to have occurred.
Specifies that an unknown reason caused the login failure.
Specifies that the selected account does not exist. This status is only available when the
ProvidesExtendedInformation property of the login
failure arguments is .
Specifies that either the account was not found, or that the password was invalid. For extended information check the
ProvidesExtendedInformation property of the login
failure arguments.
Specifies that the account has been closed. This status is only available when the
ProvidesExtendedInformation property of the login
failure arguments is .
Contains information about a situation in which the client failed to log into Battle.net.
Creates a new LoginFailedEventArgs that does not support extended information.
The login failure reason associated with this event.
The underlying message status code, which may be useful if the parameter is
Unknown.
Creates a new LoginFailedEventArgs that does supports extended information.
The login failure reason associated with this event.
The underlying message status code, which may be useful if the parameter is
Unknown.
Additional textual information optionally provided by the Battle.net server.
Gets whether information besides that an invalid username or password was provided.
Gets a textual reason for the login failure, if one was provided by the server.
This property is only meaningful if ProvidesExtendedInformation is .
Gets the literal status code returned from the server.
Gets the basic login failure reason.
Specifies the contract for handlers wishing to listen for login failure events.
The object that originated the event.
The event arguments.
The list of races that are supported by Warcraft III for Battle.net.
Specifies that the icon race sent from Battle.net was unrecognized.
Specifies that a user's icon is based on the random list.
Specifies that a user's icon is based on the tournament list.
Specifies that a user's icon is based on the human list.
Specifies that a user's icon is based on the orc list.
Specifies that a user's icon is based on the night elf list.
Specifies that a user's icon is based on the undead list.
Specifies the level of information available about a Battle.net user who is on the client's friend list.
Specifies that the user is offline.
Specifies that the user is not in a chat channel.
Specifies that the user is in a chat channel.
Specifies that the user is in a public game.
Specifies that the user is in a private (password-protected) game, but you are not mutual friends, and so the user's game information
will not be made available to you.
Specifies that the user is in a private (password-protected) game, but because you are mutual friends, you will be provided
the name of the game.
Specifies the ranks a clan member may have within a clan.
Specifies that the member is a new recruit who has been with the clan less than one week.
Specifies that the member is a new recruit who has been with the clan at least one week.
Specifies that the member is a regular clan member.
Specifies that the member is a clan officer.
Specifies that the member is the clan leader.
Specifies information provided to the client when being invited to join an existing clan.
Creates a new instance of ClanInvitationEventArgs.
The unique request ID specified by Battle.net.
The clan tag.
The clan name.
The name of the user inviting the client.
Gets the unique request ID associated with the invitation.
Gets the clan tag of the clan to which the client was invited.
Gets the name of the clan to which the client was invited.
Gets the name of the Battle.net user who invited the client to the clan.
Specifies the contract for handlers wishing to listen for clan invitation events.
The object that originated the event.
The event arguments.
Specifies information provided by Battle.net when the client attempts to form a clan.
Creates a new ClanFormationEventArgs indicating success.
Creates a new ClanFormationEventArgs indicating failure.
Whether the failure is due to users declining.
Whether the failure is due to users being unavailable.
The accounts that failed.
Gets whether the invitation succeeded.
When this property returns , the FailureAccountNames property will return a zero-length array.
When exposed under a WCF data contract, this property's backing store is given the name Succeeded.
Gets whether the invitation failed because users declined.
When exposed under a WCF data contract, this property's backing store is given the name Declined.
Gets whether the invitation failed because users were unavailable.
When exposed under a WCF data contract, this property's backing store is given the name Unavailable.
Gets a copy of the account names that failed being invited.
When exposed under a WCF data contract, this property's backing store is given the name FailedAccounts.
Specifies the contract for handlers wishing to listen for clan formation events.
The object that originated the event.
The event arguments.
Represents a Battle.net FTP (BnFTP) file transfer request for Version 1 products.
This class is only valid for Starcraft Retail, Starcraft: Brood War, Diablo II Retail,
Diablo II: Lord of Destruction, and Warcraft II: Battle.net Edition clients. For Warcraft III: The Reign
of Chaos and Warcraft III: The Frozen Throne, use the BnFtpVersion2Request
class.
Represents a generic Battle.net FTP (BnFTP) request.
The specific Battle.net FTP protocol is implemented by the
BnFtpVersion1Request and
BnFtpVersion2Request classes, which
have their uses based on which client is being emulated. For Warcraft 3 and
The Frozen Throne, BnFtpVersion2Request should be used; otherwise,
BnFtpVersion1Request should be used.
Creates a new generic Battle.net FTP request.
The name of the file to be downloaded.
The four-character product string specifying the
client being emulated.
The timestamp of the file's last write in UTC.
You may specify null (Nothing in Visual Basic) if the
time is unavailable.
Valid emulation clients include:
- STAR for Starcraft Retail
- SEXP for Starcraft: Brood War
- W2BN for Warcraft II: Battle.net Edition
- D2DV for Diablo II Retail
- D2XP for Diablo II: Lord of Destruction
- WAR3 for Warcraft III: The Reign of Chaos
- W3XP for Warcraft III: The Frozen Throne
Invokes the FilePartDownloaded event.
Note to Inheritors: The suggested way to hook the FilePartDownloaded event is to override this method. However, to
ensure that the event is called and all listeners receive it, be certain to call the base implementation as well.
The download status for this file.
Executes the BnFTP request, downloading the file to where LocalFileName
specifies, and closes the connection.
By default, LocalFileName is the same name as the remote file, which will cause the file
to be saved in the local application path. The desired location of the file must be set before
ExecuteRequest is called.
Thrown if the local file cannot be written.
Thrown if the remote host closes the connection prematurely.
Gets the Product string utilized by this request.
Indicates that part of a file has been downloaded during this request.
Gets or sets the local path of the file.
This property must be set before the ExecuteRequest method is
called. It can be changed in subsequent calls to download the same file to multiple locations; however,
changing this property will not affect files that have already been downloaded.
Gets the name of the filed being requested.
Gets (and in derived classes, sets) the size of the file.
This property is only valid after
ExecuteRequest has been called.
Gets the local file's last-write time, if it was specified. If it was not specified, this property
returns null (Nothing in Visual Basic).
Gets or sets the server from which this request should download.
The default server is useast.battle.net.
Creates a standard Version 1 Battle.net FTP request.
The four-character identifier for the product being emulated by this request.
The full or relative path to the file as it is to be stored on the local
machine. The name portion of the file must be the filename being requested from the service.
The last-write time of the file. If the file is not available, this parameter
can be null (Nothing in Visual Basic).
Creates a Version 1 Battle.net FTP request specifically for banner ad downloads.
The four-character identifier for the product being emulated by this request.
The full or relative path to the file as it is to be stored on the local
machine. The name portion of the file must be the filename being requested from the service.
The last-write time of the file. If the file is not available, this parameter
can be null (Nothing in Visual Basic).
The banner ID provided by Battle.net's ad notice message.
The banner filename extension provided by Battle.net's ad notice message.
Although it is not specifically required to download banner ads, it is recommended for forward-compatibility
with the Battle.net protocol that this constructor is used.
Executes the BnFTP request, downloading the file to where LocalFileName
specifies, and closes the connection.
By default, LocalFileName is the same name as the remote file, which will cause the file
to be saved in the local application path. The desired location of the file must be set before
ExecuteRequest is called.
Thrown if the local file cannot be written.
Thrown if the remote host closes the connection prematurely.
Provides a friend list received from the server.
Creates a new FriendListReceivedEventArgs.
The list of friends received from Battle.net.
Gets the friends list received from Battle.net.
When this property's backing store is serialized as part of a WCF data contract,
it is given the name Friends.
Specifies the contract for handlers wishing to listen for friend list received events.
The object that originated the event.
The event arguments.
Provides global resources preallocated for performance.
Registers a client connection, tracking it and increasing the available buffer pool.
The client connection that is being registered.
Unregisters a client connection, halting tracking and decreasing the available buffer pool.
The client connection being unregistered.
Gets the BufferPool used for incoming packets.
Gets the BufferPool used for outgoing packets.
Represents a Battle.net chat product. This class cannot be instantiated.
This class is primarily designed to provide information about products supported on Battle.net. In order to obtain an instance of it,
access one of the static fields. Equality can also be tested by comparing a user's product to an instance retrieved from the fields exposed
by this class.
The Product object for a telnet chat client.
The Product object for Starcraft (Retail).
The Product object for Starcraft Shareware.
The Product object for Starcraft: Brood War.
The Product object for Japan Starcraft.
The Product object for Warcraft II: Battle.net Edition.
The Product object for Diablo (Retail).
The Product object for Diablo (Shareware).
The Product object for Diablo 2 Shareware.
The Product object for Diablo 2 (Retail).
The Product object for Diablo 2: The Lord of Destruction.
The Product object for Warcraft 3: The Reign of Chaos.
The Product object for Warcraft 3: The Frozen Throne.
The Product object that represents any product unrecognized by BN#.
Gets the Product associated with the specified product code.
The four-character product code to check.
A Product object associated with the product code if it is found; otherwise .
Gets an array of all supported products.
An array of recognized products.
Gets the product code for this Product.
Gets the name of this product.
If localized resources exist for the current language, they are retrieved.
Specifies that a friend has moved position in the client's list of friends (for example, by being promoted or demoted).
Creates a new FriendMovedEventArgs.
The friend whose position changed.
The new 0-based index of the friend's position.
Gets a reference to the friend whose position changed.
When this property's backing store is serialized as part of a WCF data contract,
it is given the name Friend.
Gets the new position of the friend (0-based).
When this property's backing store is serialized as part of a WCF data contract,
it is given the name NewIndex.
Specifies the contract for handlers wishing to listen for friend moved events.
The object that originated the event.
The event arguments.
Contains event data about when the client's user account leaves a clan.
Creates a new LeftClanEventArgs.
Specifies whether the client was removed from the clan.
Gets whether the client was removed from the clan by a leader.
If this property returns , it means that the user left of his or her own accord.
Specifies the contract for handlers wishing to listen for client clan departure events.
The object that originated the event.
The event arguments.
Specifies the possible results when attempting to remove a clan member with RemoveClanMember.
Specifies that the member was successfully removed.
Specifies that Battle.net failed to remove the user from the clan.
Specifies that the member is too new to be removed from the clan.
Specifies that the client is not authorized to remove that member.
Specifies that the user is not allowed to be removed.
Specifies the status of an attempt to designate a new clan leader.
Creates a new ClanChieftanChangeEventArgs.
The result code from Battle.net.
Gets the result of the change attempt.
When exposed under a WCF data contract, this property's backing store is given the name Result.
Specifies the contract for handlers wishing to listen for clan chieftan change command events.
The object that originated the event.
The event arguments.
Specifies the contract for event handlers that want to listen to the Information event.
The object that raised the event.
The event arguments.
Specifies informational event arguments.
Initializes a new InformationEventArgs.
The information to pass.
Gets the information for the event.
Specifies the causes of client versioning failure reported by Battle.net.
Indicates that client checks passed.
Indicates that the client should upgrade.
Indicates that the version checksum was invalid.
Indicates that the client is using a newer version than is currently supported.
The CD key was invalid.
The CD key is already in use.
The CD key has been banned.
The CD key was for the wrong product.
Indicates that the expansion CD key was invalid.
Indicates that the expansion CD key is already in use.
Indicates that the expansion CD key was banned.
Indicates that the expansion CD key was for the wrong product.
Provides the base information about a chat event.
Initializes a new ChatEventArgs.
The event type.
Gets the type of chat event that took place.
The event arguments for the clan member list notification.
Creates a new instance of ClanMemberListEventArgs.
The clan members in the list.
Gets the list of members received from Battle.net.
When exposed under a WCF data contract, this property's backing store is given the name Members.
Specifies the contract for clan member list events.
The BattleNetClient connection that originated the event.
The event arguments.
Specifies the status of a clan candidates search.
Indicates that the search was a success and that the tag is available.
Indicates that the requested tag is already taken.
Indicates that the client user is already in a clan.
Specifies the tag requested was invalid.
Specifies the contract for chat events that involve another user, but not specifically communication.
The object that raised the event.
The event arguments.
Specifies event information for chat events that involve another user, but not specifically communication.
An example of when this class would be used is for a user joined or user left event.
Creates a new UserEventArgs with the specified settings.
The type of chat event.
A reference to the user involved in the event.
Gets a reference to the user who was involved in the event.
Calculates hash values for data using the old login-system
checks.
This method of logon would be used in down-level clients
using the SID_CLIENTID, SID_CLIENTID2, or SID_AUTH_INFO
messages specifying the login style 0 (Old login
system).
This type is safe for multithreaded operations.
Calculates the single "broken" SHA-1 hash of the specified
data.
The data buffer to hash.
A 20-byte buffer containing the hash value.
Calculates the single "broken" SHA-1 hash of the specified
password using ASCII encoding.
The password to hash.
A 20-byte buffer containing the hash value.
Calculates the double-pass "broken" SHA-1 hash of the
specified data.
The data buffer to hash.
The client token,
a randomly-generated value specified by the client.
The server token, a
randomly-generated value specified by the server.
A 20-byte buffer containing the hash value.
Calculates the double-pass "broken" SHA-1 hash of the
specified password using ASCII encoding.
The password to hash.
The client token,
a randomly-generated value specified by the client.
The server token, a
randomly-generated value specified by the server.
A 20-byte buffer containing the hash value.
Calculates the double-pass "broken" SHA-1 hash of the
specified password using ASCII encoding. This method is
not CLS-compliant.
The password to hash.
The client token,
a randomly-generated value specified by the client.
The server token, a
randomly-generated value specified by the server.
A 20-byte buffer containing the hash value.
Calculates the double-pass "broken" SHA-1 hash of the
specified data. This method is not CLS-compliant.
The data buffer to hash.
The client token,
a randomly-generated value specified by the client.
The server token, a
randomly-generated value specified by the server.
A 20-byte buffer containing the hash value.
Implements a pool of byte arrays to improve allocation performance when parsing data.
This type is safe for multithreaded operations.
Creates a new buffer pool with the specified name, buffer sizes, and buffer count.
The name of the pool.
The size of the preallocated buffers.
The number of preallocated buffers that should be available.
Thrown if or
are zero or negative.
Determines whether the specified buffer is already free.
The buffer to check.
if the buffer is freed; otherwise .
Gets a buffer from the available pool if one is available, or else allocates a new one.
Buffers retrieved with this method should be returned to the pool by using the
FreeBuffer method.
A byte[] from the pool.
Returns the specified buffer to the pool.
if the buffer belonged to this pool and was freed; otherwise .
If the ClearOnFree property is , then the buffer will be zeroed before
being restored to the pool.
The buffer to return to the pool.
Thrown if is .
Increases the number of buffers available in the pool by a given size.
The number of buffers to preallocate.
Thrown if the system is unable to preallocate the requested number of buffers.
This method does not cause the NewBufferAllocated event to be raised.
Removes up to the specified number of buffers from the pool.
The number of buffers to attempt to remove.
The number of buffers actually removed.
The number of buffers removed may actually be lower than the number requested if the specified number of buffers are not free.
For example, if the number of buffers free is 15, and the callee requests the removal of 20 buffers, only 15 will be freed, and so the
returned value will be 15.
Fires the NewBufferAllocated event.
The event arguments.
Raises the BufferRequested event.
The event arguments.
Raises the BufferReturned event.
The event arguments.
Gets the name of this pool.
If no name is set, this property may return .
Gets the size of the buffers allocated from this pool.
Gets the maximum number of buffers available at any given time from this pool.
Gets the current number of buffers available for use.
Gets or sets whether to zero the contents of a buffer when it is freed.
The default value of this is ; however, it may be set to to achieve
a minor performance increase.
Informs listeners when a new buffer beyond the initial length has been allocated.
Informs listeners that a buffer has been allocated.
Informs listeners that a buffer has been freed.
Specifies the reasons for which an account may fail to be created.
Specifies that an unknown cause was responsible for the account creation failure.
Specifies that invalid characters (such as those in illies) was used.
Specifies that an invalid or banned word, such as a curse word, were in the name.
Specifies that the account name already exists.
Specifies that not enough alphanumeric characters were in the name.
Specifies that the name was too short or blank.
Specifies that too many punctuation characters were next to each other in the name.
Specifies that there were too many punctuation characters in the name.
Represents an MPQ file stream (that is, a stream within an MPQ file).
Disposes the MpqFileStream.
Cleans up unmanaged resources in use.
true if the object is being disposed; false if it is being finalized.
Reads data from the underlying stream into the specified buffer.
The buffer that will receive the data.
The starting location in the buffer to get the data.
The amount of data to be read.
Rather than throwing an exception, if the buffer is too small to return the requested amount of
data, only as much data as the buffer can hold is returned.
The number of bytes read.
Moves the current location within the stream to the specified location.
The offset relative to the seek origin.
The seek origin.
The new position in the file.
Flushes the buffer to the underlying stream.
Thrown whenever this method is called.
Sets the length of the underlying stream.
The new length.
Thrown whenever this method is called.
Writes to the stream.
The data to write.
The offset into the buffer to write.
The number of bytes to write.
Thrown whenever this method is called.
Gets the name of the file.
Gets whether the stream supports reading.
Gets whether the stream supports seeking.
Gets the length of the stream.
Gets or sets the offset from the beginning of the stream at which the stream is currently located.
Gets whether this stream supports writing.
Specifies the types of compression supported by a BLP2 image.
Specifies that the image uses JPEG compression.
Specifies that the image is palettized.
Specifies that the image uses DirectX-style compression.
Provides a parser for .bni files from Starcraft and Warcraft II: Battle.net Edition.
It is incorrect to attempt to use this class to read a Warcraft III .BNI file. Those files are .MPQ files, and should be read
using the MpqArchive class.
Creates a new BNI file parser to parse the specified file.
The path to the file to parse.
Thrown if the file specified in does not exist.
Thrown if the file contains data types that are unsupported by this implementation.
Creates a new BNI file parser from the specified stream.
The stream to load.
Thrown if is .
Thrown if the file contains data types that are unsupported by this implementation.
Disposes the object, freeing any managed and unmanaged resources.
Gets the full image.
Gets all icons and their associated metadata.
Represents a user profile request key. This class cannot be inherited.
Gets a user profile key for the specified type of statistic.
The type of statistic (ladder, non-ladder).
The type of record (wins, losses).
The client for which to request.
A non-writeable UserProfileKey.
Thrown if or
are values that are not defined by their enumerations.
If the product specified by was invalid, or if the
type of profile or record was not appropriate for the client (for example, IronMan Ladder is only valid for Warcraft II:
Battle.net Edition).
Gets the profile key corresponding to the user's Sex entry.
This field is defunct in Starcraft and Warcraft III.
Gets the profile key corresponding to the user's Age entry.
This field is defunct on all Battle.net clients.
Gets the profile key corresponding to the user's Location entry.
This key may be used when writing the user profile.
Gets the profile key corresponding to the user's Description entry.
This key may be used when writing the user profile.
Gets the profile key corresponding to the time of the last logon.
Gets the profile key corresponding to the time of the last logoff.
Gets the profile key corresponding to the total time logged in.
Gets the profile key corresponding to the account creation time.
Gets whether this key may be used when writing a profile update.
Specifies a user profile that has been populated by Battle.net.
Creates a new UserProfileEventArgs with the specified profile.
The profile that had been populated.
Gets the user profile result from the request.
Specifies the contract for handlers wishing to listen for user profile events.
The object that originated the event.
The event arguments.
Specifies the types of responses when attempting to invite a user to join a clan.
Indicates that the user accepted the invitation.
Indicates that the user declined the invitation.
Indicates that Battle.net was unable to invite the user (for instance, the user was not online).
Indicates that the clan is full.
Contains information about an attempt to disband the client's clan.
Creates a new ClanDisbandEventArgs.
Whether the disband succeeded.
Gets whether the disband succeeded.
The disband may fail if the client is not the clan leader, or if the clan is not at least one week old.
When exposed under a WCF data contract, this property's backing store is given the name Succeeded.
Specifies the contract for handlers wishing to listen for clan disband events.
The object that originated the event.
The event arguments.
Wraps an I/O exception with MPQ-specific errors.
Creates an MPQ exception with no exception information.
Creates an MPQ exception with the specified message.
The error message related to the exception.
Creates an MPQ exception with the specified message and inner exception.
The error message related to the exception.
A related exception that caused this exception.
Creates an MPQ exception from serialized data.
The serialization info.
The serialization streaming context.
Completes a DataBuffer implementation with the additional
data used by the BNCS protocol.
When using this class with a Stream, the BncsReader only takes the next packet's data
off of the stream. An ideal example of this would be when using a NetworkSteam
to connect to Battle.net. Incidentally, this constructor and method will block execution until new data has arrived. Therefore,
if your main receiving loop is going to use these methods, it should be on a background worker loop.
Operates as a buffered data reader for network and file input.
This class does not write data in any manner; for writing or sending data,
use the DataBuffer or derived classes.
This class always uses little-endian byte ordering.
Creates a new data reader with the specified stream as input.
This constructor will block until a full packet has been returned.
The stream from which to read.
The length of the data to read from the stream.
Creates a new data reader with the specified byte data.
The data to read.
Reads a boolean value from the data stream.
This method interprets a 32-bit value from the stream as false if it is zero and true if it is nonzero.
The next boolean value from the data stream.
Reads a byte value from the data stream.
The next byte from the data stream.
Reads a byte array from the data stream.
The number of bytes to read from the stream.
The next expectedItems bytes from the stream.
Reads a null-terminated byte array from the data stream.
The return value includes the null terminator.
The next byte array in the stream, terminated by a value of 0.
Reads a signed 16-bit value from the data stream.
The next 16-bit value from the data stream.
Reads an array of signed 16-bit values from the data stream.
The number of 16-bit values to read from the stream.
The next expectedItems 16-bit values from the stream.
Reads an unsigned 16-bit value from the data stream.
This method is not CLS-compliant.
The next 16-bit value from the data stream.
Reads an array of unsigned 16-bit values from the data stream.
This method is not CLS-compliant.
The number of 16-bit values to read from the stream.
The next expectedItems 16-bit values from the stream.
Reads a signed 32-bit value from the data stream.
The next 32-bit value from the data stream.
Reads an array of signed 32-bit values from the data stream.
The number of 32-bit values to read from the stream.
The next expectedItems 32-bit values from the stream.
Reads an unsigned 32-bit value from the data stream.
This method is not CLS-compliant.
The next 32-bit value from the data stream.
Reads an array of signed 32-bit values from the data stream.
This method is not CLS-compliant.
The number of 32-bit values to read from the stream.
The next expectedItems 32-bit values from the stream.
Reads a signed 64-bit value from the data stream.
The next 64-bit value from the data stream.
Reads an array of signed 64-bit values from the data stream.
The number of 64-bit values to read from the stream.
The next expectedItems 64-bit values from the stream.
Reads an unsigned 64-bit value from the data stream.
This method is not CLS-compliant.
The next 64-bit value from the data stream.
Reads an array of unsigned 64-bit values from the data stream.
This method is not CLS-compliant.
The number of 64-bit values to read from the stream.
The next expectedItems 64-bit values from the stream.
Reads the next byte in the stream but does not consume it.
A byte value (0-255) if the call succeeded, or else -1 if reading past the end of the stream.
Peeks at the next possible four-byte string with the specified byte padding without advancing the index.
The byte used to pad the string to total four bytes.
The next 4-byte string, reversed, from the stream.
Reads the next possible four-byte string with the specified byte padding.
The byte used to pad the string to total four bytes.
The next 4-byte string, reversed, from the stream.
Reads the next C-style ASCII null-terminated string from the stream.
The next C-style string.
Reads the next C-style null-terminated string from the stream.
The encoding used for the string.
The next C-style string encoded with the specified encoding.
Reads the next pascal-style ASCII string from the stream.
The next pascal-style string.
Reads the next pascal-style string from the stream.
The encoding used for the string.
The next pascal-style string encoded with the specified encoding.
Reads the next wide-pascal-style string from the stream.
The next wide-pascal-style string.
Reads the next wide-pascal-style string from the stream.
The encoding used for the string.
The next wide-pascal-style string encoded with the specified encoding.
Returns the next variable-length string with the specified terminator character.
The terminator that should indicate the end of the string.
The encoding to use to read the string.
A variable-length string with no NULL (0) characters nor the terminator character.
Checks to see whether the offset from the current position lies within the stream and, if so, advances to
that position relative to the current location.
The number of bytes beyond the current position to advance to.
True if the position lies within the stream and the cursor was advanced; otherwise false.
Gets a hex representation of this buffer.
A string representing this buffer's contents in hexadecimal notation.
Gets a copy of the data used by the current instance. When overridden in a
derived class, allows this class to access an alternative data source.
Gets a reference to the underlying buffer.
Gets the length of the data.
Gets the current position within the stream.
Creates a new data reader with the specified stream as input.
The stream from which to read.
Thrown if str
is null (Nothing in Visual Basic).
Creates a new data reader with the specified byte data.
The data to read.
Thrown if data is
null (Nothing in Visual Basic).
Gets a hex representation of this data.
A string representing this buffer's contents in hexadecimal notation.
Gets the length of the data.
Thrown if this reader is not yet initialized.
Gets or sets the ID of the packet as it was specified when it was created.
Specifies that a friend has been removed from the client's friends list.
Creates a new FriendRemovedEventArgs.
The friend who was removed.
Gets a reference to the friend who was removed.
When this property's backing store is serialized as part of a WCF data contract,
it is given the name Friend.
Specifies the contract for handlers wishing to listen for friend removed events.
The object that originated the event.
The event arguments.
Contains information about the result of an attempt of the client to remove another member from the clan.
Creates a new ClanRemovalResponseEventArgs.
The request ID assigned to the request.
The response from the server.
Gets the request ID associated with the request.
Gets the user's or server's response to the request.
Specifies the contract for handlers wishing to listen for clan member removal response events.
The object that originated the event.
The event arguments.
Specifies the contract for chat events that do not involve another user.
The object that raised the event.
The event arguments.
Specifies event information for chat events that do not involve another user.
An example of when this class would be used is for a server broadcast, server information, or an error.
Creates a new ServerChatEventArgs with the specified information.
The type of event.
Event-specific flags that must be interpreted based on the event type.
Informational message from the server.
Gets the message from the server.
Gets the event-specific flags.
These must be interpreted based on the event type.
Contains download status information about a currently-executing Battle.net FTP request. This class cannot be inherited.
Gets the current length of the file that has been downloaded.
Gets the total length of the file to download.
Gets the name of the file being downloaded.
Indicates the method type that handles Battle.net FTP download status events.
The object that initiated this event.
Status information about the download.
The sender parameter is guaranteed to always be an instance of BnFtpRequestBase (or a derived class).
Contains information about when a BN# connection event handler callback raises an exception.
Battle.net-related events driven by BattleNetClient are guaranteed to execute sequentially, in the order in which they
were registered relative to other event handlers of their priority.
For example, consider a scenario in which there are three handlers registered for the UserJoined event;
one is registered at High Priority and two are registered at Low priority:
- High: Moderation.ChannelModerationHandler.client_UserJoined(System.Object, BNSharp.UserEventArgs)
- Low: Client.UI.ChatDisplay.client_UserJoined(System.Object, BNSharp.UserEventArgs)
- Low: Client.UI.ChannelDisplay.client_UserJoined(System.Object, BNSharp.UserEventArgs)
Unlike normal .NET event handlers, every one of those handlers are guaranteed to be called back, regardless of whether a prior handler caused an
exception to be thrown. However, if an exception is thrown, the EventExceptionThrown event
will be raised on the client. So, the sequence of external method calls that would happen in such an event, if the Moderation handler threw an exception,
would be something along these lines:
- ChannelModerationHandler.client_UserJoined (raises exception)
- BattleNetClient.EventExceptionThrown
- ChatDisplay.client_UserJoined
- ChannelDisplay.client_UserJoined
Typically, all listeners of the EventExceptionThrown event are not guaranteed to be called and follow normal .NET event semantics.
Gets a string representation of this event data.
The results of this method vary based on the type of build passed. For builds with the DEBUG constant defined,
the result will be a verbose response. For builds without it defined, it will limit itself to basic information. For
more information, see ToString(string).
A string representation of this event data.
Gets a string representation of this event data.
The type of representation to return. "v" results in verbose information; "b" results in basic information.
A string representation of this event data.
Assumes all parameters are not null.
Gets the Priority at which the event was executing.
Gets the Exception that is being reported.
Gets the Delegate that was being invoked during the failure.
Gets the name of the event that was being executed during the failure.
Gets the sender parameter of the method being invoked.
This property typically returns the BattleNetClient that was executing the event.
Gets the event arguments that were passed along to the method.
Specifies the contract for handlers wishing to listen for event exception events.
The object that originated the event (typically a BattleNetClient).
The event arguments.
Specifies the contract for chat events that involve another user and communication.
The object that raised the event.
The event arguments.
Represents the event information associated with a chat event with a given user and communication.
Creates a new instance of ChatMessageEventArgs with the given parameters.
The type of event.
The other user's flags.
The primarily involved user.
The message.
Gets the flags of the user.
Gets the name of the user who communicated.
Gets the message.
Specifies a key-value-based user profile. This class cannot be inherited.
Creates a new empty UserProfileRequest.
The name of the user being requested.
Creates a new UserProfileRequest with a number of keys.
The name of the user being requested.
The keys to initially add.
Adds a key to a profile request.
The key to retrieve.
Adds a list of keys to a profile request.
The keys to retrieve.
Gets the number of keys in this request.
Gets the name of the user whose profile this represents.
Gets the value returned from Battle.net for the specified key.
The key to look up.
The value returned from Battle.net.
You can obtain the keys by creating and maintaining references to them, or by treating this object as enumerable
(which means it can be used in a loop).
Contains information about a user who is logged on with a Warcraft III client.
When implemented in a derived class, provides statistical information about a user.
More specific information is available from most users by casting an object of this class to one of the
derived classes. Products and their relevant classes are provided in the following table:
-
Product
Stats subclass type
-
Starcraft Retail, Starcraft: Brood War, Starcraft Shareware, Japan Starcraft,
Warcraft II: Battle.net Edition, Diablo Retail, Diablo Shareware
StarcraftStats
-
Diablo II Retail, Diablo II: Lord of Destruction
Diablo2Stats
-
Warcraft III: The Reign of Chaos, Warcraft III: The Frozen Throne
Warcraft3Stats
-
Others (unknown clients)
DefaultStats
Parses a user statstring and returns an object representing the stats in a meaningful way.
The name of the user whose stats are being examined.
The stats of the user.
An instance of a class derived from UserStats based on the user's
Product. To check the product, check the
Product property.
Thrown if or
are .
More specific information is available from most users by casting an object of this class to one of the
derived classes. Products and their relevant classes are provided in the following table:
-
Product
Stats subclass type
-
Starcraft Retail, Starcraft: Brood War, Starcraft Shareware, Japan Starcraft,
Warcraft II: Battle.net Edition, Diablo Retail, Diablo Shareware
StarcraftStats
-
Diablo II Retail, Diablo II: Lord of Destruction
Diablo2Stats
-
Warcraft III: The Reign of Chaos, Warcraft III: The Frozen Throne
Warcraft3Stats
-
Others (unknown clients)
DefaultStats
Creates a default statistics object with information only about the product.
The product for which to create information.
An instance of UserStats with only product information.
When implemented in a derived class, gets the product with which the user is logged on.
When exposed under a WCF data contract, this property's backing store is given
the name Product.
When implemented in a derived class, gets the literal text of the stat string.
Gets the user's clan tag.
Gets the icon race used for the user.
Gets the icon tier used for the user.
Gets the level of the user.
Gets the Product with which the user is currently logged on.
Gets the user's literal statstring text.
Specifies the type of client ping that should be used.
Specifies that the connection should have normal ping.
Specifies that the connection should attempt to have a -1ms ping.
Specifies that the connection should attempt to have a 0ms ping.
Represents a news entry.
Creates a new NewsEntry with the specified timestamp and content.
The time at which the news was posted in UTC.
The content of the news.
Gets a string representation of this news entry.
A string of the date's long date string.
Gets the date at which this news was posted in local time.
Gets the text of the news entry.
When implemented, allows a custom class to handle Warden packets.
Initializes the Warden module with the specified CD key hash part, the native socket handle, and the game file.
The key hash part provided.
if successful; otherwise .
Uninitializes the Warden module.
Processes the warden challenge.
A copy of the original buffer sent by the server.
Represents statistics logged onto a Diablo II Realm character.
This class cannot be instantiated directly. To obtain an instance of this class, use
UserStats.Parse, and cast the result to this class.
This class is only meaningful if the user is logged on as a realm character. To determine
whether the user is logged on with a Realm character, check the IsRealmCharacter property.
Gets the name of the user's account. On Diablo II, this will always be prefixed with the asterisk (*), as this is the account
name to which whispering may be done.
Gets the number of acts the character has completed on the current difficulty level.
Gets the user's level.
Gets the character class for the user's character.
Gets the most recent difficulty level for the character.
Gets whether the character has completed the entire game.
This property is a utility provided as a shortcut, since you can determine whether the character has
completed the entire game based on the number of ActsCompleted, Difficulty, and
whether the character is a Lord of Destruction character.
Gets whether the character is male.
This property is a utility property provided as a shortcut, since you can determine the gender
of the character based on the CharacterClass property.
Gets whether the user's character is a ladder character.
Gets whether the user's character is currently dead.
Gets whether the user's character is hardcore.
Gets whether the user's character was created with the Lord of Destruction expansion.
Gets the user's Realm.
Gets the user's current character name.
Gets whether the user is logged on with a Realm character.
Gets the product currently in use by the user.
Gets the literal text of the statstring.
Gets information about the user's product when the product is otherwise unrecognized.
Gets the Product with which the user is currently logged on.
Gets the literal statstring text.
Specifies the type of record key to look up for statistics.
Specifies the Wins value.
Specifies the Losses value.
Specifies the Disconnects value.
Specifies the Last Game value.
Specifies the Last Game Result value.
Specifies the Rating value. This is only valid for Ladder and
IronManLadder profile record key requests.
Specifies the High Rating value. This is only valid for Ladder and
IronManLadder profile record key requests.
Specifies the Rank value. This is only valid for Ladder and
IronManLadder profile record key requests.
Specifies the High Rank value. This is only valid for Ladder and
IronManLadder profile record key requests.
Specifies result codes for an attempt to change the clan chieftan (leader).
Indicates that the change succeeded.
Indicates that the clan is less than a week old.
Indicates that the designee did not accept becoming chieftan.
Indicates that the request has failed.
Indicates that the client is not the present clan chieftan.
Indicates that the user does not exist, is not in the clan, or that the user has not been in the clan long enough.
Specifies priorities for data handling.
When using BNSharp for a simple client, use of the Priority enumeration is optional. However, if you want
to develop something such as an extremely secure channel moderation client, it is highly recommended that you utilize both
the prioritized packet parsing engine and the prioritized event handler system.
Specifies the highest priority. This enumeration value is 5.
Specifies the normal priority. This enumeration value is 3.
Specifies the lowest priority. This enumeration value is 1.
Provides utilities for decoding and otherwise validating
CD keys of Blizzard products. This class cannot be inherited.
This type is safe for multithreaded operations.
Creates a CD key decoder for the specified key.
This constructor only conducts initial validity checks to ensure that the CD key is valid; that is,
it checks for a valid key length (13, 16, or 26 characters) and checks that the characters are valid
for the key type. For example, Starcraft keys are numeric only, whereas Warcraft II, Diablo II, Lord
of Destruction, Warcraft III, and The Frozen Throne keys are alphanumeric.
Additional validity checks are conducted internally; however, these do not raise Exceptions. To
confirm the validity of a key after instantiation, call the CdKey.IsValid
property.
The CD key to initialize processing for.
Thrown if the value of cdKey is
null (Nothing in Visual Basic).
Thrown if the
CD key is an invalid length or does not pass initial
validity checks.
Creates a CD key decoder for the specified key.
This method only conducts initial validity checks to ensure that the CD key is valid; that is,
it checks for a valid key length (13, 16, or 26 characters) and checks that the characters are valid
for the key type. For example, Starcraft keys are numeric only, whereas Warcraft II, Diablo II, Lord
of Destruction, Warcraft III, and The Frozen Throne keys are alphanumeric.
Additional validity checks are conducted internally; however, these do not raise Exceptions. To
confirm the validity of a key after instantiation, call the CdKey.IsValid
property.
This method is only a wrapper for the CdKey constructor and provides no additional
functionality.
The CD key to initialize processing for.
Thrown if the value of key is
null (Nothing in Visual Basic).
Thrown if the
CD key is an invalid length or does not pass initial
validity checks.
An instance of the CdKey class
Gets the "Private" or "Value 2" value of the CD key.
This method returns null (Nothing in Visual Basic) if the CD key is not valid.
To check validity, use the IsValid property.
For Starcraft, Warcraft II: Battle.net Edition, Diablo II, or Lord of Destruction CD keys,
this value is a 4-byte array. It can be converted to an integer value with the
BitConverter class.
For Warcraft III: The Reign of Chaos and The Frozen Throne CD keys, this value is a 10-byte
array.
Computes the 20-byte hash value of the CD key.
The result of the hash calculation is used in the message 0x51 SID_AUTH_CHECK (from the client)
as well as 0x36 SID_CDKEY2.
Thrown if the object has not yet been
initialized.
A randomly-generated token value that is determined by session at the client.
A randomly-generated token value that is determined by session at the server.
A 20-byte array containing the hash value of the specified key.
Computes the 20-byte hash value of the CD key. This method is not CLS-compliant.
The result of the hash calculation is used in the message 0x51 SID_AUTH_CHECK (from the client)
as well as 0x36 SID_CDKEY2.
Thrown if the object has not yet been
initialized.
A randomly-generated token value that is determined by session at the client.
A randomly-generated token value that is determined by session at the server.
A 20-byte array containing the hash value of the specified key.
Gets the CD key this object is processing.
Thrown if the object has not yet been
initialized.
Gets the product value encoded in the CD key.
This property returns 0 if the CD key is not valid. To check validity, use the
IsValid property.
Thrown if the object has not yet been
initialized.
Gets the "Public" or "Value 1" value of the CD key.
This property returns 0 if the CD key is not valid. To check validity, use the
IsValid property.
Thrown if the object has not yet been
initialized.
Gets the "Private" or "Value 2" value of the CD key.
This property returns null (Nothing in Visual Basic) if the CD key is not valid.
To check validity, use the IsValid property.
For Starcraft, Warcraft II: Battle.net Edition, Diablo II, or Lord of Destruction CD keys,
this value is a 4-byte array. It can be converted to an integer value with the
BitConverter class.
For Warcraft III: The Reign of Chaos and The Frozen Throne CD keys, this value is a 10-byte
array.
Gets whether or not the CD key is valid.
This property does not return whether or not this CD key is valid for Battle.net, but rather whether
the product's installer would accept the key as valid.
Thrown if the object has not yet been
initialized.
A strongly-typed resource class, for looking up localized strings, etc.
Returns the cached ResourceManager instance used by this class.
Overrides the current thread's CurrentUICulture property for all
resource lookups using this strongly typed resource class.
Looks up a localized string similar to The specified file was not found by Battle.net..
Looks up a localized string similar to Only Starcraft, Starcraft: Brood War, Diablo II Retail, Diablo II: the Lord of Destruction, and Warcraft II: Battle.net Edition (STAR, SEXP, D2DV, D2XP, and W2BN, respectively) can use BnFTP version 1..
Looks up a localized string similar to Only Warcraft III: the Reign of Chaos, and Warcraft III: the Frozen Throne (WAR3 and W3XP, respectively) can use BnFTP version 2..
Looks up a localized string similar to The value specified for the CD key is null..
Looks up a localized string similar to Extraction of MPQ number is not supported on Lockdown MPQs. The entire Lockdown DLL file must be passed into the Lockdown CheckRevision function. See the CheckRevision class documentation for more information..
Looks up a localized string similar to The file name cannot be null..
Looks up a localized string similar to You must specify a list of exactly three files for the revision check..
Looks up a localized string similar to You must specify a 3-file list for the revision check..
Looks up a localized string similar to The name of the MPQ version file must be greater than 7 characters long..
Looks up a localized string similar to The MPQ name parameter cannot be null..
Looks up a localized string similar to The value string parameter cannot be null for a revision check..
Looks up a localized string similar to D2DV.
Looks up a localized string similar to D2XP.
Looks up a localized string similar to The specified data buffer was null..
Looks up a localized string similar to The specified encoding parameter was null..
Looks up a localized string similar to {0} {1:d1}/{2:d2}/{3:d2} {4:d2}:{5:d2}:{6:d2} {7}.
Looks up a localized string similar to The specified file was not found..
Looks up a localized string similar to The specified value for the local file name was null..
Looks up a localized string similar to The CD key must be a valid 13-, 16-, or 26-character key..
Looks up a localized string similar to You cannot calculate the key hash on an invalid key..
Looks up a localized string similar to The CD key specified is not a valid Starcraft CD key..
Looks up a localized string similar to The CD key specified is not a valid Warcraft II/Diablo II/Lord of Destruction CD key..
Looks up a localized string similar to The CD key specified is not a valid Warcraft III/Frozen Throne CD key..
Looks up a localized string similar to The MPQ file was not able to be opened in the specified mode..
Looks up a localized string similar to The specified file could not be found in the MPQ archive..
Looks up a localized string similar to The MPQ file is corrupt..
Looks up a localized string similar to Unknown MPQ API error: {0}.
Looks up a localized string similar to The path to the MPQ file cannot be null..
Looks up a localized string similar to There is insufficient space in the data buffer for the account creation packet..
Looks up a localized string similar to There is insufficient space in the data buffer for the account login packet..
Looks up a localized string similar to There is insufficient space in the data buffer for the account login proof packet..
Looks up a localized string similar to The salt value was not 32 bytes..
Looks up a localized string similar to The server key was not 32 bytes..
Looks up a localized string similar to The server proof value must be exactly 20 bytes..
Looks up a localized string similar to The server signature must be exactly 128 bytes..
Looks up a localized string similar to The object you attempted to access has not yet been initialized. You must call the Initialize method on the object before it can be used..
Looks up a localized string similar to An object was already initiated at the call for initiation..
Looks up a localized string similar to An object was not initialized prior to use..
Looks up a localized string similar to cdKey.
Looks up a localized string similar to data.
Looks up a localized string similar to enc.
Looks up a localized string similar to fileName.
Looks up a localized string similar to len.
Looks up a localized string similar to mpqFilePath.
Looks up a localized string similar to productId.
Looks up a localized string similar to salt.
Looks up a localized string similar to serverKey.
Looks up a localized string similar to str.
Looks up a localized string similar to value.
Looks up a localized string similar to SEXP.
Looks up a localized string similar to STAR.
Looks up a localized string similar to The specified stream is null..
Looks up a localized string similar to The specified string is null..
Looks up a localized string similar to String length was too long; max length {0}..
Looks up a localized string similar to The specified parameter must be greater than zero (0)..
Looks up a localized string similar to W2BN.
Looks up a localized string similar to W3XP.
Looks up a localized string similar to WAR3.
Looks up a localized string similar to Cannot hash more than 1024 bytes..
Provides information about the client's user's current clan during login.
Creates a new instance of ClanMembershipEventArgs.
The tag of the clan to which the client belongs.
The rank within the clan of the client.
Gets your current rank within the clan.
When exposed under a WCF data contract, this property's backing store is given the name Rank.
Gets the tag of the clan to which you belong.
When exposed under a WCF data contract, this property's backing store is given the name Tag.
Specifies the contract for listeners that want to observe the clan membership event.
The BattleNetClient that originated the event.
The event arguments.
Supports the New Logon System's SRP (Secure Remote Password)
authentication system as well as Warcraft III server
signature validation. This class cannot be inherited.
This class does not monitor contexts to ensure that
its values are being modified in the appropriate sequence;
the NLS authorization scheme is left up to the consumer.
This type is safe for all multithreaded operations.
The modulus value used for login calculations.
The generator value used for login calculations.
The four-byte RSA server signature key used to decrypt
the server signatures.
The modulus used to calculate the server IP signature.
Creates a new NLS login context.
The username to use for authentication.
The password to use for authentication.
This type does not validate the sequence from moving from one message to the next. Ensure that you
have the correct sequence of calls.
An NLS context ID.
Verifies that the server's proof value matches the value
calculated by the client.
The 20-byte server proof.
Thrown if
the server proof value is not exactly 20 bytes.
Thrown if the object has not
yet been initialized.
This method should be called after the LoginProof method.
True if the server proof is valid;
otherwise false.
Adds the account login proof (for SID_AUTH_ACCOUNTLOGONPROOF)
to the specified stream at the current location.
The stream to modify.
The salt value, sent from the server
in SID_AUTH_ACCOUNTLOGON.
The server key, sent from the server
in SID_AUTH_ACCOUNTLOGON.
Thrown if
the salt or server key values are not exactly 32 bytes.
Thrown if the buffer does
not have enough space to add the account creation information.
Thrown if the object has not
yet been initialized.
The writeable length of the stream must be at least 20 bytes.
This method should be called after the LoginAccount method.
The total number of bytes written to the buffer.
Adds the account login proof (for SID_AUTH_ACCOUNTLOGONPROOF)
to the specified buffer at the specified location.
The buffer to modify.
The starting index at which to
modify the buffer.
The total number of bytes from
the starting index of the buffer that may be modified.
The salt value, sent from the server
in SID_AUTH_ACCOUNTLOGON.
The server key, sent from the server
in SID_AUTH_ACCOUNTLOGON.
Thrown if
the salt or server key values are not exactly 32 bytes.
Thrown if the buffer does
not have enough space to add the account creation information.
Thrown if the object has not
yet been initialized.
The writeable length of the buffer must be at least 20 bytes.
This method should be called after the LoginAccount method.
The total number of bytes written to the buffer.
Adds the account login proof (for SID_AUTH_ACCOUNTLOGONPROOF)
to the specified packet.
The BNCS packet to which to add the account logon data.
The salt value, sent from the server
in SID_AUTH_ACCOUNTLOGON.
The server key, sent from the server
in SID_AUTH_ACCOUNTLOGON.
Thrown if
the salt or server key values are not exactly 32 bytes.
Thrown if the object has not
yet been initialized.
This method should be called after the LoginAccount method.
The total number of bytes written to the buffer.
Adds the account login information (for SID_AUTH_ACCOUNTLOGON)
to the specified stream at the current location.
The stream to modify.
Thrown if the stream does
not have enough space to add the account creation information.
Thrown if the object has not
yet been initialized.
The writeable length of the stream must be at least 33 bytes plus the length of the username.
This method may be called first after creating the instance, or after the
CreateAccount method.
The total number of bytes written to the stream.
Adds the account login information (for SID_AUTH_ACCOUNTLOGON)
to the specified packet.
The packet to which to add the login information.
Thrown if the object has not
yet been initialized.
This method may be called first after creating the instance, or after the
CreateAccount method.
The total number of bytes written to the buffer.
Adds the account login information (for SID_AUTH_ACCOUNTLOGON)
to the specified buffer at the specified location.
The buffer to modify.
The starting index at which to
modify the buffer.
The total number of bytes from
the starting index of the buffer that may be modified.
Thrown if the buffer does
not have enough space to add the account creation information.
Thrown if the object has not
yet been initialized.
The writeable length of the stream must be at least 33 bytes plus the length of the username.
This method may be called first after creating the instance, or after the
CreateAccount method.
The total number of bytes written to the buffer.
Adds the account creation information (for SID_AUTH_ACCOUNTCREATE)
to the specified stream at the current location.
The stream to modify.
Thrown if the stream does
not have enough space to add the account creation information.
Thrown if the object has not
yet been initialized.
The writeable length of the stream must be at least 65 bytes plus the length of the user name.
This method must be called first if you are creating a new account.
The total number of bytes written to the stream.
Adds the account creation information (for SID_AUTH_ACCOUNTCREATE)
to the specified packet.
The packet to which to add the account creation information.
Thrown if the object has not
yet been initialized.
This method must be called first if you are creating a new account.
The total number of bytes written to the buffer.
Adds the account creation information (for SID_AUTH_ACCOUNTCREATE)
to the specified buffer at the specified location.
The buffer to modify.
The starting index at which to
modify the buffer.
The total number of bytes from
the starting index of the buffer that may be modified.
Thrown if the buffer does
not have enough space to add the account creation information.
Thrown if the object has not
yet been initialized.
The writeable length of the stream must be at least 65 bytes plus the length of the user name.
This method must be called first if you are creating a new account.
The total number of bytes written to the buffer.
Validates a Warcraft III server signature.
The server signature from
Battle.net's SID_AUTH_INFO message.
The IPv4 address of the server
currently connected-to.
True if the signature matches;
otherwise false.
Thrown if
the server signature is not exactly 128 bytes.
Specifies the contract for event handlers wishing to listen to the entered chat event.
The object that raised the event.
The event arguments.
Specifies the event arguments for when the client entered chat.
Creates a new instance of EnteredChatEventArgs.
The unique display name of the client.
The client's stat string.
The client's account name.
Gets the unique username assigned to the client.
Gets the user's client information string.
Gets the user's login account name.
Specifies the contract for clients wishing to register for the channel list event.
The object that raised the event.
The event arguments.
Specifies the channel list event arguments.
Creates a new instance of ChannelListEventArgs.
The channels to list.
Gets the copy of the list of channels sent by the server.
Represents statistics logged onto Battle.net with Starcraft, Japan Starcraft, Warcraft II: Battle.net Edition,
or the original Diablo.
This class cannot be instantiated directly. To obtain an instance of this class, use
UserStats.Parse, and cast the result to this class.
Gets whether the user is logged on with a spawned client.
Gets the icon code for the user issued by Battle.net.
Gets the user's highest ladder rating.
Gets the user's win count.
Gets the user's current ladder rank.
Gets the user's current ladder rating.
Gets the Product with which the user is logged on.
Gets the literal text of the user's statstring.
Represents a Battle.net friend user.
Creates a new FriendUser.
The 0-based index of the user's location.
The account name of the friend.
The friend's current status.
The friend's current location information.
The product with which the friend is currently logged on, otherwise .
The name of the friend's current location.
Gets, and in derived classes sets, the index (0-based) of the user on the client's friends list.
When exposed under a WCF data contract, this property's backing store is given
the name Index.
Gets, and in derived classes sets, the account name of the friend.
When exposed under a WCF data contract, this property's backing store is given
the name AccountName.
Gets, and in derived classes sets, a reference to the product information about the user's current logged on state.
This property will return if the user is currently offline.
When exposed under a WCF data contract, this property's backing store is given
the name Product.
Gets, and in derived classes sets, contextual information about the user's status.
This property will return if the user is currently offline.
When exposed under a WCF data contract, this property's backing store is given
the name Product.
Gets, and in derived classes sets, the type of location information provided by Battle.net.
When exposed under a WCF data contract, this property's backing store is given
the name LocationType.
Gets, and in derived classes sets, the name of the location of the current user.
When exposed under a WCF data contract, this property's backing store is given
the name Location.
Represents a user found in a channel.
Creates a new ChatUser.
Specifies the user's fully-qualified username, including possibly the character name,
name separator (for Diablo 2 characters), and realm namespace qualifier.
The user's latency.
The user's flags.
The user's stats.
The user's stats can be determined by passing the username and binary statsring value to
UserStats.Parse.
Gets, and in derived classes sets, the user's latency to Battle.net.
Gets, and in derived classes sets, user-specific flags.
Gets the user's full display name.
Gets the user's stats.
For more information about the user's stats, you should check the Product
property of the object and then cast to one of the descendant classes. For more information, see
UserStats.
Contains information about an account creation attempt that failed.
Contains information about an attempted account creation event.
Creates a new AccountCreationEventArgs for the specified account name.
The name of the account being created.
Gets the name of the account being created.
Creates a new AccountCreationFailedEventArgs for the specifiec account.
The name that failed to be created.
The reason provided by Battle.net for the failure.
Gets the reason for the account creation failure.
Specifies the contract for handlers wishing to listen for account creation failure events.
The object that originated the event.
The event arguments.
Specifies the contract for event handlers wishing to listen to the error event.
The object that raised the event.
The event arguments.
Specifies error event information.
Creates a new instance of ErrorEventArgs.
The error message.
Whether it is causing the client to disconnect.
The error message.
Whether it is causing the client to disconnect.
Specifies the contract for event handlers that want to handle the client versioning check failure event.
The object that raised the event.
The event arguments.
Specifies the arguments for a client versioning check failure event.
Creates a new instance of ClientCheckFailedEventArgs.
The failure code for version checking.
Additional information, if available.
Gets the reason provided by Battle.net.
Gets additional information, if any, provided by Battle.net about the problem.
Specifies the type of profile record keys that can be requested.
Specifies Normal. This is valid on Starcraft, Diablo, Warcraft II: Battle.net Edition, and Warcraft III.
Specifies Ladder. This is valid on Starcraft, Diablo, and Warcraft II: Battle.net Edition.
Specifies an Iron Man Ladder. This is only valid on Warcraft II: Battle.net Edition.
Specifies that a new friend was added to the list of friends.
Creates a new FriendAddedEventArgs.
The friend that was added to the list.
Gets a reference to the friend that was added.
When this property's backing store is serialized as part of a WCF data contract,
it is given the name NewFriend.
Specifies the contract for handlers wishing to listen for friend added events.
The object that originated the event.
The event arguments.
Represents a Battle.net FTP (BnFTP) file transfer request for Version 2 products.
This class is only valid for Warcraft III: The Reign of Chaos and Warcraft III: The Frozen Throne.
For Starcraft Retail, Starcraft: Brood War, Diablo II Retail, Diablo II: Lord of Destruction, and Warcraft
II: Battle.net Edition clients, use the BnFtpVersion1Request
class.
Creates a standard Version 2 Battle.net FTP request.
The four-character identifier for the product being emulated by this request.
The full or relative path to the file as it is to be stored on the local
machine. The name portion of the file must be the filename being requested from the service.
The last-write time of the file. If the file is not available, this parameter
can be null (Nothing in Visual Basic).
The CD key of the client being emulated.
Creates a Version 2 Battle.net FTP request specifically for banner ad downloads.
The four-character identifier for the product being emulated by this request.
The full or relative path to the file as it is to be stored on the local
machine. The name portion of the file must be the filename being requested from the service.
The last-write time of the file. If the file is not available, this parameter
can be null (Nothing in Visual Basic).
The CD key of the client being emulated.
The banner ID provided by Battle.net's ad notice message.
The banner filename extension provided by Battle.net's ad notice message.
Although it is not specifically required to download banner ads, it is recommended for forward-compatibility
with the Battle.net protocol that this constructor is used.
Executes the BnFTP request, downloading the file to where LocalFileName
specifies, and closes the connection.
By default, LocalFileName is the same name as the remote file, which will cause the file
to be saved in the local application path. The desired location of the file must be set before
ExecuteRequest is called.
Thrown if the local file cannot be written.
Thrown if the remote host closes the connection prematurely.
Provides functions for printing bytes to various output devices. This class cannot
be inherited.
This example demonstrates how the formatter prints out binary data.
DataFormatter.WriteToConsole(XSha1.CalculateHash(Encoding.ASCII.GetBytes("password")));
Output:
0000 ec c8 0d 1d 76 e7 58 c0 b9 da 8c 25 ff 10 6a ff ìE..vçXA.U.%ÿ.jÿ
0010 8e 24 29 16 .$).
Formats a data into 16-byte rows followed by an ASCII representation.
The data to format.
A string representing the data.
Thrown if data is null
(Nothing in Visual Basic).
Formats a data into 16-byte rows followed by an ASCII representation.
The data to format.
The starting position of the data to format.
The amount of data to format.
A string representing the data.
Thrown if data is null
(Nothing in Visual Basic).
Writes a series of bytes to the console, printing them in 16-byte rows
followed by an ASCII representation.
The data to print.
Writes a series of bytes to trace listeners, printing them in 16-byte rows,
followed by an ASCII representation.
The data to print.
Writes a series of bytes to trace listeners, printing them in 16-byte rows,
followed by an ASCII representation.
The data to print.
A category name to classify the data.
Specifies the flags that can be applied to channel-related chat events.
Specifies that the channel is a normal private channel.
Specifies that the channel is public.
Specifies that the channel is moderated by a Blizzard representative.
Specifies that the channel is restricted.
Specifies that the channel is silent.
Specifies that the channel is provided by the system.
Specifies that the channel is specific to a product.
Specifies that the channel is globally-accessible.
Sent to the client after the client has invited another user to join an existing clan.
Creates a new ClanInvitationResponseEventArgs.
The ID of the request assigned by the invitation.
The response from Battle.net.
Gets the ID of the associated invitation request.
Gets the server's response.
Specifies the contract for handlers wishing to listen for clan invitation response events.
The object that originated the event.
The event arguments.
Represents an MPQ archive.
Opens the specified file contained within the MPQ.
The path to the file relative to the MPQ root.
An MpqFileStream to the file within the MPQ.
Thrown if the file is not found or there is a problem reading from the MPQ.
Thrown if mpqFilePath is null (Nothing in Visual Basic).
Determines whether the archive contains the specified file.
The path to the file relative to the MPQ root.
True if the file is contained within the MPQ; otherwise false.
Saves the specified file to the provided path.
The fully-qualified name of the file in the MPQ.
The path to which to save the file.
The file is saved as an immediate child of the path specified in .
Saves the specified file to the specified path, optionally expanding the paths used in the MPQ.
The fully-qualified name of the file in the MPQ.
The root path to which to save the file.
Whether to create child directories based on the path to the file in the MPQ.
Called when the .NET Framework is removing this object from memory.
Disposes this archive.
If you call Dispose on an archive you do not need to call MpqServices.CloseArchive to close it.
Cleans up unmanaged resources used by this archive.
true if the object is being disposed; false if it is being finalized.
Gets the full text of the MPQ list file.
In later versions of Blizzard's games, the developers included a file called "(listfile)" in
most MPQ archives identifying the names of the files contained in the MPQ (since they are hashed and
therefore unavailable otherwise).
A string containing the full text of the list file.
Thrown if the list file is not located.
Specifies the difficulty level for Diablo II games and characters.
Specifies that the difficulty level is unrecognized.
Specifies the Normal difficulty level.
Specifies the Nightmare difficulty level.
Specifies the Hell difficulty level.
Specifies the current status of a clan member.
Specifies that the user is offline.
Specifies that the user is online but not in a channel or a game.
Specifies that the user is in a channel.
Specifies that the user is in a public game.
Specifies that the user is in a private game.
The ICommandQueueProvider interface is not yet supported in BN# Beta 2.
Determines whether sending a message of the specified length will cause a flood condition on the server.
The length of the message being tested.
if sending the message will cause a flood; otherwise .
Calculates the message delay and allows the command queue to perform any additional calculations for the message.
The length of the message being sent.
A value specifying the number of milliseconds to delay after sending the message.
Provides an implementation of Battle.net's "broken" (nonstandard) SHA-1
implementation. This class cannot be inherited.
This class does not derive from the standard
.NET SHA1
class, and also does not provide adequate security for independent
security solutions. See the System.Security.Cryptography
namespace for more information.
This type is safe for multithreaded operations.
Calculates the "broken" SHA-1 hash used by Battle.net.
The data to hash.
A 20-byte array containing the hashed result.
Specifies the compression type used by a BLP1 image.
Specifies that a BLP1 image is based on JPEG compression.
Specifies that a BLP1 image is palettized.
Specifies the character classes supported by Diablo 2 characters.
Specifies that the class is unknown or invalid.
Specifies the Amazon class (female).
Specifies the Sorceress class (female).
Specifies the Necromancer class (male).
Specifies the Paladin class (male).
Specifies the Barbarian class (male).
Specifies the Druid class (male).
Specifies the Assassin class (female).
Contains information about when the client's user's clan rank has changed.
Creates a new instance of ClanRankChangeEventArgs.
The previous rank.
The new rank.
The member who was responsible for the rank change.
Gets your previous clan rank.
When exposed under a WCF data contract, this property's backing store is given the name PreviousRank.
Gets your new clan rank.
When exposed under a WCF data contract, this property's backing store is given the name NewRank.
Gets the ClanMember who changed the rank.
When exposed under a WCF data contract, this property's backing store is given the name MemberResponsible.
Specifies the contract for when handlers want to take care of the event in which the client's clan rank has changed.
The BattleNetClient that originated the event.
The event arguments.
Specifies the event arguments provided from Battle.net when the client is invited to join a new clan.
Creates a new ClanFormationInvitationEventArgs.
The unique ID of the request.
The clan tag.
The full name of the new clan.
The user responsible for the invitation.
The users being invited.
Gets the unique ID of the request.
This value should be used in the response.
When exposed under a WCF data contract, this property's backing store is given the name RequestID.
Gets the Tag of the clan being formed.
When exposed under a WCF data contract, this property's backing store is given the name Tag.
Gets the full name of the clan being formed.
When exposed under a WCF data contract, this property's backing store is given the name Name.
Gets the screen name of the user sending the invitation.
When exposed under a WCF data contract, this property's backing store is given the name Inviter.
Gets a copy of the list of users being invited to join.
When exposed under a WCF data contract, this property's backing store is given the name InvitedUsers.
Specifies the contract for handlers wishing to listen for clan formation invitation events.
The object that originated the event.
The event arguments.
Specifies the contract for handlers wishing to listen for account creation events.
The object that originated the event.
The event arguments.