C# WinFroms Splash Screen

One fo the first challenges I faced as a C# developer writing windows forms applications was the concept of a splash screen with a progress bar. While in principle it seemed simple, opening a different form in a separate thread and making its controls updatable from the first thread was alien to me.

I decided to (finally) write this post after seeing a lot of requests for help around this subject on various forums. The main thing new developers struggle with when attempting their very first splash screen are delegates.

To start with, either create a blank Windows Forms Application in Visual Studio or follow the steps below in the project you are adding a splash screen to. If you are creating a new project, you will find Form1.cs, which we will leave as is for this tutorial. Imagine that Form1 is going to be the main window of your application.

Now go and add a new Windows Form to your project and call is SplashScreen.cs. Add a Progress Bar control to your new form and resize the form around it. Now change the FormBorderStyle property for the form to None and StartPosition to CenterScreen. I’ve also changed the BAckColor property to red to make it a bit more visible for this tutorial.


Now head into the code view for SplashScreen.cs (right click it in the solution explorer windows and click View Code).

The code for the splash screen is reasonably straight forward if you know how delegates and threads work. Check out the comments for some information on what each section does.

using System;
using System.Threading;
using System.Windows.Forms;

namespace SplashScreenTutorial
public partial class SplashScreen : Form
//The delegates required to invoke methods from a different thread
private delegate void CloseDelegate();
private delegate void UpdateDelegate(string txt);

private SplashScreen _splashInstance;

//The initializer for the SplashScreen Class
public SplashScreen(int max)
progressBar1.Minimum = 0;
progressBar1.Maximum = max;

//Private method used to display the splash creen form.
private void ShowForm(object max)
_splashInstance = new SplashScreen(Convert.ToInt32(max));

//Public method that spawns a new thread and calls the ShowForm() method to lauch the splash screen in the new thread.
public void ShowSplashScreen(int max)
if (_splashInstance != null)
Thread thread = new Thread(ShowForm);
thread.IsBackground = true;

//Public bool to check if the splash screen is ready.
public bool Ready()
return (_splashInstance != null) && (_splashInstance.Created);

//Public method used to update the progress bar progress and text from your main application thread.
public void UpdateProgress(string txt)
_splashInstance.Invoke(new UpdateDelegate(UpdateProgressInternal), txt);


//Public method used to close the splash screen from your main application thread.
public void CloseForm()
_splashInstance.Invoke(new CloseDelegate(CloseFormInternal));

//The private method invoked by the delegate to update the progress bar.
private void UpdateProgressInternal(string txt)
_splashInstance.progressBar1.Text = txt;

//The private method invoked by the delegate to close the splash screen.
private void CloseFormInternal()


Next you need to add a bit of code to your Program.cs file to call the splash screen and update it between each task during your application startup process. Make sure it goes before Application.Run(Form1).

static void Main()

//Instantiate a new instance of SplashScreen
SplashScreen splash = new SplashScreen(4);
//Display the splash screen with a max value for the progress bar

//Wait for the form to be loaded.
while (!splash.Ready())
//Loop to wait for the splash screen to be ready before trying to
update it. We will get a null reference exception if the splash screen isn't ready yet.

//Update the progress bar
splash.UpdateProgress("Loading Step 1");
//Perform action
Thread.Sleep(1000); //Lets pretend this is doing something constructive
//Update the progress bar
splash.UpdateProgress("Loading Step 2");
//Perform action
Thread.Sleep(1000); //Lets pretend this is doing something constructive
//Update the progress bar
splash.UpdateProgress("Loading Step 3");
//Perform action
Thread.Sleep(1000); //Lets pretend this is doing something constructive
//Update the progress bar
splash.UpdateProgress("Loading Step 4");
//Perform action
Thread.Sleep(1000); //Lets pretend this is doing something constructive
//Close the Splash Screen

//Launch your main application form
Application.Run(new Form1());

That’s all there is to it. I’m not going to go into a load of detail about threads and delegates in this post. To be honest it’s mainly because I can’t be bothered because both subjects are tedious and boring.

And for all those who are still reading, the example project is available here for download.

Controlling the Startech VS421HDPIP with C#

As part of a project I have been working on to spec and install a video conferencing solution I purchased a couple of Startech VS421HDPIP units to switch between camera inputs. I chose this unit for a couple of reasons; it has enough inputs for the project, it’s capable of doing picture in picture, it can be controlled via telnet or RS232, our supplier could get it for half the RRP and it’s made by Startech, who’s kit has never left us in an awkward situation.

When I first hooked it up it just worked and the presets that were built-in were decent. Unfortunately it didn’t have presets to support the use cases I required, but I expected that from reading the manual prior to purchasing them. The presets can be changed from the web interface, which is the only downside to this unit… its utter pants. Fortunately it supports some pretty advanced commands via telnet so all is not lost. After playing with the telnet prompt for a while I figured that I could probably write some form of application to change the video output layout from a PC, which would certainly make it more user-friendly. The VC solution is going to be installed in a remote office and anything to make operation easier for the end users is a big plus. This will also allow me to have basically unlimited “presets” to cover more use cases without reconfiguration. Bonus.


I decided that the application should probably allow control of the PTZ cameras too to encompass the entire VC solution in one control panel, so a simple “driver” style API would be the best bet for controlling each component. The driver for the Startech VS421HDPIP only took two hours to write, including an application to test the class, and is incredibly simple to use. It is available to download at the end of this post. Here’s an example of how to use it.

