Right Click on Nick In Hubframe fails after a while

do you mean right-clicks on nicks in the user list, in the chat, or both?
for the latter, does the standard context menu still appear?

could be related to user commands, try to test with/without them?

Sorry i was a bit vague. Right-clicks on nicks in main chat is the one it stops working on. Userlist works perfect.
When you click on one in main chat, it's just like clicking on any normal text:
Undo
Cut
Copy
Paste
Select All.

After removing my two existing user commands it still didn't work. Or after a reconnect.

i just committed a fix about the max chars limit that was set to 0 (or -1) so the chat probably dropped its first characters when its buffer was filled. now the function that makes sure the max chars limit is never hit (it cleans first TextLimit / 10 chars and makes sure whole lines are removed) should be working again.
could solve your issue, as you mentioned "active" chats.

That seems to have sorted it. :)
The amount of text the chat stores is a lot less but the right click menus are all working.

The patch is wrong in that it shortens the chat history...the real cause for this error probably lies in the way the character position is calculated for positions > 64k characters (short vs int)...The edit box is a mess in this regard and thus those parts probably need some attention to keep the long history and have correct behavior...

re-added these setTextLimit(0); lines. however something has to be changed in the addChat functions where the limit is checked:
int limit = chat->getTextLimit();
always returns -1 so the following methods used to split the first lines of chat are never called. hence the edit control probably removes characters 1 by 1 when its real limit is reached...
i've taken a look into the SmartWin code for edit messages and all integer types seem correct...

except that getTextLimit probably shouldn't be returning an int but a size_t or possibly a DWORD...-1 as size_t becomes a large positive number (max representable by a 32-bit unsigned int)...but this needs further investigation on msdn...with the 2000/xp edit controls, technically available memory should be the only limit for text length...we could then argue that we should limit the backlog to something smaller (how much smaller?)...

i remember i've had such a discussion before on a completely different project and that the conclusion was that it's very hard to predict how many characters you can put into an edit control. it depends not only on the limit that can be set by these TextLimit functions, but also on other factors like how much memory is available, etc.
that's why i removed setTextLimit(0); in order to let the system determine by itself how many max chars it thinks it can handle. in my case (WinXP), it was returning 30000.

here is an easy fix for that problem, tested by sending myself 1 thousand lines filled with 1 hundred letters each! before the fix, the user context menu stopped working exactly after 64K characters; now, it should theoritically handle 64K max lines with 64K chars each (which is a limit that hopefully won't be reached by anyone...).
the problem came from the EM_CHARFROMPOS message that returns a 16-bit character index; idea from http://www.autohotkey.com/forum/topic11239.html

as for the unrelated problem of characters that would be allocated 1 by 1 when the control doesn't have anymore space, http://msdn2.microsoft.com/en-us/library/ms997530.aspx says that this happens 32 bytes by 32 bytes. that article is old so it may even be better now in more recent versions of Windows... anyway, setTextLimit(0) and letting the system do the hard work when the control needs to find more space seems like a good solution.

[01:12] TLS disabled, failed to generate certificate: The system cannot find the file specified.
[01:12] Failed to load certificate file
[01:12] File list refresh initiated
[01:12] File list refresh finished