My dual monitor alignment

I have a bit of an odd configuration when it comes to dual monitor alignment that really catches people off guard. Most often when I see people with dual monitors, they arrange their monitors in one of two ways:

  1. Perfectly align the monitors horizontally (physically and virtually)
  2. If the monitors are not aligned perfectly (due to different height raisers/stands, monitor size or laziness), the virtual alignment is adjusted to reflect this The end result is the desktop behaves like it naturally extends across both monitors, so dragging a window half way between each monitor would make it appear seamlessly moving across monitors. Something like this (click/tap to make the window move back and forth):

But this causes me a couple of problems.

First of all, one of the great features in Windows 7 (or did it come in from Vista?) is being able to snap windows to the side of the screen, making them take up half of the display area. But with multiple monitors configured, you can no longer do this with the mouse on the side of the screen that "connects" one display to the other. Yes, I know I can use WinKey+Arrow, but if I'm already using the mouse, I don't want to have to swap just to do this.

Secondly, I'm a bit lazy when it comes tracking the mouse pointer. If I want to close a window, I just push the mouse up and to the right, then click. The sides of the screen will "funnel" the mouse to the top-rightmost corner, right where the "X" is located, so I can close a window without having to think about or watch the mouse pointer (yes I can use Alt-F4/Ctrl-W, but same deal as before). Likewise for getting to the Start menu, and to a lesser extent File menu and system tray. Also, getting to the scroll bar of a window on the "left" display means you need to be a bit more precise.

However, at some point I discovered something interesting which solved my woes: if you position the virtual windows exactly diagonal to each other, the side of the screen allows snapping windows with the mouse again! And to move the cursor between displays, you actually move the mouse through the corner of the display:

This is wonderful, I can now snap windows as expected, I can still be lazy to get to the window close button, start menu, and get to the scroll bar with out worrying about overshooting and moving the cursor to the other display. You'd think this would make moving the mouse/windows between screens a royal pain, but in the same way I just push the mouse up/right to get to the close window button, however I can just quickly flick the mouse down/right (or up/left as appropriate), and I get to the other screen.

Of course, this drives people crazy trying to use my computer, since it's really not obvious and takes some getting used to. Tie that in with the fact I have a Evoluent vertical mouse and they pretty much throw their hands up and let me "drive" :)

Enter Windows 8…

Windows 8 might screw me. Windows 8 has hot corners to bring up the charm menu, app switcher and so forth. Users complained with multiple monitors on Windows 8 it was easy to overshoot the corner and have the mouse end up on the wrong screen. So they registry hack to reduce the hard edge size from 6 pixels to 0, but I'm worried the exact corner will still be blocked, meaning I can't switch between displays through it. Hopefully I won't have to use Windows 8 any time soon :)

  • work
  • hack, setup

Letters after my name

Today, I received some letters after my name. I passed the 70-573, gives me my MCPD certification, hooray! Yes, I know, it's 2013 – why am I only passing my 2010 exams now? Simply put: laziness. Well that a fear of failing. How could I possibly go back to work knowing I'd failed an exam to demonstrate I can do the very thing I'm getting paid to do!

But I didn't. I passed comfortably, and now can focus on working towards my 70-480 exam, so one down three to go.

I guess until then, if I want to be really douchey, I can sign off my emails with…

Daniel Flint
BSc (CS), MCPD, MCTS, MCP, MS

And of course, include my fancy pants Microsoft logo:

MCPD: SharePoint Developer 2010
  • sharepoint 2010

SharePoint RTE and H6

All blogs have to start somewhere, and after far too much procrastination, I'm going to start here…

The SharePoint ribbon allows users to select various styles when using the Rich Text Editor, and these styles can be customised through some clever CSS definitions. Wonderful! While maintaining a SharePoint application with plenty of customisations like this in place, I had a bug come through with a comment: I'll have to come and show this to you, it's too hard to explain.

Crap.

When users were checking in pages after editing content, occasionally the headers would end up on all different lines. So this:

While editing content
While editing content

Would become this when checking in:

After checking in
After checking in

What the hell, right?

The customised styles that had been implemented were simply allowing users to use HTML headings 1 through 6, nothing fancy, And after a bit of playing around, discovered this problem only occurred when using a heading 6 style. I also noticed this happened when running spell check (which is automatically run when checking in). So I started digging around SP.UI.RTE.debug.js, and came across a happy little array called RTE.HtmlTagName.blockElements. Lo and behold, it listed H1 through H5, but skipped H6!

I don't know if omitting H6 was intentional or not, but it seems that array is used by the spell checker to determine whether it can split up text when highlighting misspelled words, or in the case of a block element probably wrap the misspelled words in spans instead. A quick test adding H6 to this array, and like magic the problem disappeared!

I ended up putting this snippet in the master page within an EditModePanel:


ExecuteOrDelayUntilScriptLoaded(function () {
    if ( RTE
        && RTE.HtmlTagName
        && RTE.HtmlTagName.blockElements
        && !Array.contains(RTE.HtmlTagName.blockElements, "H6")
    ) {
        RTE.HtmlTagName.blockElements.push("H6");
        RTE.HtmlTagName.$4o["H6"] = true;
    }
}, "SP.UI.Rte.js");

There was actually a bit more to it than that, but that's the gist. I wasn't sure if the $4o array needed to have H6 in there too, but I figured why not. A note with that: in some versions of SP.UI.RTE.js, the array is called $4q, not $4o. So deal with that appropriately. (I ended up looping through each object under RTE.HtmlTagName looking for objects with H5 set to true, and H6 not present. Messy and horrible, but that's what happens when you dig around the guts of SharePoint.)

I haven't tried this in SharePoint 2013, but the blockElements array still doesn't have H6 listed, so it may well still be a problem! Update: I stand corrected, it actually does appear to be fixed. Good stuff. Though I believe SharePoint 2013 can run in a "2010 compatibility" mode, and the problem still appears to be present.

Here's hoping I haven't inadvertently broken something else, and/or missed something really obvious as to why this is the way it is!

  • sharepoint 2010
  • hack, javascript, rte, sharepoint