Creating a Break Timer in PowerPoint using VBA

When I teach live classes, I use the SysInternals Zoomit application, which has a break timer built in. However, I was teaching a online class, and Zoomit did not seem to get along with WebEx. I decided to write a break timer directly into the PowerPoint slides I was using.

The first step is to create a slide at the end of the presentation that looks like this:

In other words, it is a standard slide with a title at the top and bullet points section below. I centered both and removed the bullet, so it just had text on the time. The code below counts on this slide as being the last in the presentation.

Next I brought up the PowerPoint Visual Basic Editor. You can do this with Alt+F11. Insert a module with Insert > Module from the menu. In the module, add this VBA code:

Option Explicit

Private Declare PtrSafe Sub Sleep Lib "kernel32" (ByVal Milliseconds As Long)
Private lngPreviousSlide As Long
Private boolEndBreak As Boolean

Public Sub BreakTimer()
    Dim dtmStart As Date
    Dim dtmEnd As Date
    Dim slidesCollection As slides
    Dim slideBreak As slide
    Dim lngCurrentSlide As Long
    dtmStart = Now
    dtmEnd = DateAdd("n", 10, dtmStart)
    Set slidesCollection = Application.ActivePresentation.slides
    Set slideBreak = slidesCollection(slidesCollection.Count)
    lngCurrentSlide = SlideShowWindows(1).View.slide.SlideIndex
    If lngCurrentSlide = slidesCollection.Count Then
        'On the break slide, end the break early
        boolEndBreak = True
        ' Go on break
        lngPreviousSlide = lngCurrentSlide
        boolEndBreak = False
        SlideShowWindows(1).View.GotoSlide slidesCollection.Count, msoTrue
        Do Until (Now > dtmEnd) Or boolEndBreak
            slideBreak.Shapes(2).TextFrame.TextRange.Text = Format(dtmEnd - Now, "n:ss")
            Sleep 900
        SlideShowWindows(1).View.GotoSlide lngPreviousSlide, msoFalse
    End If
End Sub

When this code run, it remembers the current slide, changes the code to the last slide, and starts a 10 minute countdown (Change the 10 in the DateAdd function to another number to do a different number of minutes in your break).

I then went to the master slide (View > Slide Master) and added a small button in the lower right hand corner. To add a button, you need to have the Developer ribbon turned on. Use File > Options > Customize Ribbon and check the checkbox next to Developer in the dialog and press OK. Then switch to your Developer ribbon.

On the Developer ribbon, Click the Command Button icon, then draw the button on the master slide. Then click the Properties button on the ribbon. Set the name of the button to cmdBreak, and select a clock type image file in the Picture property by hitting the ... button on the right. Then double-click on the button you just created. This creates an Event Handler for the button. In the Event Handler, add this code:

Option Explicit

Private Sub cmdBreak_Click()
    Call BreakTimer
End Sub

Close the Master slide. Run your presentation. Whenever you want to call a break, click the button in the lower right of the current slide. It will jump to your break slide and start counting down. At the end of the break, it will jump back to the slide it was on. If you want to end the break early, on the break slide, click the break button and it will end it (the code is re-entrant, so it can be processing and the button is hit again, which executes it a second time while the first instance is still running).


Visual Studio 2019 Community has CodeLens

I have been asking for many years in this blog that Visual Studio get CodeLens on the cheaper versions.of Visual Studio. CodeLens shows the number of references to piece of code immediately below the method first line, and quickly allows getting to those references. It is actually configurable, so it can show other information as well, but the reference count is the default.

When Microsoft first made CodeLens available, it was only available on the $12000 version of Visual Studio. It has finally made its way into the Community Edition as of the recent release of Visual Studio 2019. The Community Edition is the version available for free for very small companies, educational, and personal use.

Now if they would make Code Coverage available on the Community Edition, it would make me happy. Code Coverage allows seeing what code has been hit by test suites and where additional tests need to be written. There is the free AxoCover that does pretty well, but having the Microsoft version available would be better. This is my biggest missing feature in the Visual Studio that I use.


How to Delete an Excessively Long Directory on NTFS