//create a new instance of the VS421HDPIP class.
VS421HDPIP Conn = new VS421HDPIP();

//set the unit IP address and port
Conn.Ip = IPAddress.Parse(“”;
Conn.Port = 23;

//open the connection to the unit.

//execute commands. See list of commands in the accompanying blog post.
Conn.PowerOn();  //Power on the unit from standby
Conn.Recall(VS421HDPIP.WindowState.Fav1);  //Recall the Fav.1 Preset
Conn.SetImagePosition(VS421HDPIP.InputChannel.Input2, 1420, 790); //Sets the possition of channel 2.

//always close the connection when done. The unit only allows one session at a time and not closing a session will result in you having to reboot the unit or waiting for the session timeout on the unit before opening a new connection.

Unfortunately the telnet prompt doesn’t let you retrieve information. Maybe this is something Startech will add to future models but it is what it is.


The commands I implemented are basically identical to the commands listed in the manual for the VS421HDPIP. I won’t go over available parameters for each here. The parameters are similar to those listed in the manual as well so I’m sure they’d be easy to figure out with intellisense.

  • PowerOn() – Power on the unit from standby.
  • PowerOff() – Place the unit in standby.
  • SetOutResolution(Resolution res) – Sets the output resolution.
  • OsdDisable() – Disable the On Screen Display.
  • OsdEnable() – Enable the On Screen Display.
  • OsdHOffset(int offset) – Sets the horizontal offset of the OSD.
  • OsdVOffset(int offset) – Sets the verticle offset of the OSD.
  • OsdTimeout(int timeout) – Sets the timeout of the OSD.
  • OsdGain(int gain) – Sets the gain of the OSD.
  • SetBrightness(InputChannel chan, int level) – Sets the brightness level of an input.
  • SetContrast(InputChannel chan, int level) – Sets the contrast level of an input.
  • SetSaturation(InputChannel chan, int level) – Sets the saturation level of an input.
  • SetHue(InputChannel chan, int level) – Set the hue level of an input.
  • Mute() – Mutes the audio output of the unit.
  • Unmute() – Unmutes the audio output of the unit.
  • SetImageSize(InputChannel chan, int h, int v) – Sets the size of a channel.
  • SetImagePosition(InputChannel chan, int h, int v) – Sets the position of a channel.
  • ChannelImageOn(InputChannel chan) – Turns a channel on.
  • ChannelImageOff(InputChannel chan) – Turns a channel off.
  • ChannelPriority(InputChannel chan, int priority) – Sets a channel’s priority.
  • SetChannelLabel(InputChannel chan, string label) – Sets a channel’s label.
  • StoreCurrentConfiguration(Favorite loc) – Stores current settings to a preset.
  • MirrorOn() – Makes the unit mirror it’s output (rear projection).
  • MirrorOff() – Disables the output mirror feature.
  • SetOutputRotation(Rotation value) – Rotate unit output (ceiling hung projector).
  • SetFadeDuration(Fadetime time) – Sets fadetime between windows.
  • SendTelnetCommand(string command) – Send a telnet command to the unit.


I have provided the driver I wrote in case it is useful to anybody. I do so with absolutely no warranty or support and you use it at your own risk.

Compiled DLL
Visual Studio Project Files

Don’t Piss Off Your Developer(s)

Most developers enjoy their work, whether they are part of a development team, a free-lance developer or a single, in-house developer for some company somewhere. Developers are usually very clever and creative people, solving complex problems never solved before and coming up with new innovative ways for people to do things more efficiently.

The one thing developers don’t do particularly well is read the minds of the people they develop solutions for. This might seem an obvious observation, but most developers will tell you of the people they deal with that expect them to be mind readers.

The first problem is that most people struggle to convey their thoughts and requirements in a meaningful way to the developer, expecting the developer to instinctively know how you want a certain solution to work or behave. This isn’t the case. Work with your developer before they start work on your solution to make sure they understand what you want. Create a statement of requirements to outline the key features you want, how you want them to work, and how you want user interfaces to look, even if it’s just a rough drawing to show layout and some crayons to show the colour scheme required. Your developer will thank you, trust me.

Secondly, don’t try to pretend you know all about development when dealing with the developer, even if you do. You might well be, or have been, a developer yourself, but at the end of the day each developer does things their own way and you trying to tell them how to do it just gets their back up. Don’t forget, you are asking the developer to create something for you, not paying them to listen to how you would do it.

Another way to piss a developer off is to provide a statement of requirements, and then proceed to change your mind once the developer has started working on the delivery of your requirements. It doesn’t matter that you are paying the developer for his or her time, changing a software solution half way through development usually involves deleting code that the developer has spent a lot of time writing, and always leads to delays in delivery. It might mean more money for the developer, but what if the developer has booked his or her time out to another project or customer and your “tweaks” means they are unable to start the next piece of work.

Now you might be thinking why you should care if your developer is pissed off if you are paying for his time. I’ll tell you. A pissed off developer is a stressed developer, and a stressed developer makes more mistakes in the code, leading to bugs. This isn’t a deliberate act of vengeance for all the times you did successfully piss your developer off, its simple psychology. When people get stressed, they try to get out of the stressful situation as quickly as possible. This can lead to lapses in concentration and even corner cutting to get the job done quicker, meaning more bugs in the end product.

Don’t get me wrong, bugs happen. It’s impossible to write software without bugs (except maybe print(“Hello World”);). All I’m saying is there is an increased probability of bugs if you piss off your developer.