Disable Design-Time Support in Visual Studio

I recently wrote a class in c# that inherits from System.Diagnostics.Process. This class abstracts a shelling-to-disk process that I need to do. Something like this:

public class MyShellTask : Process
{
...
}

One thing that bugged me to no end is that, in Visual Studio, when you double click the file in the Solution Explorer, it considered it "designable" even though there was no designer. So that means I got a empty page every time, telling me that it was not designable, with a link to "View Code". Well, "View Code" is what I wanted, not "View Designer", when I double-clicked!

So after getting very frustrated, I did the natural thing.. I googled looking for an answer. I had a notion that I could control this behaviour through Attribute tags on the class if only I knew the right one. Having made designable components before I was familiar with the attributes used for that. I tried fiddling about with Intellisense, Googling, all to no avail.. Nothing worked! Nothing showed up in my Google searches! Good God! What to do now?

Fiddle some more... until finally I found the right attribute:

[System.ComponentModel.DesignerCategory("")]
public class MyShellTask : Process
{
...
}

Note that you must call this with an empty string (don't believe the intellisense comment, an empty constructor call will NOT do the same as calling the constructor with an empty string.) This sets it to a non-category that it doesn't know how to deal with, and so doesn't offer designer support to you!


This also helps custom installer class for use with your Visual Studio Setup projects, which exhibit the same annoying VS UI problems... ie:

/// 

/// Custom Installer actions for this project.
/// 
[RunInstaller(true)]
[System.ComponentModel.DesignerCategory("")]
public partial class MyInstaller : Installer
{
   ...
}

Hope that helps someone! Now there will be at least ONE hit if someone googles up "disable design-time support" or "disable designer support" like I did!

Java, NetBeans, and Templates, OH MY!

Well, having recently sparked an interest in moving towards a Open Source, cross platform, but still as cool as c#/VS2005 development platform, I of course landed in the middle of NetBeans 5.5 and Java.

Having never programmed in Java before, but understanding it's really similar to c# (or I should say c# is really similar to Java), I immediately started fiddling about as if I were writing c# code. So, it's easy to get past typing uppercase String, not lowercase, and also not too hard to grok "extends" instead of ":" for inheritance. The one-class-per-file thing, well, I guess it will just make me a more organized programmer, however annoying it is. But the things that really erked me was properties.

In c# I can do this:

...
private string _name;

public string Name
{
  get
  {
      return this._name;
  }
  set
  {
      this._name = value;
  }
}
...

but in Java, that looks like:

...
private String _name;

public String getName()
{
  return this._name;
}

public void setName(string value)
{
  this._name = value;
}
...

Wow. Extremely obnoxious. Furthermore, I have finally gotten myself broken in with the VS2005 IDE to type "prop" + TAB to get a nice template for my properties. Well, since there is no such thing in Java, this macro also does not exist. So, I proceeded to make a NetBeans code template called "prop", which functions the same way the VS2005 "prop" code snippet does.

So, for all you c# coders who are venturing into the foreign lands of Java, here's a little tutorial on how to add this little cultural comfort into NetBeans.


Property Code Template Installation Instructions:

1. Select menu item "Tools->Options".
2. Click on "Editor" sidebar button.
3. Click on "Code Templates" tab.
4. Select "Java" from languages combo-box.
5. Click "New", and then enter "prop" as the Abbreviation in the dialog.
6. Click "Ok".
7. Make sure "prop" is the selected template, and in the text box below the list, enter these lines:

  private ${int} ${_prop};

  public ${int} get${Property}()
  {
      return this.${_prop};
  }

  public void set${Property}(${int} value)
  {
          this.${_prop} = value;
  }

8. Select "Tab" from "Expand On" combo box.
9. Click "OK".


Now you've got it installed.. Feel free to go to the code and give it a whirl! Have a look at the other macros in the list to see what's built in, and once you figure out the syntax of the template notation, make your own templates!

Code Snippet: ListEnum

Some times you want to list an Enum and see what it's actual numeric values are.. Well sometimes I do anyway, and when I do, I use:

private static void ListEnum(Type _enum)
{            
    Console.WriteLine("enum " + _enum.Name);
    Console.WriteLine("{"); 
    string[] foo = Enum.GetNames(_enum);
    Array bar = Enum.GetValues(_enum);
    for(int i =0;i<foo.Length; i++)
    {
        Console.WriteLine(
            foo[i] + " = " + 
            ((int)bar.GetValue(i)).ToString() + ",");
    }
    Console.WriteLine("}");
}

Enjoy!

Code Snippet: SQL FileExists

Today in the course of my work, I came across a situation where some of the files referred to in our SQL database were not actually on disk where we thought they were. This was a largeish database of files (over 10,000), and we thought there might be as many as 1600 files missing, so I didn't want to go through each one manually to find the missing files. That led me to this solution: creating a function in SQL to check if the files exist.

The first method I tried for doing this used an undocumented system stored procedure in MSSQL, called xp_fileexist. The code for that looks like this:

-- using MSSQL built-in stored proc xp_fileexist

CREATE FUNCTION FileExists(@File varchar(255)) RETURNS BIT AS
BEGIN
DECLARE @i int
EXEC master..xp_fileexist @File, @i out
RETURN @i
END

It's a pretty simple wrapper around the stored-procedure. Implimenting it as a function provides a more versatile tool for querying howver, as shown in this example usage:

--- usage

SELECT *
FROM tbl_FileInformation
WHERE (dbo.FileExists(PathAndFile) = 'True')

Unfortunately, this didn't do the trick for us at that time. MS SQL server apparently cannot, under any circumstances, see mapped drives. All of our data was on a drive called 'P:', which was mapped to a network accessible storage device, that our whole company uses. Not to be discouraged, I thought to myself "Well, perhaps it's just a limitation of the xp_cmdshell options, not SQL server as a whole. May there's another way of finding this out...".

So that led me to write this next function, which uses Scripting.FileSystemObject via the OLE Automation Options. First things first, I needed to run the following commands to enable OLE Automation, to make it possible:

-- configuring for use of scripting object

sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
sp_configure 'Ole Automation Procedures', 1;
GO
RECONFIGURE;
GO

That's the SQL native way, the other option is to use Surface Area Configuartion and enable it via the check-box. Once that was out of the way, I could try out my function...

-- Using the scripting object

CREATE FUNCTION FileExists(@File varchar(255)) RETURNS BIT AS
BEGIN
declare @objFSys int
declare @i int

exec sp_OACreate 'Scripting.FileSystemObject', @objFSys out
exec sp_OAMethod @objFSys, 'FileExists', @i out, @File
exec sp_OADestroy @objFSys

return @i
END

But... unfortunately, this gave the same results.

So, the moral of the story? Kids, MS SQL just can't see mapped drives. Give it up now!

If you're lucky enough to have all your data on a drive that's local to the SQL server, and find yourself needing to know if a file you've got referenced still exists, then give these methods a try!

YMMV.

vista sidebar on XP 2

Well, I was very excited about getting the Vista sidebar to work on XP, until I started playing with the Gadgets.

It turns out the patched version of the Sidebar executable is from a early beta version of Vista. The unfortunate point about that, is that the Gadgets that work with the XP version are vastly different than the Gadgets for the released version of Vista. That means all the gadgets that you can download don't work with the XP version. It also means that all the information about developing Gadgets for the Sidebar is relevant to the Vista version, not the XP version.

To detail some of the differences:

In the early release, Gadgets are not even called Gadgets, they are called Parts. Parts and Gadgets are very similar, in that they both are a zip file containing what amounts to a mini-webpage which is loaded and interpreted by the Sidebar.

In the XP version, a Part is a zip file with the extension changed to ".part", in Vista the extension is ".gadget". In XP, the directory where those files are stored is %userdir%\Parts, in Vista it's %userdir%\AppData\Local\Microsoft\Windows Sidebar\Gadgets.

Parts require a Manifest.XML file, while Gadgets require a Gadget.xml file. The contents of those files, while containing nearly the same data, use different names for all the tags, making them not compatible.

Beyond that there are a number of other subtle differences, as well as a generally limited set of functionality in the XP version, as compared to the released Vista version.

So, that poses a question? Considering the large amount of people who aren't interested in upgrading to Vista, due to performance or cost issues, or just not wanting to uproot and start again, is it worth my time to develop for this patched version of the Vista sidebar? Is there a substantial user-base that would benefit from having more cool Gadgets, I mean Parts, to run in their XP Patched Vista Beta Sidebar?

Perhaps that's a bigger niche than one would initially imagine.

Well, until I have an install of Vista to run the release version, providing a development environment for generating good Gadgets, I may just amuse myself with by playing with potentially pointless Parts.

vista sidebar on XP

So, I was perusing codeproject.com and I came across their current Vista Gadgets Competition. Well, this sparked my interest, not because I am interested in prizes, but because until now, I hadn't heard of Gadgets, or the Vista Sidebar, or really much about Vista at all.

The reason for this is that, I, being slightly conservative regarding willy-nilly-ly installing new OSes as soon as they are available, choose to upgrade by force, only when absolutely unable to do otherwise. That means, I'm running Windows XP. So what is a developer to do now that his interest is piqued? Install Vista so I can play with Gadgets and the mystical sidebar? No! I, of course, choose to google up a nice patched version of sidebar.exe that can run on XP!

Woohoo! I'm excited to say, that this not only works, but works without a hitch. I was able to install and run the Vista Sidebar on XP in mere moments. And that also means I can fiddle with widgets, oops I mean Gadgets. ;)

See my next few posts for more information about Gadgets... But before you do, download the XP version of Windows Sidebar so you can join in the fun too!

Links and knowledge courtesy of MSTN and their article about this, which I found out about by reading this blog post on My Digital Life.

self-stabilization and dijkstra

So, upon creating this blog, the first thing I felt obliged to do was to show it off to my roommate and idea-raquetball partner Max Strini (his blog).

His first reaction was "that's sort of militant". Probably in reference to the term "vanguard" which is generally used to refer to an aggressive front-line force of some sort. I concurred, but still felt I had made a good choice.

Max then immediately hijacked my computer, launched a new firefox window, and began googling up and mumbling unrecognizable names. Dijkstra, The Humble Programmer, and How do we tell truths that might hurt? suddenly appeared and were read out-loud to me by my excited friend and companion.

He was right!

How fascinating was Dijkstra? Fascinating enough that, even though I had worked 13 hours straight, eaten almost nothing all day, and have a beautiful wife and 1.5 week old child waiting for me, I felt compelled to click about and read more.

I came across self-stabilization and it occurred to me, that the impetus behind creating this blog is a form of self-stabilization. In one sense, it's my own self-stabilization, in which I will divest and store the processes by which I created order from confusion in my daily life, providing a resource which I could use to reduce the amount of overhead needed to repeat these feats. But secondly, it is self-stabilization as and unconscious process of the online tech-blogging community. I rely heavily on the blogged accounts of problem-solving that others so diligently post for all the world to see. The first thing I do when I encounter a new and challenging problem is to check and see who has dealt with this problem before, and what did they do? What solutions are already available in the vast spray of information available from public search engines? Most of the valuable information I find is not the official formal documentation provided by the institutions that created the technologies, detailing every facet of the system with excrutiating thoroughness, but rather the anecdotal, code-snippetted, hyper-linked, semi-stable accounts posted by my unknown peers battling the same dragons. From these bits, I learn how to use the vast and morbid technology describing in the aforementioned chronicles of specificata.

So this blog, is self-stabilization for the blogging culture in which I so heavily rely. If there were no blogs to read, how would I solve many of those problems? Isn't it my duty to give back to that system? Shouldn't I also serve to stabilize this information vortex and let other reap from my trouble-shooting bounty?

Indeed. I should.

a startlingly quick birth

Creating this blog today was extremely simple. I am duely impressed.