I’ve been using VSCode for quite some time now. Generally speaking, I’ve been super happy with it. It’s ultra configurable, fairly light weight, very fast, and just generally a pleasure to work with.

Except….

They completely got handling of Ctrl-Right wrong. Try it in Word, try it in Notepad++, in Visual Studio, you name it, they all work a certain way.

But VSCode, not so much.

Now, it’d be easy enough to get used to it, if all my editors decided to change the default way they handle Ctrl-Right. But, yeah, no.

I’ve dealt with it for a while now but this weekend, I finally decided to have a look.

It took some Google-foo, but eventually I came across this post by Spongman that very accurately describes the problem.

I won’t repeat that here, but here’s the keybindings for VSCode that fix the problem.

    {
        "key": "ctrl+shift+right",
        "command": "-cursorWordEndRightSelect",
        "when": "textInputFocus"
    },
    {
        "key": "ctrl+right",
        "command": "-cursorWordEndRight",
        "when": "textInputFocus"
    },
    {
        "key": "ctrl+right",
        "command": "-cursorWordAccessibilityRight",
        "when": "accessibilityModeEnabled && textInputFocus"
    },
    {
        "key": "ctrl+shift+right",
        "command": "-cursorWordAccessibilityRightSelect",
        "when": "accessibilityModeEnabled && textInputFocus"
    },
    {
        "key": "ctrl+right",
        "command": "cursorWordStartRight"
    },
    {
        "key": "ctrl+shift+right",
        "command": "cursorWordStartRightSelect"
    }

It’s a bit tricky to get them installed in VSCode, what with the new Settings UI, but, once they’re there, Mwah! Perfection!

A colleague recently pointed me to a fantastic little desktop customization app for windows, RainMeter.

He was using the lottaweather skin, so I pulled that as well, and I’ve found it quite nice to have a really clear forecast stuck right there on the desktop.

It’s tiny, quite capable, and is really easy to knock up a quick notification panel or whatnot based on a webservice, or so I thought.

At work, we’d recently been throwing ideas around about how to be reasonably notified of build failures and Pull Requests/Statuses.

Another colleague came across AnyStatus, which is quite nice in it’s own right, but I thought it’d be nice to have something in the same style as lottaweathers skin.

I’ll dig into the details of scraping azuredevops and jenkins later, but while putting things together, I ran into a vexing problem.

I had one measure that resolved the users azure guid “id” given their name and a different measure that requested all the Pull Requests where that userid was listed as a “reviewer”.

Pretty standard stuff for RainMeter, and the urls I was using worked just fine in PostMan, but not Rainmeter.

Actually, the UserID request worked, but not the Pull Request query.

Here’s the measure definitiion:

[MeasureMyReviews]
Measure=WebParser
Disabled=1
URL=https://azuredevops.blahblah.com/#organization#/#project#/_apis/git/repositories/#repository#/pullrequests?api-version=5.1&searchCriteria.reviewerId=[MeasureUserID]
Header=Authorization:Basic #AzureDevOpsPATBase64#

After WAY too much head scratching, I discovered the problem was two-fold.

1. My measure referenced the UserID measure like so: [MeasureUserID] but that syntax doesn’t work in this context. In a URL definition, it needs to be [&MeasureUserID] (note the &)
2. WebParser measures happen asynchronously, but in this case, the “MeasureMyReviews” has to happen AFTER the MeasureUserID. Otherwise, the userid hasn’t been resolved and will just be blank.

The fix was to set Disabled=1 for the MeasureMyReviews measure, then enable it in the FinishAction of MeasureUserID, like so:

[MeasureUserID]
Measure=WebParser
URL=https://azuredevops.blahblah.com/#organization#/_apis/identities?api-version=5.1&searchFilter=General&filterValue=#username#
Header=Authorization:Basic #AzureDevOpsPATBase64#
RegExp=(?siU)"id":"(.*)"
StringIndex=1
DynamicVariables=1
FinishAction=[!SetOption MeasureMyReviews Disabled 0][!UpdateMeasure MeasureMyReviews]

Note the two bang commands in the “FinishAction”

I work with a team that’s pretty geographically distributed, so it’s always nice to have a solid notion of what time it is where-ever the person I’m talking to (or about to talk to) might happen to be.

I stumbled upon TClock (and White-Tiger’s update TClock Redux) quite some time ago and it worked fantastically for what I needed.

Yeah, OK, it might be a tad dated, UI-wise, but it easily allows you to put several clocks for different timezones, with labels, right there in the tray. And you still have quick access to calendar, etc.

For me, I used a TClock configuration like this for ages.

Notice 3 timezones, with seconds that update only on the middle zone (I’m in Central), and an uptime clock, day name, and date just for good measure.

But recently, I started working with several folks scattered across India, and their timezones were fractional, something like GMT-7.5.

And TClock didn’t handle that.

I finally got some time several weeks back, so I forked White Tiger’s Redux branch, dusted off my C programming chops and went to work.

And I came up with TClock Redux Redux.

White Tiger might incorporate the pull request into their branch, but until that time, I’m posting the GITHUB project and release here.

Source is located here

An initial release, 64bit only, can be found on the releases page here

How to use it

Stop TClock if it’s running on your machine, download the release Clock64.exe and simply copy it over the existing Clock64.exe. Then restart TClock.

Outwardly, it’s exactly the same as TClock Redux, so please see White Tiger’s page for detailed configuration information.

For this version, the only thing that’s different is the handling of the “w” format specifier.

“w” means “calculate a time that’s an offset of x hours from the “current” timezone.

So, for instance, if I’m in Central US time, and I wanted to show East Coast time as, say, 12:30PM, I’d use “w+1:nntt”.

For Pune, India, however, they’re actually 12.5 hours ahead of Central time.

The original TClock Redux couldn’t handle that, but with this version, you can configure you clock format string with

“w+12.5:nntt”

and you’ll get the time in Pune, offset by 12.5 hours from the current time zone.

So now, my Taskbar can look like this:

I’ve added “day of the year” and “week of the year” just for fun.

The TLDR;

For the impatient crowd 🙂

• Download The Disambiguator KeePass plugin here.
• Unzip it and place the PLGX file in the KeePass “Plugins” folder, just like any other plugin.
• Restart KeePass. You should see a “Compiling Plugins” notice and then KeePass should start normally.
• In KeePass, click “Tools”, “Plugins” and verify that The Disambiguator is now in the list of loaded plugins.
• Edit the AutoType entry for a credential set that has an ambiguous Window Title.
• add “{exe:nameOfExecutable}” (without doublequotes) at the end of the WindowTitle. Replace nameOfExecutable with the filename of the Executable program file that the Target Window belongs to. In the case of Quicken, for instance, that would look like {exe:qw.exe}

Now open your target application and use AutoType as you normally would. If everything is set right, KeePass will now automatically select the appropriate credentials for the target window using both the Window Title and the application executable.

Introduction

I’ve used the password manager KeePass for a very long time. Excellent, simple, clean install, low resource usage and fast.

The AutoType support, while possibly not quite as simple as some full commercial packages, is quite flexible and has never let me down.

Well, almost never.

KeePass’s AutoType feature works by allowing the user to enter one or more “Window Titles”, which it then compares against the target window when you user presses the AutoType hotkey.

When only one configured Window Title matches the Window Title of the target window, KeePass automatically can choose that single set of credentials, and perform the autotype. It’s almost like magic!

Trouble Ahead

But, what happens when there are 2 or more credential sets that have the same Window Title?

For instance, both Quicken and Exodus request the user to login via a login screen with the Window Title “Enter Password”.

If you’re “responsible” with you passwords, and we all are as KeePass users (right?!), then you’re not using the same credentials (username and password) for two different applications. This means you likely have two different sets of credentials stored in KeePass: one for Quicken and one for Exodus. And you’ve setup AutoType for both.

But there’s the rub. Both sets of credentials have AutoType setup to key on the Window Title of “Enter Password”, as they must.

Unfortunately, when you have, say, the Quicken Login window displayed and press the KeePass AutoType hotkey (normally Ctr-Alt-A), KeePass discovers 2 sets of credentials (and possibly more) that match. Because it can’t magically decide which to use, it pops up the Credential Chooser dialog so that you, the user, can make the choice.

This is all fine and good, but it can be a bit of a pain, and it forces the user to make a choice when the choice should be automatic.

Enter The Disambiguator

The problem here, of course, is disambiguation. Using the Window Title as the only “disambiguating” factor is ok most of the time, but, as the above example shows, it’s not always quite enough to completely identify a single specific credential set to use for autotype.

Alex Vallat has a very nice plugin for KeePass called WebAutoType which specifically allows users to configure matching URLs for autotype entries. This will almost always provide enough uniqueness to properly match a single credential set for Web Pages. But unfortunately, it does nothing for normal desktop apps like Quicken or Exodus.

That’s where The Disambiguator comes in.

to be continued