script processing can cause "auto-repeat command" to fail on rapid input

Posted by Fiendish on Thu 23 Jun 2011 08:23 PM — 2 posts, 8,193 views.

Fiendish USA Global Moderator Thu 23 Jun 2011 08:23 PM #0

This happens in Windows XP and Windows 7 using MUSHclient 4.75

A lot of script processing can disrupt the "auto-repeat command" option and cause MUSHclient to wipe out the input bar. Here is a trivial test plugin:


<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE muclient>
<muclient>
<plugin
   name="Test"
   author="Fiendish and Redryn"
   id="999999999999999999999999"
   language="Lua"
   purpose="test the input bug"
   date_written="2011-06-23 21:40:14"
   requires="4.75"
   version="1.0"
></plugin>

<aliases>
<alias
match="*"
enabled="y"
send_to="12"
sequence="100"
>
<send>
   for i = 1,100000000 do local pants=nil end
   Send("%1")
</send>
</alias>
</aliases>
</muclient>

With this plugin loaded, enter a command on the input line (e.g. "s" for south) and then hold down the enter key to send that command as fast as possible. The input line will get erased.

A smaller loop end count causes this to not happen. Adjustment of numbers may be necessary depending on the performance of your computer.

Nick Gammon Australia Forum Administrator Fri 24 Jun 2011 08:56 AM #1

Hmm. The code for handling a keypress did this:


void CSendView::OnChar(UINT nChar, UINT nRepCnt, UINT nFlags) 
{
CMUSHclientDoc* pDoc = GetDocument();
ASSERT_VALID(pDoc);

  if ((nChar == VK_RETURN) && (nRepCnt == 1))
  {
   // process command
  }

That is, the Enter key only got processed if you didn't hit it fast enough to trigger a repeat count.

I suppose I though that auto-repeating should not count as hitting enter hundreds of times, but removing the test for nRepCnt seems to fix the reported problem.