Monthly Archives: January 2011

No process window for C# console apps

When I’m using windows and I need a quick and dirty app which is never going to be cross-platform, I like to use C# .Net. It’s pretty fast to get something up and running, and C# is enjoyable to work with. One of the things I often find myself trying to do is prevent an ugly console window from opening up when I’m running an app. There are multiple ways to do this, but they all have their drawbacks.

First method:
Process proc= new Process();
proc.StartInfo.FileName = "cmd.exe"; 
proc.StartInfo.CreateNoWindow = true;
proc.Start();

Drawback: CreateNoWindow doesn’t work if you start a process with UseShellExecute = true.

Second method:
Process proc= new Process();
proc.StartInfo.FileName = "cmd.exe"; 
proc.WindowStyle = ProcessWindowStyle.Hidden;
proc.Start();

Drawback: ProcessWindowStyle.Hidden is only a suggestion, and the child process can always show itself.

Third method:
[DllImport("user32.dll")]
static extern IntPtr FindWindow(string lpClassName,string lpWindowName);
 
[DllImport("user32.dll")]
static extern bool ShowWindow(IntPtr hWnd, int nCmdShow);
 
const int SW_HIDE = 0;
const int SW_SHOW = 5;
 
static void Main()
{
    Process proc = new Process();
    proc.StartInfo.Verb = "Print"; 
    proc.Start(); 
    ShowWindow(hWnd, SW_HIDE); // Hide console window
}

Drawback: Dll imports are ugly. Why can’t I do this in regular .Net?

And a little trick:
If you don’t need your console app to show up at all, go to your project configuration and change your output type to “Windows Application”.

Environment variables and Process.Start

This is a problem that I’ve come across a couple of times now. I want to spawn a process from .Net with changes to the path or other environment variables, but I don’t want to modify the local environment variables for the calling process. Or I need to run a third-party batch file that configures the environment, and then run something else.
Process.Start("setenv.bat");
Process.Start("app.exe");
Uh oh. No good, because each of the Processes spawn with their own local copy of the environment, and so the environment that is used by app.exe is a fresh copy of the environment used by the .Net app. The easiest solution is to just create another batch file that calls them both and call that instead.
Process.Start("setenv_and_then_call_app_exe.bat");
But as soon as it gets more complicated than that, the preferred solution is to run the two in the same environment, which can be done by running a process and redirecting standard input.
Process proc = new Process();
proc.StartInfo.FileName = "cmd.exe"; 
proc.StartInfo.UseShellExecute = false;
proc.StartInfo.RedirectStandardInput = true;

proc.Start();
StreamWriter cmdWriter = proc.StandardInput;
cmdWriter.WriteLine("setenv.bat");
cmdWriter.WriteLine("app.exe");

Now the changes to the environment made by setenv.bat will persist and affect the execution of app.exe.

Adding code samples with SyntaxHighlighter 3.0

When you’re writing a technical post on coding, it’s important to be able to post code samples to show people exactly what you mean (and make it easier for them to cut and paste). But the standard behaviour for the <code> tag only forces the browser to render in a fixed-width font:

$(function() { $( "#button" ).click(function(){ $( ".classOld" ).switchClass( "classOld", "classNew", 1000 ); return false; }); });


Garbage, right? If you add the <pre> tag, you get your tabs and formatting back:

$(function() {
    $( "#button" ).click(function(){
        $( ".classOld" ).switchClass( "classOld", "classNew", 1000 );
        return false;
    });
});

That’s a bit better, but what we’re really missing is the pretty colors that help us parse the code semantics.

$(function() {
    $( "#button" ).click(function(){
        $( ".classOld" ).switchClass( "classOld", "classNew", 1000 );
        return false;
    });
});

That’s more like it! This code highlighting is the result of a fantastic open-source tool by Alex Gorbatchev called Syntax Highlighter, which you can find at http://alexgorbatchev.com/SyntaxHighlighter/.

Basic usage

1. Download the syntax highlighter package from the download page and install it somewhere where it is open to the web.
2. Insert the following code into the head of your html file, making sure to replace the paths with the correct paths for your installation (there is also a hosted version at http://alexgorbatchev.com/pub/sh/current/).

<script type="text/javascript" src="scripts/shCore.js"></script>
<script type="text/javascript" src="scripts/shBrushJScript.js"></script>
<script type="text/javascript" src="scripts/shBrushXml.js"></script>
<link href="styles/shCore.css" rel="stylesheet" type="text/css" />
<link href="styles/shThemeDefault.css" rel="stylesheet" type="text/css" />
<script type="text/javascript">
     SyntaxHighlighter.all()
</script>
3. Insert the following into your html body:
<pre class="brush: js">
$(function() {
    $( "#button" ).click(function(){
        $( ".classOld" ).switchClass( "classOld", "classNew", 1000 );
        return false;
    });
});
</pre>

And you have a basic code syntax highlighter running. Check out the configuration options if you want more control.

Notes:

Make sure to include the appropriate brushes for the syntax you want to show. This example includes the Javascript (“shBrushJScript”) brush and the HTML (“shBrushXml”) brush.
The vertical scroll bar shows up in Safari and Chrome because there is a 1 px offset introduced. This can be corrected by adding a pixel of padding to the .syntaxhighlighter class in the shCore.css file. Not the most elegant solution, but it works.

.syntaxHighlighter {
  padding: 0 1px !important;
...
}