Fix slow link clicks in Microsoft Office (Word, Excel, Powerpoint, etc)

When working with a spreadsheet with roughly 90 rows of links, I got frustrated with a 1-3 second delay when clicking on each link.

The cause

For those who don't have Internet Explorer as their default browser (who in their right mind would?), Office has implemented a workaround which does a request internally to check the response before opening the link.

This internal request also handles other cases like checking if the link points to another spreadsheet file or an external word doc file on a network drive.

The behaviour is noticeable in Office 2003, 2007, 2010, 2013, 2016 and probably 2019 onwards.

Fortunately there is an easy fix which forces link clicks to be handled by the system instead of Office.

The catch

If this all sounds too good to be true, then it is.

The fix changes a setting which sets ForceShellExecute=1, which means all links will be treated as if it was clicked from within the shell (aka Windows Explorer).

Because of that, Office no longer has any way to intercept the clicks and this breaks multi-document linkage. See this page to see if any of the scenarios affect your daily workflow before running the fix.

The fix

To stop the internal request from being made (and causing delays), go to this Office troubleshooting page and download the "Easy fix".

Run it and follow the instructions.

That should be all you need to do.

Sources:


Getting native Linux terminal on Win10 WSL (Windows Subsystem for Linux)

(Wow, it's been a while since I've written anything! Since Open Live Writer doesn't seem to be working anymore, I had to venture back into writing straight in the browser. Dammit Blogger it's still awful)

After upgrading to Win10 1809 (the infamous November 2018 rollout) and updating to the latest WSL Ubuntu build, I noticed a bunch of issues with my ConEmu/WSL setup.

Vim wasn't navigating as it should; ignoring input at random and text wasn't pasting properly into the command line. It seemed to be truncated randomly and I couldn't spot a pattern. Turns out there were some changes to the way input was encoded and I needed an update for ConEmu and use their wslbridge script.

I tried updating and the performance hit was awful. I had native WSL and bridged ConEmu side by side tailing the same log file and the bridge script was causing it to jitter uncomfortably.

Along the way I found an extremely helpful post by ropnop called "Configuring a pretty and usable terminal emulator for WSL". I didn't know it was possible to forward the X Window manager to... Windows! There was a detail or two missing (regarding firewall and dbus) but eventually I managed to get it working in a slightly simpler way (no need for vbscript).

Downloads

Setup


  • Install VcXsrv and run XLaunch. The default settings are fine, but be sure to save the config so you can simply run the configuration to start X.
  • Alternatively you can start it with:
    "C:\Program Files\VcXsrv\vcxsrv.exe" :0 -ac -terminate -lesspointer -multiwindow -clipboard -wgl -dpi auto
  • Make sure the icon appears in the taskbar.


  • Open up an instance of WSL Bash
  • Start off with "sudo apt-get update"
  • Followed by "sudo apt-get install dbus-x11 gnome-terminal" (you can substitute gnome-terminal with whatever terminal you'd prefer)
  • Confirm install and let the downloads start
  • While you're waiting, be sure to create a firewall rule to prevent anyone else from accessing your X server
  • (Firewall setup) Go to "Windows Defender Firewall" and click on "Advanced settings" on the left

(I hate the labyrinth known as Windows 10 settings)


  • Click on "Inbound Rules" under "Windows Defender Firewall ..."
  • Right click > "New Rule" (or click on New Rule on the right panel)
  • Rule type: Program
  • Program path: C:\Program Files\VcXsrv\vcxsrv.exe (by default)
  • Allow the connection
  • Only apply to Private connections
  • Then give the rule an appropriate name
  • Edit the new rule you've created
  • Go to the "Scope" tab and add 127.0.0.1 to both local and remote IP restrictions


  • Apply and finish
  • (Back to the terminal setup) Once it's done downloading, give dbus a kick start:
    sudo /etc/init.d/dbus restart
  • Test that window forwarding works by pasting this in:
    DISPLAY=:0 gnome-terminal &
  • If it works, create an alias in ".bash_aliases" called "runterminal" with the following:
    alias runterminal="DISPLAY=:0 terminator &"


  • Finally, create a shortcut on your desktop to easily start gnome-terminal:
    bash.exe -i -c "runterminal"
  • Set "Run" to minimised to avoid an unnecessary command prompt flicker.
  • And now you're done!

Sources


 
Copyright © Twig's Tech Tips
Theme by BloggerThemes & TopWPThemes Sponsored by iBlogtoBlog