Category: Computers

Mac OS X and Windows

Add Merge Fields to a Word Document before adding a DataSource

Adding merge fields to a Word document without adding a datasource to it is not at all obvious when the mail merge button is greyed out. But to use MailMerge programmatically you probably want to do just that.

You can do it—unobviously—via Insert->QuickParts->Field:

Choose MergeField from the list on the left, and then you can type in your merge field name.

More recently, the “Field” button has been promoted (woo) to a top-level citizen of the Insert Ribbon, so now it' s a bit easier to find:

Your CPU vs your code. Two short lessons in software performance

There’s a great Q and Answer at dijkstra-path-finding-in-c-is-15x-slower-than-c-version which starts with C++ code at 2ms vs C# at 38ms; and finishes with C# at 2.8ms.

On similar lines, the solution to this riddle — why-does-net-core-2-0-perform-worse-than-net-framework-4-6-1 — has nothing to do with the framework; it results from the slower performance of 64bit code compared to 32bit.

Which just goes to confirm what you might have suspected;

VMs aren’t that slow; and
For best performance, you have to understand your VM, and your language, and your O/S, and ultimately your CPU.

PowerShell String.Split() Off-by-Method-Overload Error

This seemed to me an error and I and was on the point of raising it as a bug on the Powershell github repo:

PS> "\this".Split( [char]'\', [StringSplitOptions]::RemoveEmptyEntries).Length
# >> 2

Presumably it is because [StringSplitOptions]::RemoveEmptyEntries is coerced to a [char] and so the line is parsed as:

PS> "\this".Split( ([char]'\', [StringSplitOptions]::RemoveEmptyEntries) ).Length

Instead of as

PS> \this".Split( (,[char]'\'), [StringSplitOptions]::RemoveEmptyEntries).Length

If the first parameter is a string not a character then it works as expected:

PS> "\this".Split( '\', [StringSplitOptions]::RemoveEmptyEntries).Length
# >> 1

But the really unfortunate case is :

PS> "\this".Split( [System.IO.Path]::DirectorySeparatorChar, [StringSplitOptions]::RemoveEmptyEntries).Length
# >> 2

which results in

PS> "\this".Split( [System.IO.Path]::DirectorySeparatorChar, [StringSplitOptions]::RemoveEmptyEntries).[0]
# >> $null
# instead of
# >> "this"

It turns out that it's fixed in Powershell 6 Beta; or to be more precise, it doesn't happen in PowerShell 6. What changed is that the underlying .Net framework has added new overloads to String.Split():

string[] Split(char separator, System.StringSplitOptions options)                                                                                    
string[] Split(char separator, int count, System.StringSplitOptions options)                                                                         
string[] Split(string separator, System.StringSplitOptions options)                                                                                  
string[] Split(string separator, int count, System.StringSplitOptions options)

Whereas PowerShell 5 only has these overloads available:

string[] Split(Params char[] separator)                                                                                                              
string[] Split(char[] separator, int count)                                                                                                          
string[] Split(char[] separator, System.StringSplitOptions options)                                                                                  
string[] Split(char[] separator, int count, System.StringSplitOptions options)                                                                       
string[] Split(string[] separator, System.StringSplitOptions options)                                                                                
string[] Split(string[] separator, int count, System.StringSplitOptions options)

And so the best-match overload that PowerShell 6 chooses is different to PowerShell 5's best match.