Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
 Posted: Wed Jan 27, 2010 1:21 am
How I wasted my programming day with Windows
|
I should probably put this into my Blog as a rant about Windows, but I'm just too tired.
Today I was trying to debug possible delay problems with TeSSH/CMUD. So I was adding some code to debug the Telnet Option Negotiation code. I decided to add a feature to log all Telnet Option negotiation messages to the Tools/MessageLog window.
When handling the NAWS decoding, I noticed that as I resized the screen, this Message Log window was not updating. I verified that the new window size was properly being sent to the MUD. Somehow the Message Log window itself wasn't updating.
The update code for this window is REALLY simple:
| Code: |
procedure UpdateMessageLog;
begin
MessageLog.Memo.Text := MessageCache.Text
end;
|
where MessageCache is an internal TStringList (list of strings) that gets added to whenever a log message needs to be displayed. For example, if you want to log a message to the Message Log window, CMUD does this:
| Code: |
MessageCache.Add('This is a new message line')
UpdateMessageLog
|
and the UpdateMessageLog code puts the MessageCache.Text into the MessageLog.Memo.Text component if the Message Log window is actually visible.
So why wasn't this working? Well, I spent ALL DAY on this crap. First I discovered that the above UpdateMessageLog was actually causing an Exception that was being trapped and ignored. What was the exception message? "Text exceeds Memo capacity". What the hell?
OK, so maybe the message log buffer was getting too full. I didn't think that the Memo control in Windows had any size limit anymore (was 64k bytes back in Win95 I think). So I just put some text code in it:
MessageLog.Memo.Text := 'test'
Guess what? It STILL gave an exception. What the hell is wrong with assigning a simple text string like this to a Windows Memo component??
My next guess was that maybe this was somehow getting called from a background thread. Windows doesn't like you to mess with a visual UI component from a background thread. So I added a line to display the current ThreadID to a debug file. Nope, that wasn't it...the code was properly running from the main UI thread.
So now what? I was tearing out my hair and swearing at the computer at this point. It just didn't make any sense at all. What was causing this "exceeds Memo capacity" exception??
I created a button on the form that manually sets the memo text to a test string. It worked! No exception. So why does setting the memo text work when triggered from a button on the form, but not when the NAWS string is being sent to the MUD?
I got out a tool that lets me debug Windows messages. I learned that the NAWS data was being sent from the WM_SIZE message handler in Windows. That makes sense...I have a Delphi onResize event handler set for the main MUD window. When the MUD window changes size, it sends the new NAWS data to the server if it supports that telnet option. Then it calls the routine to add that line to the Message Log.
So as a last resort, I changed the UpdateMessageLog routine to post a message to the Windows message queue to actually perform the update at a later time. In other words, now I have something like this:
| Code: |
procedure wmUpdateMessageLog(var Msg: TMessage) message wm_UpdateMessageLog;
begin
MessageLog.Memo.Text := MessageCache.Text
end;
procedure UpdateMessageLog;
begin
PostMessage( Handle, wm_UpdateMessageLog, 0, 0);
end;
|
Basically, this uses a custom Windows Event number (wm_UpdateMessageLog), and now the Update routine just posts that to the Windows message queue. When Windows processes this message, it calls the wmUpdateMessageLog routine, which actually updates the Memo text.
Yes, this worked. So the entire problem all day long was because of some obscure problem in Windows that doesn't allow you to update the contents of a Memo control while Windows is in the middle of processing a WM_SIZE message (even from a different window). This makes no sense to me. I have no idea if this is new to Windows 7. I'm too tired to try running this within VMware under WinXp to see what happens.
I'm just pissed that I wasted the whole day on crap like this and never did find any way to reproduce any connection delays with TeSSH. |
|
