Wednesday, 13 February 2013
Fixing Visual Studio 2010 keyboard text selection
Short version: does shift-selecting blocks of text in Visual Studio, Word, Outlook, Notepad or other Windows apps mysteriously cancel your selection from time to time? The problem may be to do with your keyboard's PS2 to USB adapter. Skip to the end for an easy fix.
I spend a lot of time editing text. Sometimes, this is in Word or Vim, but mostly it's in Visual Studio's code editor. So, when something I'm used to breaks, something I do so often that it's hard-wired into my fingers, it gets my attention.
I often select blocks of text by holding down Shift, holding Cursor Down until the block of text has been selected, and then pressing Cursor Up to move back up a line or two. When I'm working quickly, I often press Cursor Up before releasing Cursor Down. And until recently, this would work perfectly - the Cursor Up stroke would take precedence over the repeating Cursor Down and things would smoothly come to a halt.
I started a new project recently which needed Visual Studio 2010 (I'd been using VS2008 until then). I installed VS2010 on a fresh development PC and pretty quickly noticed that whenever I tried to select a block of text, it would end up unselected again. Selecting it a second time, more carefully, worked fine. During periods of heavy editing, I might do this operation several times a minute, so this was DEEPLY AGGRAVATING.
I figured out that things worked fine as long as I released Cursor Down before pressing Cursor Up while making the selection. Unfortunately, training my fingers to do this was a lot harder than I expected, so the problem continued. Since I was only working on the VS2010 PC a couple of days a week, I was able to live with it. I checked Google, of course, but nobody else seemed to be suffering from this problem. I even used the Spy++ development tool to monitor keyboard messages going to the Visual Studio window, but nothing seemed amiss.
Over Christmas, I rebuilt my home office, incorporating some new monitors, KVMs, moving things around, etc. Soon after, I noticed the problem had spread to my main development PC. Worse, it turned out that applications other than Visual Studio were now being affected. Even Visual Studio 2008, which had been fine up until now, was suffering, as was Notepad, Outlook, and pretty much any application that accepted multi-line text input!
What was going on here? I checked a couple of my other PCs -- some of them were doing it, some of them not. Was this some sort of strange new virus with an unanticipated side-effect? Several full virus checks (all clean) suggested not. Both Windows 7 and Windows 8 systems were showing the problem, but I had other similar systems that were clear, as was Windows 2012. More intriguingly, when I connected to an afflicted system using remote desktop, the problem vanished. I even considered the issue might be related to a keyboard switch I was using to share a single keyboard & mouse between several PCs, but where I had such a setup, some of the PCs on the switch were fine, others were not.
At this point, I reckoned the cause must be some system utility I had installed on some but not all of the PCs, or possibly a Windows update. An audit of all such software didn't point to any culprits, however. And the problem continued to sit there, annoying the heck out of me on a daily basis.
Until finally, today, a break-through! I decided to connect an old PS/2 keyboard to my main PC at the same time as the USB KVM switch I was using day-to-day -- and using the old keyboard, the problem didn't occur! I then connected the PS/2 keyboard to a USB port, using a cheap PS2 to USB adapter, and the problem returned. It was something to do with the KVM after all.
The next step was to go back to Spy++ again and do some A/B comparisons. I used Notepad as my test application -- it's so simple that I figured there would be very little noise to get in the way. (I briefly had no output from Spy++, until I realised it could only monitor 32-bit applications on my Win7/64 PC; I fixed this by copying the 32-bit version of Notepad.exe across from a Win7 x86 system and monitoring that.)
Here's the pertinent output, showing the key sequence SHIFT, Down (held down to repeat several times), Up, release Down, release Up.
First, with the keyboard connected via USB:
P WM_KEYDOWN nVirtKey:VK_SHIFT cRepeat:1 Code:2A fExtended:0 fAltDown:0 fRepeat:0 fUp:0 P WM_KEYDOWN nVirtKey:VK_SHIFT cRepeat:1 Code:2A fExtended:0 fAltDown:0 fRepeat:1 fUp:0 P WM_KEYDOWN nVirtKey:VK_SHIFT cRepeat:1 Code:2A fExtended:0 fAltDown:0 fRepeat:1 fUp:0 P WM_KEYDOWN nVirtKey:VK_DOWN cRepeat:1 Code:50 fExtended:1 fAltDown:0 fRepeat:0 fUp:0 P WM_KEYUP nVirtKey:VK_DOWN cRepeat:1 Code:50 fExtended:1 fAltDown:0 fRepeat:1 fUp:1 P WM_KEYDOWN nVirtKey:VK_DOWN cRepeat:1 Code:50 fExtended:1 fAltDown:0 fRepeat:0 fUp:0 P WM_KEYUP nVirtKey:VK_DOWN cRepeat:1 Code:50 fExtended:1 fAltDown:0 fRepeat:1 fUp:1 P WM_KEYDOWN nVirtKey:VK_DOWN cRepeat:1 Code:50 fExtended:1 fAltDown:0 fRepeat:0 fUp:0 P WM_KEYUP nVirtKey:VK_DOWN cRepeat:1 Code:50 fExtended:1 fAltDown:0 fRepeat:1 fUp:1 P WM_KEYDOWN nVirtKey:VK_DOWN cRepeat:1 Code:50 fExtended:1 fAltDown:0 fRepeat:0 fUp:0 P WM_KEYUP nVirtKey:VK_SHIFT cRepeat:1 Code:2A fExtended:0 fAltDown:0 fRepeat:1 fUp:1 P WM_KEYDOWN nVirtKey:VK_UP cRepeat:1 Code:48 fExtended:1 fAltDown:0 fRepeat:0 fUp:0 P WM_KEYUP nVirtKey:VK_UP cRepeat:1 Code:48 fExtended:1 fAltDown:0 fRepeat:1 fUp:1 P WM_KEYUP nVirtKey:VK_DOWN cRepeat:1 Code:50 fExtended:1 fAltDown:0 fRepeat:1 fUp:1
Now the same sequence, using the PS/2 keyboard connected directly to the PS/2 port:
P WM_KEYDOWN nVirtKey:VK_SHIFT cRepeat:1 Code:2A fExtended:0 fAltDown:0 fRepeat:0 fUp:0 P WM_KEYDOWN nVirtKey:VK_SHIFT cRepeat:1 Code:2A fExtended:0 fAltDown:0 fRepeat:1 fUp:0 P WM_KEYDOWN nVirtKey:VK_SHIFT cRepeat:1 Code:2A fExtended:0 fAltDown:0 fRepeat:1 fUp:0 P WM_KEYDOWN nVirtKey:VK_DOWN cRepeat:1 Code:50 fExtended:1 fAltDown:0 fRepeat:0 fUp:0 P WM_KEYDOWN nVirtKey:VK_DOWN cRepeat:1 Code:50 fExtended:1 fAltDown:0 fRepeat:1 fUp:0 P WM_KEYDOWN nVirtKey:VK_DOWN cRepeat:1 Code:50 fExtended:1 fAltDown:0 fRepeat:1 fUp:0 P WM_KEYDOWN nVirtKey:VK_DOWN cRepeat:1 Code:50 fExtended:1 fAltDown:0 fRepeat:1 fUp:0 P WM_KEYDOWN nVirtKey:VK_UP cRepeat:1 Code:48 fExtended:1 fAltDown:0 fRepeat:0 fUp:0 P WM_KEYUP nVirtKey:VK_UP cRepeat:1 Code:48 fExtended:1 fAltDown:0 fRepeat:1 fUp:1 P WM_KEYUP nVirtKey:VK_DOWN cRepeat:1 Code:50 fExtended:1 fAltDown:0 fRepeat:1 fUp:1 P WM_KEYUP nVirtKey:VK_SHIFT cRepeat:1 Code:2A fExtended:0 fAltDown:0 fRepeat:1 fUp:1
There are two significant differences: the USB input seems to repeat keys by continually releasing and re-generating the keystroke (even though I had the Down key held down continually); more significantly, it generates an up-stroke for the Shift key as soon as I press Cursor Up (or indeed any other key, I discovered), before generating the Up keystroke -- essentially, the keyboard was not supporting N-key-rollover when connected via USB.
This second point is what was causing the problem, since if you select a block of text using Shift and then press Up on its own, it does indeed cancel the selection.
Okay, so now we have the cause - how to fix it? I knew from previous testing that a genuine USB keyboard didn't seem to exhibit this problem, so it must be something to do with my PS2 to USB adapter (actually, two different types, both with the same problem). I speculated that it might have something to do with the keyboard repeat speed -- perhaps Windows was simulating repeated keys in the USB driver if it thought the attached keyboard couldn't handle this itself, or perhaps the PS/2 keyboard's repeated codes were being remapped by the USB converter cable.
Next stop was to Control Panel -> Keyboard -> Speed where I tried setting the keyboard repeat speed to both its slowest and fastest setting. Amazingly, either setting fixed the problem completely! It seems that all you need to do is set the repeat speed to something other than the default; this magically makes things start behaving properly.
To confirm, I repeated my test with Spy++ and sure enough, the USB-connected keyboard is now correctly sending repeated KEY_DOWN codes and no longer sending a KEY_UP for Shift in advance of the Up keystroke being pressed. My guess is that this is a quirk of the built-in Windows USB keyboard driver, rather than something in the device itself, since identical behaviour occurred with two separate PS2 to USB converters.
So problem solved: I had adjusted the keyboard speed setting on some of my PCs, but not on others which is why the problem appeared to be so random.
Monday, 17 December 2012
Syncing sent mail between iPhone and Outlook
I use Outlook 2003 for most of my mail. However, since buying an iPhone last year, I've gradually been replying to more and more messages by phone. The convenience of being able to send a quick reply Right Now is great; it's one less email to deal with when I get back to my desk, and a good use of what would otherwise be dead time.
This creates a problem though: I use POP3 mail with Outlook so it doesn't see messages sent from my iPhone. If I want to check back on a reply weeks or months later, it can be difficult to locate.
To fix this, I have my iPhone configured to automatically BCC me on any messages or replies I send. This works but the BCC'd messages arrive in my Inbox as new messages which I then need to consciously ignore. They're also more difficult to find later on since I need to search my entire Inbox instead of just checking my Sent Items.
Today, I finally implemented a really simple, obvious solution I should have come up with months ago: using Outlook's Rules to automatically move such messages to the Sent Items folder. The trick is to use an obscure Rules feature that lets you check for specific keywords in the message header.
If you open any message sent from the iPhone in Outlook, and choose View Menu -> Options, you will see the full mail header. iPhone messages always have an X-Mailer header line reading "iPhone Mail (xxxx)". Outlook can use this to identify iPhone messages automatically and move them to Sent Items.
I don't want to move messages I receive from other iPhone users though, just messages sent from my iPhone. I also don't want to move messages sent to me - I often send myself iPhone messages to remind me to do things, or to quickly move photos from my phone to my desktop without having to sync. Outlook can handle both of these conditions by simply checking the To: and From: fields of the message.
Putting it altogether, I created a new Outlook Rule like this. (The steps are for Outlook 2003, but Outlook 2007/2010 should be similar):
- Select Rules and Alerts on the Outlook Tools menu
- Click to create a New Rule; start from a Blank rule, not a pre-defined template
- Turn on these conditions: From people or distribution list, and With specific words in the message header
- In the rule description below, edit the People or distribution list to include the address(es) you send iPhone mail from. Also edit the Specific words list to include the phrase iPhone Mail.
- Click Next and choose the actions Move it to a specific folder and optionally Flag it with a colored flag. (I move messages to my Sent Items folder, and flag them green to make them stand out, but you could create a folder specifically for iPhone messages if you prefer.)
- Click Next, then choose Except if sent only to me from the list of exceptions. This ensures that messages I forward to myself don't get moved to Sent Items.
- Click Next once more to finish creating the rule, give it a sensible rule name (I used iPhone Messages) and then, if you like, run it immediately on the contents of your Inbox. This tidied up all the existing messages I've sent from my iPhone over the past year.
Only takes a minute to set up, and now my Inbox feels like it's back under control again. Better, I can now easily find messages I sent on my iPhone while searching on my desktop.
(Yes, switching from POP3 to IMAP would let me do all this seamlessly, in principle, but there's something about the simplicity of POP3 that I continue to like.)
Tuesday, 20 November 2012
Monitoring network downtime with PRTG
I've been using MRTG for a while to monitor assorted servers, routers, and switches I manage at The Windmill. It's free, works pretty well, and is quite configurable. The graphs it produces are plain but functional, and they do the job.
Recently, I needed a tool to monitor my home network, primarily because the Cisco 3925 router provided by my Internet supplier, UPC, has had a nasty tendency to lockup every week or so. Now, UPC's 120 Mb/s Internet service is fantastic value, and performs exceptionally well, but having it randomly interrupted like this is really, really annoying -- especially when the router is buried in a small cupboard at the back of our attic, where all the TV wiring is concentrated.
I also have a wireless access point (an old reconditioned Eircom Netopia 2247) which periodically hangs, though on a different schedule to the Cisco. So, I figured it was time to start monitoring both devices to see exactly when they go offline, in the hope that I might be able to correlate it with other network activity.
While MRTG can do this, it's not the most user friendly of systems to configure. Since I crave nothing more than an easy life, I decided to look around for alternatives.
This brought me to PRTG, a commercial monitoring tool from Paessler that covers some of the same ground. It's free for up to 10 monitoring points, runs under Windows, and has a nice web-based GUI that makes it easy to configure or review logs from anywhere on my LAN. So, I decided to give it a try.
I've been using PRTG for about two months now, and it's working very well. There are a huge number of built-in sensors: everything from basic PING tests, SNMP polling of routers & switches to Windows system metrics (for any machine on the LAN) to remote website HTTP monitoring. With the 10 free sensors included in the evaluation copy, I was able to add rules for three websites I manage, my Wifi and Internet routers, a separate VPN router I use to access client networks, and also a few of my local machines:
PRTG lets you create sensor dependency trees: for example, I monitor the uptime of this website (www.snoopdos.com) but the monitoring rule says not to try and monitor it if the UPC Cisco router is down, OR if Google's main DNS server at 126.96.36.199 can't be reached. This ensures I don't get an onslaught of website failures in the log just because my Internet connection was interrupted.
PRTG also lets you raise alerts whenever a sensor goes on or offline, or crosses a threshold. For example, if the disk space on C:\ on my main Media Center TV system drops below 1 GB, I can easily have PRTG alert me, either by email or SMS.
I've barely scratched the surface of what's possible so far, but it's a very capable system. When Paessler emailed me today with an offer to upgrade my free 10-sensor license to 30 sensors in return for some blog coverage, it wasn't a difficult decision. While I only blog about products I actually like and use, PRTG now falls squarely into that camp. Give it a try and see what you think for yourself.
Tuesday, 30 September 2008
Vista audio glitch on Sony Vaio V505CP
My personal laptop is a Sony Vaio V505CP. It's almost five years old, but after upgrading it to 1.5 GB RAM and a 160 GB hard drive, it does a good job of running Windows Vista SP1. I use it mainly when I'm out on consulting jobs or travelling, so I don't need anything more powerful.
A month or two back, I noticed that whenever I played music, the audio would glitch every 20-30 seconds. The mouse pointer also froze briefly during the glitches. This was something new -- it was working fine after the original upgrade to Vista SP1. Today, I finally got around to investigating the cause.
For those in a hurry: the culprit was NDIS.SYS, the network driver. Simply turning off the built-in wireless adapter (easily done with a switch on the front of the Sony's case) made the glitch go away. I can live with this for now, since I rarely use wireless and stream music at the same time; normally, I leave the wireless enabled all the time, just in case I might need it, but it's not a big deal to turn it off.
So how did I figure this out? Here are the steps I followed, including dead ends (the journey is often as interesting as the destination).
My first port of call was Windows Task Manager. I usually start here, simply because Task Manager is standard on every Windows PC. In this case, it showed a big CPU spike whenever the glitch occurred, but unfortunately, Task Manager itself froze during the glitch so I couldn't identify what process was responsible.
The next tool to try was Process Explorer from SysInternals, a wonderful tool for all kinds of system probing. It includes a dummy task entry for DPC (Deferred Procedure Calls) and so I could see that during glitches, DPC was particularly active, responsible for almost all the additional CPU usage.
Deferred Procedure Calls are used whenever a process needs to make a system call, but the system is busy doing something important like handling an interrupt. The system call is queued until the interrupt completes, and all outstanding calls are then executed in sequence -- hence the brief jump in CPU activity.
Some Googling brought me to a handy tool called DPC Latency Checker, which graphs DPC usage over time. Using this confirmed the theory:
The red peaks indicate unusually long DPC latencies, which will cause system problems. Unfortunately, the checker didn't tell me the cause of these, but I knew it was probably a badly written device driver. The checker's website suggested using Microsoft's RATTv3 developer tool to identify the culprit.
I hadn't come across RATTv3 before, but it's very useful -- if you're running Windows XP, that is. It records the latency of each and every device driver's interrupt calls, correlated over time, and identifies the bad ones for you. Unfortunately, it doesn't work too well under Vista.
Back to Google, where I found a thread suggesting Microsoft's new Performance Toolkit as a good Vista alternative. This does everything RATTv3 can do, and a lot more besides.
One thing to watch out for: after installing the toolkit, all the files end up in "C:\Program Files\Microsoft Windows Performance Toolkit". I suggest copying them to C:\XPerf for convenience, since the installation folder is not added to the system path automatically.
After installing, you can begin a new capture by opening a command prompt in the toolkit folder and typing:
xperf -on DiagEasy
to begin tracing. Then let the system run for a minute or two, until the glitch has occurred. Next, turn off tracing and convert the results to a file suitable for viewing:
xperf -d trace.etl
Finally, view the accumulated results:
Pretty easy! Doing this produced a summary page with a ton of detail, most of which I didn't need (CPU usage, disk i/o, etc.) The thing I was interested in was DPC activity, which it showed as a graph like this:
The peaks in the graph show unexpectedly high DPC levels. By selecting one of those peaks and right-clicking, I was able to display a summary of all the driver activity that had contributed to the peak:
From this, it was clear that NDIS.SYS was the culprit, with a worst-case latency of more than 200 ms. (I repeated the test several times to confirm this, and it was consistently in top place.)
So mystery solved. From here, it was an easy step to try disabling the network adapters to see if that fixed things -- and turning off the wirless adapter did the trick.
So when I have a chance, I'll upgrade my wireless driver and hopefully that will sort it out permanently. For now, though, I'm just glad to have properly working audio again.
Sunday, 23 December 2007
Telepresence in the air
Marc Andreessen's blog today mentioned this cool demo:
This uses video goggles with a head-tracking sensor to remotely control the orientation of a camera mounted on a pilot-less plane, letting you virtually explore the heavens.
Apart from the general wow-factor of flying around the sky without ever leaving the ground, it reminded me of another piece of impressive technology I came across recently: quad-copters.
Here, a high-speed DSP is used to combine realtime feedback from gyros and sensors on position, wind direction, etc. to control four rotating blades independently allowing for stationary hovering in a wide range of conditions with no pilot input required. Great for remote video surveillance etc.
Combining these two pieces of technology seems like a perfect opportunity. Has anyone done it yet?
And a missing piece of the puzzle: even using stereo cameras to feed the video goggles, the image will still be flat since there is no way to remotely focus it (other than relying on auto-focus). Has anyone developed a set of video goggles that can track the eye's ability to focus on specific objects? Combine that with a pair of remote cameras that can track the eye's focus in that way and you could have REAL telepresence (once the latency isn't too high, of course).
Isn't it great that we live in an age where such amazing technology is affordable enough to let people devise interesting hacks in their spare time...?
:: Next Page >>