Ok, well first, the title of this post is deceiving. Really this post is about converting a byte array to a printable/displayable string in C#. The problem is that if you have an arbitrary byte array, say, representing an object from a stream or something, it may contain characters that are not actually printable or visible (i.e control characters) and when you try to use Console.WriteLine or anything of the sort, you may hear beeps or see weird shapes.

Anyway, I was coding a tool that allows inspection of objects in an MSM queue, and as such needed to somehow display a binary object. I wanted to do something similar to the Visual Studio Memory Watch debug window, where I showed the bytes that were "showable" and substituted a period ('.') for bytes that were not. Easy enough, here is the code snippet:

I lovethe expression "up-to". When marketing folks die and enter the afterlife, presumably it's up to 100% heaven. The nice thing about "up to" is that it encompasses the null set of whatever range it is cast upon. Up to 99% success rate could very well be 0% success rate since it satisfies the idiomatic condition.

Anyway, so I was coding in Java the other day and ran into a decent candidate for the WTF files.

 I was doing this very basic un-encryption thing, where I was reading file and un-encrypting it using the specified key. Pretty basic stuff.

I was using the CypherInputStream class to read the file stream and decrypt it. I user CypherInputStream.read method and everything was dandy until in my testing I noticed that a portion of the file remained encrypted.

I ran into this error a couple of times when trying to launch debug for an Android application in Eclipse. In all the cases I completely forgot what I had to do to fix this and this thread has conssitenly led me towards the solution.

However, not all the way. For some reason, doing a project Clean did not remove the jar file for one of the libraries in the workspace and that was causing an issue in another project that referenced the library.

In any case, for me the solution has been to simply search the workspace directory tree for *.jar, and remove the Jars for any of the projects that are about to be built (i.e. keep any 3rd party Jars for which no source code would be compiled.) So far so good..

Cheers!

One of the many cool things about WCF is that it abstracts network communication into the lower layers of the framework and leaves us developers to deal with the actual data for our applications instead of the nitty gritty of connection handling and data casting.

Operation Contracts can define parameter types explicitly and that works as expected. But what's super neat is that a service method can define a parameter of a generic type (i.e. object) and the service can still auto-magically figure out the underlying type and cast the object appropriately as long as the ServiveKnownType attribute of the service contract is properly specified...

Well.. almost.

Recently, I was working with an Android client that interfaced with a WCF service. I used JSON to encode and transfer that data. Everything was great, until I called one of my service methods that had a generic parameter:

[OperationContract]
string DoSomeStuff(int id, object inputObject);

I should mention that I already had a .Net client (that DID NOT use JSON) for this service and everything worked great. However, calling this method from Java resulted in the following exception:

I have recently had the pleasure of diving head first into some Android development. Putting asing my feelings about Java, and unnecessary nomenclature obfuscation of well-known, long pre-existing paradigms (e.g. Intent vs Message, Activity vs Window/Dialog), I have been quite impressed..  

However, the security model gets annoying and seemingly really really limits the scope of applications and services that could be provided by 3rd party developers. There are newish paradigms like Device Administration Application, but the support and the feature set still leaves a lot to be desired.

Overall, my sense is that Benjamin Franklin would not approve of the Android security model and I kind of agree.

"They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety."

Cheers!

A little while ago Mint.com changed their export file format, which broke ccQuickMint - an application that converts Mint transactions to Quickbooks format, so they can be imported. 

I've updated the app to prevent the error below.

New version is available here. More information on how to use ccQuickMint is in this post.

Let me know how it works out or if there are other issues.

Cheers!

I was recently re-organizing my music collection and.. Well, I suppose "re-organizing" implies a level of initial organization that my collection has never enjoyed. So..

I was recently organizing my music collection and noticed that it involved a number of repetitive tasks pertaining to folder management. Specifically, I wanted to 

• get rid of folders that only had one file in them
• get rid of all empty folders
• Do some mp3 tag reading and make some decisions based on that

The goal is not really the point, but the general task I wanted to completed was enumerate every folder in some base folder, test a condition (e.g. Is directory Empty), and based on the result of the condition execute some action (e.g. delete the directory). 

Typically I'd write a script for this (vbscript or maybe batch) but I was recently doing some directory enumeration in C#, so I figured I'd reuse that code. 

Sadly, it was just brought to my attention that the site has been filtering out some legitimate comments as Spam. Very sorry about that, I have disabled spam filtering and will keep it just captcha for now.

In light of the filtered posts, I'll be posting an update to ccQuickMint very soon to accomodate the new file format.. Hopefully, just in time to do the year-end books.

Cheers!

Recently I was messing around with some webcam image acquisition and thought I'd share some code that I wrote for this purpose. The code below implements a class that can capture a single image from a webcam and return it as an array of bytes or simply store it in a file - no dialogs, no frills. 

First, there are several ways to go about webcam image acquisition with C# in Windows. There is Windows Image Acquisition library (WIA), Direct X interfaces, and third-party libraries like EasyWebCam Library 

Finally, there is the option of using interop to call into avicap32.dll. This is the method I went with, because it is lightweight and works with more cameras than WIA (in my trials anyway). 

The avicap32 API is pretty goofy, however, and works as follows:

I recently discovered a little bug in Kwapture, a little screen cap app I wrote. The issue was that when the user selected a small area, it would automatically get resized to a larger size.

Yes. Another WTF file entry. Well.. sort of..

The way Kwapture works, is that after you select an area to capture, it creates another dialog over that area that uses the underlying image as a background and allows the user to draw/write on top of that. The dialog is dynamically sized using the size of the rectangle selected by user.

The dialog that is created is essentially blank:
AutoScaleMode = None
ControlBox = Flase
ShowIcon = False
ShowInTaskBar = False

However, I realized that when the user selection was below a certain size, it would always get resized to the same larger size... Approximately like this - the smallest size you can shrink Notepad into: