semi/signal

Shell extensions (at least in Windows, I can’t speak to other platforms) are not easy to write and require some pretty ugly native code, requiring Win32 and COM code. For most applications, the .NET Framework can usually provide a nice wrapper for such code, but not for shell extensions. Prior to .NET 4, using the .NET Framework was dangerous because, as explained in this forum post, an extension would attempt to inject a version of the .NET Framework (the version the shell extension was written in) into every application affected by the extension (i.e. every application making use of the shell component extended), but only one version of the .NET Framework can be loaded in a process, potentially creating conflicts with other applications using different versions of .NET.

.NET 4 can be loaded side-by-side with other versions of the framework, so shell extensions are technically possible, and I was happy to find an article + code sample detailing how to write an extension as part of Microsoft’s All-In-One Code Framework. Unfortunately, the code sample has since disappeared and, regarding .NET 4 shell extensions, Jialiang Ge of the All-In-One Code Framework team explains:

In .NET 4, with the ability to have multiple runtimes in process with any other runtime. However, writing managed shell extensions is still not supported. Microsoft recommends against writing them.

No much of an explanation, to say the least.

This is how to embed a WebKit instance within a WinForms application. I promised, a long time ago, to show this, but never got around to it. The process itself is pretty simple, assuming you have WebKit compiled (which can be pretty difficult) because you’ll need to be able to link with the WebKit libraries, specificially: WebKit.lib and WebKitGUID.lib (which, of course, have dependencies on all of the other libraries produced in the compilation). I’m going to be using a older version of WebKit, the same one I played with in my previous blog posts, as I don’t have time to check out the newest version of WebKit. Hopefully, the interfaces are the same or similar and what I’m about to describe here can be adapted easily to work with the latest version.

What we’re going to do is create a CLI wrapper to allow the .Net application to access the native WebKit code. To mix managed and unmanaged code, we’re going to need to create a C++/CLI application. Yes, it is going to be ugly code, but it works and (I think) much simpler than trying to P/Invoke functions in WebKit.dll.

Here’s the wrapper code (I’ve also included a compiled dll in the /Release folder):
WebKitCLIWrapper.dll.zip

WebKitNativeController.h and WebKitNativeController.cpp is adapted from the demo code provided by Apple. WebKitCLIWrapper.h (shown below) is the C++/CLI .NET code that wraps the native controller.

Now, we can simply include WebKitCLIWrapper.dll in any .Net project as a reference and access the wrapper to create a WebKit instance. So if your in Visual C#, create a new WinForms app, create a Panel (panel1) on a form, and add the following to the form’s Load event:

However, before running the application, you need all the necessary libraries and necessary resources referenced by WebKit.dll in the app’s working directory (I like to set it to Debug).

For convenience, here’s a zip containing all you’ll need:
WebKit_dlls+resources.zip
(as I mentioned, this is an older version of WebKit)

With all the necessary files in place, launch the app, and a WebKit instance should load in the specified panel (panel1) along with the web page specified in LoadURL() call.

If you’d like to display and process a specific piece of HTML code, get rid of the LoadURL() call, place the code to be embedded in a string, and pass it as the 2nd argument to the WebKitCLIWrapper.Wrapper constructor. For example, this will load and embed a youtube video:

The wrapper interface is very bare-bones, but it’s good enough if you just need to display some web or HTML content in your app or, if your looking to build a .NET web browser, it will hopefully provide a starting point for how to interact with WebKit.

The following piece of C# code to open a file for reading (an MS Word document, opened by Word), generated an IOException.

The IOException:

Not too unusual, but curiously, the following code, to do the same same thing, did not generate any exceptions and the file was read successfully.

I’d always assumed that File.OpenRead() was equivalent to the File.Open() call above.
Bad assumption.
It looks like the FileShare flag is set to FileShare.Read not FileShare.ReadWrite by File.OpenRead().

Note that the FileShare flag is a bit misleading as described by the docs, it doesn’t only apply to subsequent operations. Here’s a good explanation by Darin Dimitrov from stackoverflow:

In the case of future openers, a FileShare.Read means “future openers can open the file for reading”. In the case of past openers, FileShare.Read means “open this file for me only if it has past openers that opened it for reading only”. That’s why FileShare.ReadWrite needs to be used here, because Excel opens the file for writing.

This involved drawing a filled rectangle with a TextureBrush, using a 1x[whatever] texture and setting it to be tiled.

