Tag Archives: C#

For a recent project we’ve been working on we needed to get a screen shot of a form and it’s contents. After much checking on the net for some sample code, all of which used GDI32 and User32 calls, we gave up looking and decided to investigate ourselves.

In the end it was so simple and clean that we just can’t believe that this isn’t documented that well anywhere on the web. The code below is an extract of our code that takes the forms position on the screen, creates a bitmap of the contents of the screen from co-ordinates passed to it and then saves the resultant screen shot to a file

using (Bitmap bitmap = new Bitmap(ParentForm.Size.Width, ParentForm.Size.Height))
{
using (Graphics g = Graphics.FromImage(bitmap))
{
g.CopyFromScreen(new Point(ParentForm.DesktopLocation.X, ParentForm.DesktopLocation.Y), new Point(0, 0), ParentForm.Size);
}

bitmap.Save(@”C:\test.jpg”, ImageFormat.Jpeg);
}

Enjoy 🙂

Ok…. quite simple you might think! And yes it is, but only if you know how!

For a small project that we are working on at the moment we needed to show a Windows Form in full screen mode without the taskbar etc… It is quite simple in the end but needs a couple of Win32Api calls, but that is simple enough. The one thing that is easy to forget is that you need to set the FormBorderStyle property for the form to None, otherwise you will still have the menu bar showing.

To acheive the full screen mode create a simple class with the code below in it

[DllImport(“user32.dll”, EntryPoint = “GetSystemMetrics”)]
public static extern int GetSystemMetrics(int which);

[DllImport(“user32.dll”)]
public static extern void SetWindowPos(IntPtr hwnd, IntPtr hwndInsertAfter, int X, int Y, int width, int height, uint flags);

private const int SM_CXSCREEN = 0;
private const int SM_CYSCREEN = 1;
private static IntPtr HWND_TOP = IntPtr.Zero;
private const int SWP_SHOWWINDOW = 64;

public static int ScreenX
{
get { return GetSystemMetrics(SM_CXSCREEN); }
}

public static int ScreenY
{
get { return GetSystemMetrics(SM_CYSCREEN); }
}

public static void SetWindowFullScreen(IntPtr hwnd)
{
SetWindowPos(hwnd, HWND_TOP, 0, 0, ScreenX, ScreenY, SWP_SHOWWINDOW);
}

Then in your application simply create a new instance of the form and call the Show method on the form.

Form form1 = new Form();
form1 .Show(this);

Then finally create an OnLoad handler for the form and call the SetWindowFullScreen method on our helper class and that is it.

WinApi.SetWindowFullScreen(Handle);

C++ installations have never been easy and probably never will be. Having not done any C++ release work for a number of years I ran into a problem when releasing a C++ application that I built using Visual Studio 2005.

In the old days you had a nightmare working out which version of the C++ libraries to distribute and where to put them. Unless of course you statically link to the libraries which resolves the problem but makes the files rather larger.

But now with building the application using VS 2005, there is this new problem that arises which results in the obsure message

This application has failed to start because the application configuration is incorrect

After a bit of digging into all of this I found that there is a redistributable package from Microsoft that installs the necessary libraries for C++ that were used by VS2005 to build the application in the first place. Where it puts the libraries I don’t know, but to be honest I don’t really care as the installation was very simple and worked first time….so i’m happy for now.

Heres a link to the redistributable package from Microsoft.  This is the SP1 version of the package which is required if your VS2005 installation is all up-to-date. If it isn’t there is an older version of the package available from Microsoft, or your could do the right thing and get VS2005 up-to-date instead.

Previously I have always done the following to iterate through a bDataReader

while(reader.Read())
{
int index = reader.GetOrdinal(“User_Description”);
list.Add(reader[index] as string);
}
But today I stumbled upon the following which is so much neater:

foreach (DbDataRecord dbDataRecord in reader)
{
int index = dbDataRecord.GetOrdinal(“User_Description”);
list.Add(dbDataRecord[index] as string);
}

I just think it’s a lot neater and clearer as to what’s going on.

Just recently I had a problem whereby there was a case which resulted in the current working directory changing before some of my code had run. As I hadn’t catered for this case it came up with a crash which was easily fixed by getting the current application path and then combining this with the filename which I wished to access. Heres the code that I used to acheive this in a nice clean fashion and create a path to a configuration file (configurationFilename):

Uri uri = new Uri(System.Reflection.Assembly.GetExecutingAssembly().CodeBase);
string fullConfigurationFilename = Path.Combine(Path.GetDirectoryName(uri.AbsolutePath), configurationFilename);
fullConfigurationFilename = HttpUtility.UrlDecode(fullConfigurationFilename);

By using reflection to get the location of the currently executing assembly I am not relying on the actual .exe location (or website location in fact), but instead using the actual dll’s location from which the current code is running. You might wish to use the actual application’s path or the website root path, but in the scenario that I am using this in, the assembly’s path is exactly what I wanted.

Having recently created a simple framework for other developers to use, I needed to create a custom Exception class to use when throwing exceptions.

When throwing an exception in a WinForms application I always generate my own Exception class, which adds some other useful information that I can package along with the actual exception that was originally thrown. Although the Call Stack is included in the actual exception, one thing that I like to do is tell the developer the method in which the exception was originally thrown. This removes the need for the developer to navigate through the exception as all they are initially after is where the Exception occured.

In the past I would have normally simply passed in the method name like so:

throw new Exception(connSettings, MethodBase.GetCurrentMethod().Name, “Argument is Null”, ex);

But I decided to spend some time making this transparent. In the end I was able to put this in the actual Exception class using the following method which is called as a part of the constructor of the Exception class:

private void SetCallingMethod()

{
method = new StackFrame(2, false).GetMethod().Name;
}

In this we open up a new stack trace and navigate to the second frame in the trace (remembering that frame 1 of the stack will result in the constructor method). Now the code to create the new exception is simpler:

throw new Exception(connSettings, “Argument is Null”, ex);