The current version of Windows has some throwbacks to the days of the DOS operating system. Back in the day, DOS had a limit on filenames that they could not be more than 260 or so characters long (there was a little fudging between the limit on directories and filenames, but let's just call it 260).

The current NTFS file system doesn't have that 260 character limit. However, many of the tools that talk to NTFS, like the Windows Explorer and the command line still do have the limit. So if you have a tool that doesn't have the limit, it can create a directory that you cannot delete from the Windows Explorer or the command line. Arg!

The solution is to make the entire directory path shorter than 260 characters, then you can delete the directory. Go to Windows explorer, and drill down into your excessively long directory path until you cannot go any deeper. Then drag that deepest directory you can reach and move it to be a subdirectory of the root (or somewhere much further up the directory tree if the name conflicts). Delete the directory path that you dragged from, which should now be short enough to delete. Then drill down in your new path from the root...you should be able to reach further down than you could before because the limit only applies from the root. Repeat again and again until you can get to the bottom of the tree.

As an additional note: The most common reason for the long directory name problem is that Windows has a bug where it creates a recursive reparsepoint for a directory called "Application Data". This puts the directory as a subdirectory of itself. This means that you can into this subdirectory forever. So if you use a tool like robocopy to copy the directory tree, it will drill down until it hits the NTFS limit on the directory name (much longer than 260) and keep copying the directory. Then you can't delete the directory it copied. To remove a reparsepoint, you can do the following commands from a command prompt:

cd "\users\myacct\appdata\local\application data"
fsutil reparsepoint delete "application data"


Using the New Features in the Latest Versions of C#

The current version of Visual Studio 2017 (15.8.2 the day this is posted) actually supports C# version 7.3. You can see the new features by looking at the C# feature list. However, by default, Visual Studio will use C# version 7.0. To use versions after 7.0, you will need to go to the project properties, select Build, then click the Advanced button. In the dialog is a setting for Language Version. Changing this to 7.3, for example, will enable the latest features.

You can use this same setting for turning off features. If you don't like the stuff they added to C# version 7, you can go back to 6, or even back to 3. They have been pretty good, however, at not screwing up the language with features added in later versions. I can't think of a feature where I went, "I wish they didn't put that in the language." I think lambda expressions are overused by a lot of people, but there are places where they are appropriate. I also use "var" as little as possible, but there are places where var is necessary and useful. The usage of these features is a coding style issue, not a problem with the language itself.

You can see the features that might be coming in future versions of C# at this page. The biggest feature that is being discussed is non-nullable reference types. With these, you can specify that a specific reference type cannot ever be null. This will likely change how a lot of C# code gets written.


Using UserControls with Caliburn.Micro

It is common to want to create a reusable UserControl, to be placed into a WPF (Windows Presentation Foundation) screen. This can be done one of two ways:
  • ViewModel First
  • View First
The techniques below will show how to do both of these schemes using Caliburn.Micro to perform the plumbing to connect them up. It took me quite a bit of research to figure out how to make these happen, particularly the View first, scheme. Both of these techniques can be used to create a UserControl in a Window that was itself generated using the other technique. For example, a window that was created using the ViewModel First scheme can include a UserControl that is created using the View First scheme.

In the example code below, the main window View is called  MainWindowView and has a ViewModel called MainWindowViewModel. The ViewModel First control has a ViewModel called ViewModelFirstTestControlViewModel, which is displayed with the View called ViewModelFirstTestControlView. The View First control has a View called ViewFirstTestControlView and has a ViewModel called ViewFirstTestControlViewModel.

The ViewModel first scheme places a ContentControl into the MainWindowView, with a x:Name attribute. For example:

 x:Name="ViewModelFirstTestControlViewModel" />

The MainWindowViewModel then has this code:

namespace TestSystem.ViewModels
 using Caliburn.Micro;
 /// <summary>A ViewModel for the main window.</summary>
 /// <seealso cref="T:Caliburn.Micro.PropertyChangedBase"/>
 public class MainWindowViewModel : PropertyChangedBase
  /// <summary>Initializes a new instance of the <see cref="MainWindowViewModel"/> class.</summary>
  public MainWindowViewModel()
   this.ViewModelFirstTestControlViewModel = new ViewModelFirstTestControlViewModel("ViewModel First Set Content");
  /// <summary>Gets the ViewModelFirst test control view model.</summary>
  /// <value>The ViewModelFirst test control view model.</value>
  public ViewModelFirstTestControlViewModel ViewModelFirstTestControlViewModel
   private set;

So the constructor of the MainWindowViewModel instantiates the ViewModel of the UserControl, passing any arguments to initialize the values in the control. A property with the same name as the x:Name of the ContentControl exposes that ViewModel to the ContentControl. When the ContentControl needs to display the ViewModel, Caliburn.Micro finds the appropriate View and displays that as the content of the ContentControl.

The content of the actual UserControl View in this example looks like this, but could be virtually anything you want:

   Text="{Binding Path=Caption}" />

The ViewModel for the control in this example look like this:

namespace TestSystem.ViewModels
 using Caliburn.Micro;
 /// <summary>A ViewModel for the ViewModelFirst test control. This class cannot be inherited.</summary>
 /// <seealso cref="T:Caliburn.Micro.PropertyChangedBase"/>
 public sealed class ViewModelFirstTestControlViewModel : PropertyChangedBase
  /// <summary>The caption.</summary>
  private string caption = "Default ViewModel first caption";
  /// <summary>
  /// Initializes a new instance of the <see cref="ViewModelFirstTestControlViewModel"/> class.</summary>
  public ViewModelFirstTestControlViewModel()
  /// <summary>
  /// Initializes a new instance of the <see cref="ViewModelFirstTestControlViewModel"/> class.</summary>
  /// <param name="caption">The caption.</param>
  public ViewModelFirstTestControlViewModel(string caption)
   this.caption = caption;
  /// <summary>Gets or sets the caption.</summary>
  /// <value>The caption.</value>
  public string Caption
    return this.caption;
    if (value != this.caption)
     this.caption = value;
     this.NotifyOfPropertyChange(() => this.Caption);

The main point about the code is that there is a constructor that takes any initial values to be set for the control. You may not actually need the default constructor.

Now, let's examine how to do virtually the same thing, but do it View First. In the MainWindowView, there is this code to place the control into the View:

 Caption="View First Set Content" />

For this Xaml to work, two namespace must be defined:


The cm namespace comes from the Caliburn.Micro project. Many people use "cal" instead of "cm", but I've got a namespace for "calendrics" in some of  my projects, so use cm instead. The "ctl" namespace is where your views reside.

The cm:Bind.Model specifies the ViewModel for the control. The Caption passes in the initial value of the control.

This retrieves the View for the control. The View looks very similar the the ViewModel First View, with some additions:

   x:Key="ViewFirstTestControlViewModel" />
  DataContext="{StaticResource ViewFirstTestControlViewModel}">
   Text="{Binding Path=Caption}" />

The additions specify the ViewModel for the control as a resource and binds the DataContext of the first child control to that ViewModel. However, with View First, the thing you can't avoid is having code behind. The code behind for the UserControl looks like this:

namespace TestSystem.Views
 using System.Windows.Controls;
 using TestSystem.ViewModels;
 /// <summary>A view first test control view.</summary>
 /// <seealso cref="T:System.Windows.Controls.UserControl"/>
 /// <seealso cref="T:System.Windows.Markup.IComponentConnector"/>
 public partial class ViewFirstTestControlView : UserControl
  /// <summary>The view model.</summary>
  private ViewFirstTestControlViewModel vm;
  /// <summary>Initializes a new instance of the <see cref="ViewFirstTestControlView"/> class.</summary>
  public ViewFirstTestControlView()
   this.vm = (ViewFirstTestControlViewModel)this.root.DataContext;
  /// <summary>Gets or sets the caption.</summary>
  /// <value>The caption.</value>
  public string Caption
    return this.vm.Caption;
    this.vm.Caption = value;

The code behind does the InitializeComponent(), then sets the ViewModel to the DataContext that was set in the view. This, in turn, is used to have the property of the control talk to the ViewModel. The ViewModel of the control looks like this:

namespace TestSystem.ViewModels
 using Caliburn.Micro;
 /// <summary>A ViewModel for the ViewFirst test control. This class cannot be inherited.</summary>
 /// <seealso cref="T:Caliburn.Micro.PropertyChangedBase"/>
 public sealed class ViewFirstTestControlViewModel : PropertyChangedBase
  /// <summary>The text.</summary>
  private string caption = "Default View first caption";
  /// <summary>Gets or sets the text.</summary>
  /// <value>The text.</value>
  public string Caption
    return this.caption;
    if (value != this.caption)
     this.caption = value;
     this.NotifyOfPropertyChange(() => this.Caption);

This is almost the same as the ViewModel of the ViewModel First control, except it does not need the constructors, since the property is changed from the MainWindowView. (It has a default constructor that does nothing.)

A zip file for the entire project is found here. Included are all the files, including the Caliburn.Micro bootstrapper that sets up the files.

If you know of more efficient ways of doing any of the things I've described, please let me know in the comments.


Compiling Help File as Part of Visual Studio Solution

I think that Microsoft has dropped the ball on creating help files. The technology has not changed in about 25 years, and was never simple in the first place. The tools are primitive. Furthermore, there is no simple way to incorporate the building of the help file into a Visual Studio solution.

Building a help file is pretty much the same as building a web site. The pages are authored in HTML. The only difference is that there are some supplemental files that tell it how to build the Table of Contents (.hhc file) and the Index (.hhk file) to the help file, as well as a file to tell it what all the all the other files and provide the settings (.hhp file). There is a compiler that compiles the web site into a single .chm file.

To start with, let's go over the tools needed to build a help file. You need the Microsoft HTML Help Workshop. This provides the help compiler (hhc.exe), as well as a rudimentary Windows application for managing the files (hhw.exe). The content files are HTML. If you know HTML well, you can create them in any text editor. Despite knowing HTML backwards and forwards, I still prefer to edit them in an interface that understands HTML as it allows me to reformat the HTML and other features. Microsoft produced a tool for editing HTML that they have since abandoned called Microsoft Expression Web. You can download it for free from the Microsoft web site.

Visual Studio does not have a template that works with help file projects. So we have to kind of fake it out. Create a console application that will act as the help file project. The console application does not need to do anything, as we will be ignoring the compiled executable, and instead using the build events for the project to accomplish what we need.

Use hhw.exe to create the help project. Add HTML files to the project. The stuff below assumes that the name of the .hhp file is HelpProject.hhp, but you can rename it to anything else by making the appropriate changes below.  The HelpProject.hhp should be added to the root of the help project.

Then add compiling the help file to the build events for the console application. However, we have to work around one minor problem: the help compiler returns one on success and zero on failure, rather than the Windows standard of the other way around. Visual Studio considers a build event that returns something non-zero as a failure and terminates the build of the project. To reverse that, we need a short batch file. Add to the help project a file named helpcompiler.bat file that looks like this:

"%ProgramFiles(x86)%\HTML Help Workshop\hhc.exe" %1
if not errorlevel 1 exit /B 1

Then add this to the pre-build event in the Project Properties:

$(ProjectDir)helpcompiler.bat $(ProjectDir)HelpProject.hhp

When the help file compiles, it will produce HelpProject.chm in the same directory as where the HelpProject.hhp file is created. This is the compiled help file that you need. Add a line to the post-build event that copies the HelpProject.chm file to the final location where it is needed. For example:

xcopy /Y $(ProjectDir)HelpProject.chm $(SolutionDir)SomeOtherProject\bin\$(ConfigurationName)

With this hack,  Visual Studio will build the help file and copy it to where it needs to go as part of the build of the Solution.


Use .editorconfig File to Enforce Coding Conventions

As you may know, I literally wrote the book on C# coding conventions. You can get my book, The Reddick C# Style Guide on Amazon. Since the book was published, C# and Visual Studio have changed a little, as they have added new features to both. There is nothing that I would change in the book, but a few of the new features they added to version 7.x of C# that are not mentioned, such as tuples and pattern matching. Until I can get around to updating the book, there is a nifty feature in Visual Studio 2017 that you can use to enforce what I consider to be the proper coding style for C#.

In the root of your code, add a text file called .editorconfig. The basic format for this file is defined at http://EditorConfig.org. There are specific entries that are understood in Visual Studio 2017, starting with version 15.3, that can be found at https://docs.microsoft.com/en-us/visualstudio/ide/editorconfig-code-style-settings-reference. This is the file that I use, that uses the I consider to be the right style. Even if you don't agree, feel free to use it as a template for your own style.

# http://EditorConfig.org
# https://docs.microsoft.com/en-us/visualstudio/ide/editorconfig-code-style-settings-reference




# "This." and "Me." qualifiers

# Language keywords instead of framework type names for type references

# Modifier preferences
csharp_preferred_modifier_order=public, private, protected, internal, static, extern, new, virtual, abstract, sealed, override, readonly, unsafe, volatile, async:warning
visual_basic_preferred_modifier_order=Partial, Default, Private, Protected, Public, Friend, NotOverridable, Overridable, MustOverride, Overloads, Overrides, MustInherit, NotInheritable, Static, Shared, Shadows, ReadOnly, WriteOnly, Dim, Const,WithEvents, Widening, Narrowing, Custom, Async:nonewarning

# Expression-level preferences

# Implicit and explicit types

# Expression-bodied members

# Inlined variable declarations

# Pattern matching

# Expression-level preferences

# "Null" checking preferences

# Code block preferences

# Organize Usings

# Newline Options

# Indentation Options

# Spacing Options

# Wrapping Options


WPF RibbonSplitButton Activates Twice

On a WPF (Windows Presentation Foundation) RibbonSplitButton there are two parts. There is a button at the top, and a down arrow. The down arrow causes a menu to appear. If you click one of the menu items, there is what I would consider to be a bug, but what Microsoft considers to be "By Design" where it triggers the event code twice. Essentially, it triggers it once for the menu item, and once for the button.

There is a way to handle the problem. Essentially on the first trigger, you need to set the "Handled" property of the RoutedEventArgs to be true. The solution posted on the Microsoft site requires an event handler in code-behind, which isn't compatible with the MVVM architecture. Here is how I handled it using Caliburn.Micro for a button in my application that is supposed to start Excel in one of two different ways. The button at the top executes it with #0, and the two menu items executes it with #1 and #0.

First, here is the XAML. The key part of this is to pass the $executionContext as an argument to the method. This gets the necessary property to where it can be modified.

 cal:Message.Attach="[Event Click]=[Excel(0, $executionContext)]"
 IsEnabled="{Binding CanExcel}"
 Label="{x:Static loc:ShellViewResources.Excel}"
  Header="{x:Static loc:ShellViewResources.Excel}"
  cal:Message.Attach="[Event Click]=[Excel(1, $executionContext)]" />
  Header="{x:Static loc:ShellViewResources.ExcelExample}"
  cal:Message.Attach="[Event Click]=[Excel(0, $executionContext)]" />

The next part is to handle the event. In the Caliburn.Micro code, it starts with:

public void Excel(ContentLevel contentLevel, ActionExecutionContext executionContext)
 RoutedEventArgs routedEventArgs = (RoutedEventArgs)executionContext.EventArgs;
 routedEventArgs.Handled = true;
 // other code

This handles the event, which causes it not to cause the second event.


Do Not Buy Avi-On Light Switches

I bought a GE Avi-On light switch for my daughter's room. This replaces the regular wall switch with one that can be remotely controlled from her phone. The idea was to allow her to turn off the overhead light from the bed. It worked for about 10 minutes until it started downloading a firmware update to the switch, at which point the update failed. The switch no longer works. Lots of people are reporting the same issue, which means there are thousands of these switches throughout the country with this problem.

The Avi-On switches have these problems:

  1. The phone software always requires an internet connection and a login to the Avi-On site. Why? This is a Bluetooth app. There is no reason whatsoever that it needs a connection to a remote network. It only needs a connection between the phone and the switch.
  2. It requires location services turned on and access to the file system on the phone. Why? This just smacks of them just wanting to harvest information from the phone, because there is no need for these permissions. The only thing that would require these accesses is for a firmware update to be downloaded from the network to be pushed to the switch. Which leads to...
  3. The firmware update failed. You cannot push down a firmware update to remote switches if the firmware destroys the switch! And if your testing is abysmal and you somehow screw up and release a bad update, you must pull the firmware update off your site the moment you realize it. People have been reporting that the Avi-On current firmware update is causing problems for the last two months, but they are still pushing out the update.
  4. These switches supposedly make a Bluetooth mesh with other switches in the area to allow spanning past the normal range of Bluetooth. Bluetooth isn't the right technology for home control. The range is too short, which means you either need a huge number of these devices, or you need repeaters about every 33 feet apart. That's an expensive solution to home control. The goal on home control is to have connectivity that ends at the walls of your house, but not before.

In summary, do not buy Avi-On GE Bluetooth light switches, or anything else made by Avi-On Labs. I will be returning this switch to where I bought it.


Outlook VBA to Move Spam from Top Level Domains to Junk

There is a spammer who has been active for the last couple of months. The majority of my spam email has been coming from the top level domains .trade, .bid, .club, .stream, and .date. I get no legitimate mail from any of those top level domains.

I wrote a VBA routine to go through my inbox and move all email from those domains to my junk folder. It appears below:

Public Sub JunkSpamDomains()
    On Error GoTo ErrorHandler
    Dim mailItem As Outlook.mailItem
    Dim folderInbox As Outlook.folder
    Dim folderJunk As Outlook.folder
    Dim i As Long
    Dim accessor As Outlook.PropertyAccessor
    Dim strHeaders As String
    Dim lngOffset1 As Long
    Dim lngOffset2 As Long
    Dim lngDomainOffset As Long
    Dim strFrom As String
    Dim strDomain As String

    Const PR_TRANSPORT_MESSAGE_HEADERS = "http://schemas.microsoft.com/mapi/proptag/0x007D001E"    Const strBanned As String = ".trade|.bid|.club|.stream|.date"

    Set folderInbox = Application.Session.GetDefaultFolder(olFolderInbox)
    Set folderJunk = Application.Session.GetDefaultFolder(olFolderJunk)
    For Each mailItem In folderInbox.Items
        If mailItem.Class = OlObjectClass.olMail Then
            Set accessor = mailItem.PropertyAccessor
            strHeaders = accessor.GetProperty(PR_TRANSPORT_MESSAGE_HEADERS)
            lngOffset1 = InStr(1, strHeaders, vbCrLf & "From: ") + 8
            lngOffset2 = InStr(lngOffset1, strHeaders, ">")
            strFrom = Mid(strHeaders, lngOffset1, lngOffset2 - lngOffset1)
            lngDomainOffset = InStrRev(strFrom, ".")
            strDomain = Mid(strFrom, lngDomainOffset)
            If InStr(1, strBanned, strDomain) > 0 Then
                mailItem.Move folderJunk
            End If
            Set accessor = Nothing
            Set mailItem = Nothing
        End If
    Next mailItem
    Set folderInbox = Nothing
    Set folderJunk = Nothing
Exit Sub
    Select Case Err.Number
    Case Else
        MsgBox "Unexpected Error #" & Err.Number & " " & Err.Description
        Resume Next
    End Select
End Sub

Press Alt-F11 to open the VBA Editor. Select Insert Module from the menu to insert a new module. Paste this code into the window. You can bind a button on the Quick Access Toolbar (QAT) to this macro. Click the drop-down button on the right of the QAT, and select "More Commands...". Drop the "Choose Commands from:" list and select "Macros". Select "JunkSpamDomains" and click the "Add>>" button. Click the OK button.

After moving message, review the Junk folder to make sure that only spam got moved.


VBA Runtime Error Codes

I was teaching a VBA (Visual Basic for Applications) class for Excel today, and the question came up, "is there a list of all of the runtime error code numbers and what they mean?" You might be able to find one, but the easiest thing to do is to generate the list. Here is a small piece of VBA code that shows all of the runtime error code numbers and their descriptions.

Public Sub DisplayErrors()
    Dim i As Long
    For i = 1 To 65535
        If Error(i) <> "Application-defined or object-defined error" Then
            Debug.Print i & " " & Error(i)
        End If
    Next i
End Sub

When you run the code, it will print the list to the Immediate Window in the VBA Editor. Press Ctrl+G to make the Window visible.

It is possible to get other runtime errors, but only from some component that is called by VBA, not from VBA itself. When I run the code, this is the list that I get:

3 Return without GoSub
5 Invalid procedure call or argument
6 Overflow
7 Out of memory
9 Subscript out of range
10 This array is fixed or temporarily locked
11 Division by zero
13 Type mismatch
14 Out of string space
16 Expression too complex
17 Can't perform requested operation
18 User interrupt occurred
20 Resume without error
28 Out of stack space
35 Sub or Function not defined
47 Too many DLL application clients
48 Error in loading DLL
49 Bad DLL calling convention
51 Internal error
52 Bad file name or number
53 File not found
54 Bad file mode
55 File already open
57 Device I/O error
58 File already exists
59 Bad record length
61 Disk full
62 Input past end of file
63 Bad record number
67 Too many files
68 Device unavailable
70 Permission denied
71 Disk not ready
74 Can't rename with different drive
75 Path/File access error
76 Path not found
91 Object variable or With block variable not set
92 For loop not initialized
93 Invalid pattern string
94 Invalid use of Null
96 Unable to sink events of object because the object is already firing events to the maximum number of event receivers that it supports
97 Can not call friend function on object which is not an instance of defining class
98 A property or method call cannot include a reference to a private object, either as an argument or as a return value
321 Invalid file format
322 Can't create necessary temporary file
325 Invalid format in resource file
380 Invalid property value
381 Invalid property array index
382 Set not supported at runtime
383 Set not supported (read-only property)
385 Need property array index
387 Set not permitted
393 Get not supported at runtime
394 Get not supported (write-only property)
422 Property not found
423 Property or method not found
424 Object required
429 ActiveX component can't create object
430 Class does not support Automation or does not support expected interface
432 File name or class name not found during Automation operation
438 Object doesn't support this property or method
440 Automation error
442 Connection to type library or object library for remote process has been lost. Press OK for dialog to remove reference.
443 Automation object does not have a default value
445 Object doesn't support this action
446 Object doesn't support named arguments
447 Object doesn't support current locale setting
448 Named argument not found
449 Argument not optional
450 Wrong number of arguments or invalid property assignment
451 Property let procedure not defined and property get procedure did not return an object
452 Invalid ordinal
453 Specified DLL function not found
454 Code resource not found
455 Code resource lock error
457 This key is already associated with an element of this collection
458 Variable uses an Automation type not supported in Visual Basic
459 Object or class does not support the set of events
460 Invalid clipboard format
461 Method or data member not found
462 The remote server machine does not exist or is unavailable
463 Class not registered on local machine
481 Invalid picture
482 Printer error
735 Can't save file to TEMP
744 Search text not found
746 Replacements too long


C# Optimization of Switch Statement with Strings

C# does some interesting things when you have a switch statement comparing a lot of strings: Suppose you have this:

   switch (input)
        case "AAAA":
            Console.WriteLine("AAAA branch");

        case "BBBB":
            Console.WriteLine("BBBB branch");

            Console.WriteLine("default branch");


When you look at the IL (intermediate language) that it compiles into, it is essentially the same as a bunch of  if and else if statements. Converted back into C# code, it is as if you wrote this:

    if (input == "AAAA")
        Console.WriteLine("AAAA branch");
    else if (input == "BBBB")
        Console.WriteLine("BBBB branch");
        Console.WriteLine("default branch");


 However, if you continue to add case statements, this becomes inefficient. There are a lot of string comparisons that are really expensive. At a certain point, as you add cases, the compiler uses an entirely different technique to handle the cases. It creates a hash table of the strings. The IL looks like this, if it were converted back into C# code (assume there are more case statements):

    string s = input;

    switch (ComputeStringHash(s))
        case 0x25bfaac5:
            if (s == "BBBB")
                Console.WriteLine("BBBB branch");
                goto Label_0186;


        case 0xff323f9:
            if (s == "AAAA")
                Console.WriteLine("AAAA branch");
                goto Label_0186;

    Console.WriteLine("default branch");

The ComputeStringHash method is a pretty simple hash function that looks like this:

    internal static uint ComputeStringHash(string s)
        uint num = 0;

        if (s != null)
            num = 0x811c9dc5;
            for (int i = 0; i < s.Length; i++)
                num = unchecked((s[i] ^ num) * 0x1000193);

        return num;

This is a version of the FNV-1a hashing algorithm.

The change to using hashing seems to occur at about eight string case statements. The advantage is that there will be, on average, just one string comparison, the other comparisons are all comparing uint values. There is some overhead in performing the computing of the hash, which is why it doesn't use it for small number of case statements.

This actually becomes important when you are trying to write unit tests for the code. If you are trying to cover all of the branches in the unit tests, you will need to write code that hashes to 0xff323f9 but is not "AAAA" to get the goto Label_0186 branches to get covered. Your chances of finding something that hashes to the same value as your legitimate "AAAA" string without being "AAAA" is unlikely unless you are specifically trying to get a hash collision. This means that your code coverage will show branches as not being covered, even though you test every case statement in the switch statement. This will show a failure in your code coverage branch statistics (usually around only 60% covered), even though your unit test are actually adequate.

I have been working with the AxoCover and OpenCover programmers to try to get the coverage statistics for branches to be meaningful, but there may be no way to handle this correctly.

Addendum: The logic of the switch statements when it optimizes is slightly more complicated that what is presented above. The C# compiler actually performs a binary search on the hash index rather than just linearly searching through them, before getting to the comparison of the string. Performing hash collisions will raise your coverage to more than 90%, but will not go through all of the code for the binary search.


How to Convert Project from MSTest (V1) to MSTestV2

To convert a MSTest version 1 project to version 2, you need to perform several steps:

  1. In the project references, remove the reference to Microsoft.VisualStudio.QualityTools.UnitTestFramework.
  2. Edit the project file and remove the line that contains <ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
  3. Add the NuGet package for MSTest.TestAdapter.
  4. Add the NuGet package for MSTest.TestFramework
That should be all that is necessary to make the transition.


Don't Indicate Status with Just Color

Note: Since this article was written, AxoCover added configuration of colors in the settings dialog. The original point, though, was that you shouldn't indicate status with just color in your own projects.

There is a flaw in the AxoCover code coverage tool: The colors used for coverage, red and green, are hard coded. If someone were red/green color blind, this tool would be difficult to use. That creates difficulty for 8% of men and 0.5% of women. Showing status with hard coded colors with no other visual indicator is a mistake in user interface design, not just in AxoCover but in all programs. Either colors must be configurable, or an additional way of differentiating the colors (such as hatching one of them) should be used.
Status indicated with red and green bars
You'll notice that a traffic stop light indicates color with both red and green, but also with position of the colors; it does not have one light that changes color.
Traffic light uses both color and position to indicate status
Indicating status with just color, particularly red and green, is a very common UI mistake among programmers who are not color blind. While I am not color blind, I try to be aware of places where color is used wrong. This is not just an inconvenience to some people. In some cases, particularly in the United States which has the Americans with Disabilities Act (ADA), using just color to indicate status might be a violation of the law, and could have legal repercussions.

Code Coverage with AxoCover

When performing unit tests on code, how do you know if your unit tests are covering all of the code? The answer is a code coverage tool. I first used a tool like this when I was on the Microsoft Access 1.0 programming team, where we got weekly reports on how well the unit tests were covering the code. Microsoft has a code coverage tool in Visual Studio 2017, but only in the Enterprise edition. Unit tests and code coverage go together, and for Microsoft to have unit tests in the Community and Professional releases but not code coverage is kind of dumb.

Fortunately, there is a pretty competent, free, third party choice called AxoCover. You can download it from the Extensions and Updates menu item on the Tools menu in Visual Studio. It places an AxoCover menu item on the Tools menu that brings up a window to control its use. Build your solution once for AxoCover to figure out what is in there to cover. Then on the AxoCover window, click the Run button at the top. This is what it will look like:

AxoCover window in Visual Studio 2017

The critical information is on the Report tab on the left. After running the tests, AxoCover shows how much of the code got covered by percent. There are two numbers: what percent of lines and what percent of branches got covered. If there is an "if" statement, a test that hits the line counts will result in the line counting 100%, but only if both the true and false conditions are tested will the branches show 100%.
AxoCover report tab
The goal here is to get the branches to over 90%. Why not 100%? In production code, there are sometimes error handling code that can happen in only the rarest of conditions. For example: there may be code to handle if the fixed hard drive that you are writing to fails while the program is running. Sometimes trying to create a unit test for these conditions is difficult or impossible. So in general, greater than 90% is considered covered. Obviously, higher is better, but if all of your code is at 90%, you are doing pretty well. So in the example above, the coverage is 85.7%, which is good, but not good enough.

After running the tests, you can right click on a procedure in the report window and select "Show source". The source will show, with some information on the left border on what was covered and what wasn't.
Code window after running AxoCover
The green bar show lines that were covered by the unit tests. The red bar shows lines that were uncovered. The little circles show if branches were covered. In an "if" statement, you want both circles filled in. In the example above, there needs to be a unit test that covers the case "a" branch of the switch statement. After adding a unit test that covers that statement, go back to the Tests tab, build and run the tests. The report tab, then looks like this:

AxoCover report after adding new test case
Here, the coverage is perfect.

If there is one thing lacking on AxoCover, it's the documentation. The Settings tab has pretty much all of the documentation that exists.

AxoCover is really just a UI that integrate into Visual Studio. The engine that drives the code coverage is a different open source project called OpenCover, that has a command-line only interface. OpenCover is installed automatically when you install AxoCover.


How to Handle Decimal Windows Error Numbers

Occasionally, I receive error numbers from some program that are in decimal rather than the normal way that Windows discusses them, which is in hexadecimal. For example, I ran code contracts on a solution and it reported an error of -1073741571. To look up this error, several steps need to happen.

  1. Run the Windows calculator program. You can just type calc in the search on the task bar.
  2. Click on the menu icon in the upper left and select "Programmer".
  3. Click on "DEC" if it is not already selected.
  4. Type in -1073741571.
  5. Click HEX. The number comes back as FFFF FFFF C000 00FD.
  6. Ignore the top two bytes and search in your favorite search engine for C00000FD. This turns out to be a stack overflow exception. The exception is being caused by some bug in the code contracts when the Emit contracts into XML doc file checkbox is checked.
The Windows Calculator Program
The programming mode in the Windows calculator is not very well known. The other way to do conversions is to buy a HP-16C programming calculator on Ebay. None of the other calculators HP made were nearly as good for programming. I dearly love that calculator, but it's more trouble than its worth to go dig it out when the calculator in Windows is always there and you can copy and paste from it.

HP-16C Calculator


Change Visual Studio Task Bar Button to Run as Administrator

For some tasks, you need to run Visual Studio as an administrator. For example, if a build of a project needs to register for COM interop, Visual Studio will need to be run as an administrator. The easiest way to do that is to pin Visual Studio to the task bar, then change the button to run as an administrator.

To pin Visual Studio to the task bar, in the Start menu, right click on the shortcut for Visual Studio, click More, then select Pin to Task Bar. Then:
  1. Right click on the new Visual Studio icon on the task bar
  2. Right click on Visual Studio 2017 (or whatever version you are dealing with) from the menu that appears
  3. Left click on Properties from the menu that appears
  4. Click the Advanced button in the dialog
  5. Check the Run as Administrator check box
  6. Press OK on all the dialogs

Code Contracts in Visual Studio 2017

At the moment, the Code Contracts project has not caught up to Visual Studio 2017. As a work-around, you can copy a file from the install for Visual Studio 2015 into the proper place and it will allow the projects to build. It will not, however, enable the tab for setting the options in the Project Properties. For that you will still need to open the project in Visual Studio 2015.

The word Community will need to be replaced by the specific version of Visual Studio you have installed, Community, Professional, etc., in the script that follows.

This can be placed into a batch file (fixcontracts.bat) that can be checked into the project. Run the batch file as an administrator.

xcopy /y "C:\Program Files (x86)\MSBuild\14.0\Microsoft.Common.Targets\ImportAfter\CodeContractsAfter.targets" "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Microsoft.Common.targets\ImportAfter\"
setx /m TargetFrameworkSDKToolsDirectory "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7 Tools\\"

The line with TargetFrameworkSDKToolsDirectory sets a system environment variable to point to a directory where it can find sn.exe that re-signs the executable after adding the contracts. The defaults inside the targets file do not find sn.exe correctly (at least in some of my environments) without this variable. The two slashes at the end are not a mistake; the first escapes the second and only seems to be needed when preceding a quote mark. If you need to adjust this variable later, you can type System in the taskbar search box, then click the  Advanced system settings item, then click the Environment Variables button and edit it in the dialog that appears.
Contracts won't work with the .Net Framework 4.7, at least until they do a new release, so stick with 4.6 at the latest.


WiX MSI ICE Errors

A MSI (Microsoft Installer) file is actually a relational database. You can use the ORCA (One Really Cool App) program to examine its content. While the WiX candle compiler and light linker can check the contents of individual records in the database, it is the job of ICE (Internal Consistency Evaluators) to check if the database is created correctly.

ICE is a set of rules (written with code) that verify things such as referential integrity within the MSI file. This is a list of all of the ICE errors, what they mean, and how to fix them.


Colorizing C# Code in Blogger

I went back and revised all of the C# code in this blog using the info from here. I then colorized the keywords using this web page. This made all of the code examples a little nicer. Some day I might do the same thing for other languages and XML.

WiX Burn Command Line and Custom Bootstrapper Event Sequence

When a bootstrapper created with the WiX burn program executes, there are six possible Actions that it can handle: Install, Uninstall, Layout, Modify, Repair, and Help. (There are three more listed in the enum, but I don't know how they get triggered as they are not supported on the command line: Cache, UpdateReplace, and UpdateReplaceEmbedded.) The actions can be triggered by a switch on the bootstrapper application's command line:

setup [/install|/uninstall|/layout [path]|/modify|/repair|/help|/?] [/full|/none|/passive|/embedded] [other parameters]

The default is /install /full. The /help and /? options both cause the Help action. You can detect which Action was passed by checking this.Command.Action and comparing the values to the enum LaunchAction. You can detect which Display option was passed by checking this.Command.Display against the enum Display. If you are constructing your own interface, you can interpret the Action and Display switches as you see fit. If you don't want to support one, you should return an error. The /layout option may have an optional path, which can be retrieved from this.Command.LayoutDirectory.

Other information can be passed on the command line, which can be read from this.Command.GetCommandLineArgs(), which returns a string array. The string array will have the Action or Display options stripped.

The actual parsing of the command line is found in this C++ code in the ParseCommandLine() method.

When a WiX custom bootstrapper executes, there are a series of events that occur. Although you can add your own event handlers, there is no need. Instead, when you inherit from BootstrapperApplication, you can then override methods whose names all begin with On. If you override one of these method, you should call the base method at the end. For example:

protected override void OnStartup(Microsoft.Tools.WindowsInstallerXml.Bootstrapper.StartupEventArgs args)
    this.Engine.Log(LogLevel.Standard, "OnStartup");

Below is the sequence of events as they occur, and which Action causes them to execute. It is helpful to have these as comments in the Custom Bootstrapper file, so I've formatted them to be copied and pasted.

// I=Install U=Uninstall L=Layout M=Modify R=Repair
//// OnStartup (IULMR)
////  OnDetectBegin (IULMR)
////   // For each package
////   OnDetectPackageBegin (IULMR)
////   OnDetectPackageComplete (IULMR)
////  OnDetectComplete (IULMR)
////  OnPlanBegin (IULMR)
////   // For each package
////   OnPlanPackageBegin (IULMR)
////   OnPlanPackageComplete (IULMR)
////  OnPlanComplete (IULMR)
////  OnApplyPhaseCount (IULMR)
////  OnApplyBegin (IULMR)
////   OnCacheBegin (LR)
////    OnProgress (L)
////    OnCachePackageBegin (LR)
////     OnResolveSource (L)
////     OnCacheAquireBegin (LR)
////      OnCacheAcquireProgress (repeats) (LR)
////     OnCacheAquireComplete (LR)
////     OnCacheVerifyBegin (LR)
////      OnCacheAcquireProgress (repeats) (LR)
////     OnCacheVerifyComplete (LR)
////     OnProgress (LR)
////    OnCachePackageComplete (LR)
////   OnCacheComplete (LR)
////   OnElevate (IUM)
////   OnRegisterBegin (IUM)
////   OnRegisterComplete (IUM)
////   OnExecuteBegin (IULMR)
////    OnExecutePackageBegin (IUR)
////     OnExecuteProgress / OnExecuteMsiMessage (repeats) (IUR)
////     OnProgress (IUR)
////    OnExecutePackageComplete (IUR)
////   OnExecuteComplete (IULMR)
////   OnUnregisterBegin (IUMR)
////   OnUnregisterComplete (IUMR)
////  OnApplyComplete (IULMR)
//// OnShutdown (IULMR)

// Other events that may occur:
// OnDetectCompatiblePackage
// OnDetectForwardCompatibleBundle
// OnDetectMsiFeature
// OnDetectPriorBundle
// OnDetectRelatedBundle
// OnDetectRelatedMsiPackage
// OnDetectTargetMsiPackage
// OnDetectUpdate
// OnDetectUpdateBegin
// OnDetectUpdateComplete
// OnError
// OnExecuteFilesInUse
// OnExecutePatchTarget
// OnLaunchApprovedExeBegin
// OnLaunchApprovedExeComplete
// OnPlanCompatiblePackage
// OnPlanMsiFeature
// OnPlanRelatedBundle
// OnPlanTargetMsiPackage
// OnRestartRequired
// OnSystemShutdown


Visual Studio 2017 Missing Guidgen.exe

I installed Visual Studio 2017 on a machine today. I installed the minimal set of things needed to perform the compile that I needed. When I went to create a GUID, selecting Tools > Create GUID from the Visual Studio menu, it complained that it was missing guidgen.exe. I went back to the Visual Studio installer (C:\Program Files (x86)\Microsoft Visual Studio\Installer\vs_installer.exe) and selected Modify. From there I selected Individual components, then check the box for VC++ 2017 v141 toolset (x86,x64) in the Compilers, build tools, and runtimes section. When I clicked the Modify button, it then installed the guidgen.exe program, among other things.

This is actually a bug in the Visual Studio 2017 install. It should not add the Create GUID to the tools menu if it doesn't also install the guidgen.exe tool.

I reported this bug to Microsoft. They say that it is fixed in an upcoming release.


Extract the Contents of a WiX Burn Setup Executable

To extract the contents of a setup executable created by the WiX Burn compiler, use this command line:

dark setup.exe -x extractfolder

This assumes that the dark.exe program is on the path, that the name of the executable that you want to extract is setup.exe and that extractfolder is the path to the folder in which you wish to extract the contents. It will create two sub-folders: AttachedContainer and Ux. The AttachedContainer folder will have the payloads that are installed into the executable. The Ux folder will contain all of the files necessary to build the user interface of the application.


Be Careful About Formatting WiX XML Files

During the construction of a WiX MSI file, I was getting an error that looked like this

ICE17: Bitmap: '

It took a bit to debug what was causing it. I eventually used the WiX dark tool to decompile the MSI file, then looked for places where it might be referencing a bitmap. This is what I saw in the file (with some attributes removed):

<Control Id="BannerBitmap" Text="&#xD;&#xA;        WixUI_Bmp_Banner&#xD;&#xA;    "/> 
Makes perfect sense what was happening. This is what the XML in the source looked like:

    <String Id="BannerBitmap" Overridable="yes">

What had happened is that I had used Visual Studio to reformat the XML, which inserted Carriage Return/Line Feed (the &#xD;&#xA;) and spacing around the WixUI_Bmp_Banner. When WiX went to write the error into the error file, the first Carriage Return ended the error message, and it lost the rest of the message that had what it was complaining about. It's a bug in the WiX light compiler that it doesn't show the right error message, but perfectly understandable what is happening. All that is needed to fix the error is removing all the formatting.

<String Id="XocReadMeDlgBannerBitmap" Overridable="yes">WixUI_Bmp_Banner</String>

Looking at the output from the dark program shows several places where the formatting has messed up the strings being used in the files. I recommend using dark to find places in your files that might have subtle errors like this. It's important to know that WiX is actually putting all the white space in the MSI files, including Carriage Return/Line Feed and all spaces and tabs that appear in the XML files.

Transitioning from InstallShield LE to the WiX Toolset

I am making the transition from using InstallShield LE (Limited Edition) to using the WiX toolset for the installation of the Xoc Maya Calendar program that I developed. Both InstallShield and WiX use the Microsoft Windows Installer to do the heavy lifting. The Microsoft Windows Installer is a database with the extension .msi that has all of the information to install a program inside it. It cannot do a few things, though, such as install the .NET Framework before it runs. For that it needs a bootstrapper program that does the install of the framework, extracts the MSI file, then uses the Microsoft Installer exec (msiexec.exe) program to actually do the main install.

InstallShield provides an interface for creating both the MSI file and the bootstrapper. However, it has some limitations that have caused me to move to using WiX. These are the reasons I have moved:
  • The full version of InstallShield is expensive. It is $699 to $4999 depending on the version you get. There is a Limited Edition version, however, that was less, and that was what I was using.
  • The Limited Edition came with Visual Studio 2015 Professional. However, it did not work with the Community Edition. The Community Edition is the free version of Visual Studio for very small companies (like mine) and educational purposes. As a Microsoft Alumni, I can get Professional Edition at a steep discount, but it gives me no benefit over the Community Edition, except providing the license to use InstallShield LE.
  • InstallShield LE is just that, limited. There are many kinds of installs that it won't create. WiX can create anything that the MSI files support.
  • However, this is the killer: InstallShield LE is not out for Visual Studio 2017. It's not just that it isn't out now, and might be out in a month, it's that there might be significant periods in the future where it is unavailable when there is a lag between a Visual Studio release and an InstallShield release.

WiX is free and open source. The main drawback is that the learning curve to using it is steep. It is configured entirely by XML files; there is no user interface other than some minimal integration with Visual Studio. There are some attempts at providing a UI to creating the XML files, but none of them is as slick as InstallShield. It's not that XML configuration is difficult. I actually prefer XML to a UI, it's that there are a lot of options, and in some cases, it is not entirely clear how they interact. The UI can provide a list of Windows releases or .NET Framework releases rather than knowing exactly what value that needs to be entered into the XML.

After a few days of working with WiX, I broke down and essentially bought the documentation, which is the book WiX 3.6: A Developer's Guide to Windows Installer XML. (WiX is on 3.11 with 4.x in beta at this point, but the book is still the best there is.) This book is really essential for creating WiX installs. The documentation of each of the entries in the XML file is on the WiX web site, but the way to tie them together to make an install is found in the book. With a few days of working my way through the book, I am well on my way to having a new install process.

There is one tip that you may find useful if you make the transition from InstallShield to WiX. (I, of course, found this out after I had done most of the work by hand!) You can actually use some tools to create an equivalent WiX WXS file from the InstallShield executable. You will need the InstallShield setup file and the dark.exe tool that comes with the WiX toolset. Assuming that the setup program is setup.exe, that the MSI file that it extracts is setup.msi, and that the dark program is on the path, from an elevated command prompt execute the following commands:

setup.exe /x /b"." /v"/qn"
dark -x . "setup.msi" "setup.wxs"

The first line extracts the MSI file from the InstallShield executable into the current directory. The second line extracts the binary resources from the MSI file into sub-directories and creates a file called setup.wxs that has the WiX XML necessary for producing that MSI file. The WXS file will have a lot of cruft in it created by InstallShield that should be cleaned up, but it will save you a lot of work on trying to create an equivalent WiX file for the InstallShield setup.


WiX Votive Preprocessor Variable Not Finding Project Name

In WiX, the votive preprocessor variables allow the use of syntax such as $(var.ProjectName.TargetDir), where the ProjectName is the name of a project within your solution. However, you may get an error that the variable is undefined. If so, the most likely reason is that you need to add a reference to the project mentioned in ProjectName to the WiX project that is using the variable.

I got on a wrong track thinking that maybe WiX was confused by the fact that I had periods inside the project name. That, however, was a red herring. It would have complained about any project name.


The Design of Everyday Things

When I worked at Microsoft, they gave anyone who wanted one copies of several books. One was The Design of Everyday Things (originally called The Psychology of Everyday Things), by Don Norman. The Design of Everyday Things is still one of my favorite books. It is not really about computer interfaces, but all the rules apply to computers. It covers things like: why is it that when you come to a door in a building you are always pushing when you should be pulling, pulling when you should be pushing, or pushing on the side where the hinge is? It's because the door design told you to do that (and don't you feel stupid when you do!). If designers were allowed to design emergency exits, lots of people would die in fires. We don't let designers create emergency exits. Think about that the next time you click on something that looks like a hyperlink and you don't go anywhere.


WiX Splash Screen Not Showing

I am working with WiX 3.11, the Windows Installer Toolkit. I was having a problem with the splash screen not showing when specified in the SplashScreenSourceFile attribute. The WiX log file recorded "Error 0x80070057: Failed to load splash screen bitmap." I eventually found this post that says that the version of the bitmap matters. Gimp and other programs output the wrong version for WiX. This is probably a bug in WiX. I opened the bitmap in Microsoft Paint and saved it again. After doing that, the splash screen started showing.

Note that the WiX splash screen must be a bitmap, not a png, jpg, or any other file format.