The code above works correctly and here is what it produces,

Unfortunately if the y (top) coordinate of the rectangle is changed to anything other than 0, the rendering gets screwed up. Here is what occurs if the y-coordinate is set to 1 (which should, effectively, push everything down 1 pixel),

However, there is a way to hack around the issue, keep the y-coordinate at 0 and use Graphics.TranslateTransform() to do the y translation.

The .NET Framework has no methods to get the MIME type of a file and, as I was in need of such functionality a while back, I’m glad I found this post on CSharpFriends.com (UPDATE: removed link, CSharpFriends.com is dead) which presents a switch statement that maps numerous filename extensions to the appropiate MIME type.

I was somewhat dismayed that someone mentioned using the system registry to lookup the MIME types, and the OP seemed to have gone with this method. Using the registry cuts down your codebase, but that’s little more than a convenience; there are some important issues that pop up when using the registry in this situation:

• It only works if the file extension is known to Windows; either the version of Windows the app is running on knows of the file extension or an application puts the file extension into the registry.
• It binds (read: couples) your app to a third-party component, in a situation where there is no need to.
• It locks you into a specific platform (i.e. it won’t work with Mono). Even if it’s not a major issue, there’s no reason to lock your app to a certain platform when you don’t have to.

UPDATE: As CSharpFriends.com is dead, the code I derived from the original post is below. The FromFileName() function will take a filepath, get the extension from the filename, and return the MIME type of the file.

This time it’s an issue with the SIZE command. As explained here,

Some servers require sending “TYPE I” before the SIZE command will work.

Note that setting FtpWebRequest.UseBinary to true (which it is by default) does not correct this. When getting the response, an exception will be thrown telling you the file is unavailable and you’ll get a 550 error with the message, “SIZE not allowed in ASCII mode”.

A discussion and Microsoft’s response to this issue is available here; it pretty much boils down to tough noogies, it’ll be fixed in a future version.

I’ve been working on some FTP code in C# with the .Net framework’s FTP classes and frustrated that I was occasionally getting 503 (bad sequence of commands) errors. Turns out these errors will pop up if the FtpWebRequest.KeepAlive property is set to true, which it is by default. Unfortunately, this doesn’t really address why this is occurring in the first place. I’m doing a lot of multithreaded stuff, so perhaps that’s the culprit (i.e. 2+ threads using the same connection, layering their calls on top of each other). However, I’ve found some forum posts (such as this one) indicating others are having the same issue doing seemingly serial, non-asynchronous stuff.

I played around a bit with one of the .Net framework’s compression classes (System.IO.Compression.GZipStream) recently and got some unexpected results. First, the module is a bit weird in how in takes in and outputs data (e.g. for decompression you read directly from the GZipStream, but for compression you read from a MemoryStream), but once you get past this you run into a more significant issue: the compression library is not optimal and, in certain cases, the size of the “compressed” data can be significantly larger than that of the uncompressed input. I did a few ad-hoc and very unscientific tests, but they were good enough to give an indication that there was a problem. GZipStream is probably still good enough when there’s highly compressible data, but for situations where you don’t have any idea of what’s being compressed it’s probably best to look for another solution.

There’s a thread on MSDN about this issue (System.IO.Compression not as good as compressed folder) and also a feedback entry on MS Connect.

Surprisingly easy. I’m doing some bluetooth stuff and needed a way to see if the bluetooth support service (BthServ) was running before attempting bluetooth related system queries and socket IO.

Opening a window showing the contents of a folder and highlighting a specific file in the folder can be a pretty useful action, especially for applications that show or list files to the user, as it allows for the user to quickly get to a file and manipulate or open it via. the operating system’s shell. The most popular implementations of this features are, perhaps, in web browsers; it’s referred to by a couple of different phrases, “Open Folder” in IE7, “Show Containing Folder” in Safari, “Open Containing Folder” in Firefox.

Anyways, I wanted this feature for something I’m working on in Windows and it’s actually pretty simple to implement, but it took me a while to find information on it. There’s no Win32 function, instead, explorer has to be run with a command-line switch. Switches and accompanying examples can be found here.

So the command to open a containing folder would be:

Here’s a bit of C# code (it should be simple to do this in almost any language):

Of course, replace <file_path> with the file you want highlighted.

Based on the info here, as well as the page linked to above, it seems this should work on all versions of Windows since Win 95.