Dull colours in MS Word 2011 for Mac using *.doc format

I had a problem where I created a nice diagram in JPG format, but when I inserted it in my Word document the colours appeared dull and washed-out. This was using Mac Microsoft Word 2011 and saving the document in Word 97-2004 compatible format (*.doc). I tried many different ways to insert the image (including dragging and dropping it in), but all resulted in the washed-out image.



Saving the document as a Word document (*.docx) resolves the problem; but unfortunately I need to use *.doc format for backwards compatibility with my corporate clients.

Then I noticed that some of my earlier images in the same document were not washed out. How could this be? Reinserting these older images resulted in nice bright pictures in my *.doc document. So the problem had to be with the new images I was creating. I was using the same method I had always used to create images, but Word did not like my new ones. Something must have changed.

I quick check of the image properties, via the Finder, revealed the answer: The Color Profile



I had created the first images on my laptop which gave them a Color Profile of "Color LCD". The later images had been created on my secondary monitor and got a Color Profile of "DELL 3008WFP".

The Solution

The solution was to preview the image, on my laptop screen, and take a screen shot of it (using Command-Shift-4 and selecting the image). This screenshot had the required "Color LCD" Color Profile. I then dragged that screenshot into MS Word and the colours were perfect! Voila!!

Visual Studio Keyboard shortcuts that I keep forgetting!

I use so many different IDEs that there are a few key combinations that I just don't remember. Here's a quick list for next time I'm hunting:

Command	Keys I Use	Keys Others Use
Edit-Intellisense-Resolve	Alt-Shift-F10	Ctrl-+
Right Click-Go to Definition	Shift-F2	F12

Getting Novell SSL VPN working on Windows 7

I use the Novell Access Manager SSL VPN to connect to one of my customer's networks. It is a browser-based VPN client which means that you have to login via the browser and then keep the browser window open to maintain the VPN connection.

According to the documentation it will work with both Windows and Mac, and with IE, Firefox and Safari. Well it doesn't for me! Initially the only combination I could get working was IE under Windows XP. With a bit of fiddling I've finally managed to get it working for Windows 7. I write these notes for when I need to set this up again!

Attempting to launch the VPN client from IE on Windows 7 initially gives this error message:

AM.1804 : Connection to service failed.

Consulting the Novell Access Manager SSL VPN manual says that you should watch the <Users> folder. If you are quick enough, you'll see these files appear:

novl-sslvpn-service-install.exe
cacert.pem
openvpnclient.msi
PrivilegeDetector.exe
vplogin.dll

...along with a few log files. You do have to be quick though because they are deleted almost immediately.

The manual instructs you to shutdown your browser, run the novl-sslvpn-service-install.exe EXE manually and then start the browser and all should be working.

Instead, I took a simpler (and probably far less secure) route. I removed the User Account Access Control restrictions. I changed them from "Notify me when programs try to make changes to my computer" to "Never notify me". This can be done via Control Panel-User Accounts-Change User Account Control Settings



Change from Default to "Never Notify" and click OK. After confirming this change you will be prompted to restart your computer. Once it has restarted, the SSL VPN should work! Note that it does take a while to connect and you'll have to confirm to install some insecure driver software, but it works.

Using log4net with shared DLLs

I've got a C# DLL that is used from a number of different places, including .Net EXEs, VB6 EXEs, Work and Outlook COMAddIns and also Outlook forms. It uses log4net for tracing and debugging.

I'd found log4net to be pretty reliable BUT sometimes messages weren't ending up in my log file (usually when I really needed them!). Most recently this happened today when I was trying to trace a problem in my Outlook form. I'd drag the appointment in Outlook which would fire the Item Write event on the form and, although I could loo kin the DB and see that my DLL was working, nothing was showing up in the log4net log file.

How to Investigate the Problem

To find out what was really happening, I used log4net's internal debugging. In the case of an Outlook Form, I switched it on like this:

1. Started Outlook


2. Started Visual Studio and opened my DLL project


3. Switched on log4net internal debugging by modifying my log4net configuration file and changed the <log4net> to read <log4net debug="true">


4. Used "Tools-Attach to Process" and attached to the Outlook.exe process


5. Placed a breakpoint in the project on a line that I knew it should encounter


6. Ran the test again...

The Problem

When I ran the test again with log4net debugging switched on, I could clearly see that log4net was unable to write to my logfile because it was locked. I didn't obviously have it locked (I had it open in TextPad but closing that didn't fix the problem). A quick scout around revealed that log4net with the RollingFileAppender by default will lock the file and keep it locked. Clearly this was the problem in my case where multiple programs all use my DLL which writes to the same logfile.

The Solution

I do want all of the instances of my DLL to write to the same log file, but I don't want them to lock the file and keep each other out. The solution was to add the following to the appender section of my log4net configuration file:

<lockingModel type="log4net.Appender.FileAppender+MinimalLock" />

This instructs log4net to get the lock, write and release the lock every time - so it doesn't keep the file locked. With this in place, all of my DLL instances now write to the logfile, ALL of the time! There is a slight performance overhead to this approach, but then I'd rather than it works slowly, than not working quickly!