Friday, September 18, 2009

OK, if this actually works, this is pretty awesome

Theme generator. Testing now. However it's pretty damn sweet looking if it actually works.

Wow. Works like a charm (Visual Studio 2008). Very nice find.

Friday, September 11, 2009

The Registry and 64 bit OSes.

So, today starts the first real foray for me into the land of 64 bit OSes. This should prove interesting.

Needless to say, it's been interesting so far. Here's a tale of my first conundrum.

One of the tools we have in house reads the 3D Studio Max registry (locations on where to put custom scripts et al). So, in order to port this tool to an appropriate version of Max I need to be able to find out the value of "HKEY_LOCAL_MACHINE\\SOFTWARE\\Autodesk\\3dsMax\\11.0\\MAX-1:409\\Installdir".

So, I crack open Regedit go to this registry key and change it, intending to break the tool. I run the tool and voila, the tool behaves as normal (read: it doesn't break).

Wait, what?

I double check to ensure that the registry key has been changed (it now reads N:\NoDir), this time exit out of regedit and try again.

Same results. The tool works like before (read: as if the registry entry hasn't been changed).

OK. This is nutty. Is there some kind of security privilege going on here? If so, I shouldn't be able to change it. Aggrivation! But no, that's not the case.

One Google search later I find the following web page:

More to the point, we have the following bit of text
Note The registry in 64-bit versions of Windows XP, Windows Server 2003, and Windows Vista is divided into 32-bit and 64-bit keys. Many of the 32-bit keys have the same names as their 64-bit counterparts, and vice versa. The default 64-bit version of Registry Editor that is included with 64-bit versions of Windows XP, Windows Server 2003, and Windows Vista displays the 32-bit keys under the following node:

Oh my dear sweet zombie jesus. Are you kidding me?

No, apparently not. Wow. Just wow. So needless to say what I've been changing all along is the 64 bit app's version of the registry. Un-be-lieveable.

Oh well, something to be aware of in the future, I guess.

Sunday, August 09, 2009

Mixing CLR and non-clr code

So, I'm trying to get back into playing around with my "Wanton" codebase (some editor stuffs I want to do) and I ran into a problem that I've experienced in the past before, but didn't get an adequate solution for in the past.

So, in some libraries I'm creating I needed to mix in some engine based code (my Wanton codebase) into the editor. It's fairly native C/C++ code. As soon as I included it, I got the following error:

Very odd, to say the least. Here's how I was invoking the headers:

I've had issues in the past where the 'using' statement caused me grief, so I figured I'd move my header declarartions above them, a la:

Lo and behold, that did it (compiles and runs fine).

Digging around the net brought up this little gem:

The short and sweet of it?
If you add using namespace System::Windows::Forms; before including Visual C++ will be confused because IDataObject is also a managed interface in System::Windows::Forms. You can relegate windows.h declarations to a lower namespace:
inamespace Win32{#include };and reference windows.h symbols with the Win32 namespace prefix, or move all using statements from .h to .cpp and add a namespace prefix when an ambiguous symbol is used.

Just something I thought I would share with the populace at large.

Tuesday, August 04, 2009

Playing with emacs

I've started playing around with emacs at work and I thought I would keep a list of commonly used commands and plug-ins on my blog.

First off, some plugins that I'm using.

Color-themes is great and allows me a fair bit of selection when it comes to colorizing my editor. ( )

Also, I'm using tabbar.el to give me tab functionality I'd be lost without my tabs. ( )

As for commands, I'll sort them by category.

 C-x C-f                Open a file.
 C-x C-s                Save the file in the current buffer.
 C-x s                  Save all buffers.

 C-_                    Undo (that's an underscore).
 M-del                  Delete last word.
 C-x del                Delete to beginning of sentence.
 C-t                    Transpose two letters
 M-t                    Transpose two words

 M-d                    Kill a word.
 M-k                    Kill to end of sentence.
 M-z char               Kill up to next occurrence of char.

 C-s                    Incremental search forward.
 C-s C-s                Cancel forward search.
 C-r                    Incremental search backward.
 C-x k                  Kill a specific buffer by name (RET by default kills the current buffer.
 C-x C-q                Flag a buffer as read-only.
 C-x C-b                List buffers

Tuesday, July 21, 2009


Code and layout appears to be functioning correctly again. More code updates coming soon.

Tuesday, July 07, 2009

C#, MSTest and getting it to work like unittest++

So, I just spent a good bit of this afternoon setting up a C# project that I've been working on to work like UnitTest++.  Let me explain ...

UnitTest++ allows you to add a post-build step that actually runs your code, that's under unit testing after each compilation.  This is really usefull as it allows you to find bugs at compile time (not run-time).

This is considerably harder to do with MSTest (the built in unit test framework in .NET/Dev Studio).  However, your humble servant has gone through the work and figured out the process.

Assume that you have the following:
  1. an assembly, containing your project, called Foo
  2. your Unit Test assembly, called FooTesting
Inside of the Foo project, you will need a post build step that looks like this:
cd $(SolutionDir)
REM Do the following so we don't have a polluted TestResults folder
rmdir /S/Q TestResults
mkdir TestResults
"$(DevEnvDir)mstest.exe"  /testcontainer:$(SolutionDir)FooTesting\bin\$(ConfigurationName)\FooTesting.dll

This took freakin' forever to work out.  However it still doesn't give me the nice formatting of UnitTest++ that allows me to go directly to the line number of the failed test.  It's really a shame there isn't a way for the console spew to be formatted in a way that DevStudio can eat.

Monday, June 29, 2009

Screen Capture tools - Greenshot

So far, this has been a really awesome little screen capture tool. That and it opens the captured image in it's own little image editor. Sweet.

Sunday, June 28, 2009


Google Pages is going away. So that's going to hose where I store my syntax highlighting. Now my blog is busted.

Code snippets are hosed. I'm trying to fix it, please be patient.

Tuesday, June 23, 2009

More Dev Studio fun time happiness

Wild times tonight.

So, I'm working on my editor again (because ... you know ... I don't need sleep) and I run into a very interesting situation.

I've created a new UserControl called RenderPanel. It derives from System::Windows::Forms::Panel. This is a new control. I'd like it to show up in the toolbox. It doesn't.

So, I say "What the heck" and add it into the form designer by hand. Compiles fine and I get my resultant render view.

Then I try to run Visual Studio's designer on it. Nuh-un. I get a plethora of issues from the designer, telling me that I can't open the form because my RenderView isn't defined.


So, I dig. A lot. I code. A lot. Nothing seems to help. Then I run across this little article:

Nah, it can't be that easy, can it? So, I go to the menu Tools->Options and then in the Windows Forms Designer, I enable the AutoToolboxPopulate field. I close the project, open the project and lo and behold, I have a new toolbox group called Sanity_20 Components (the editor is called Sanity ... I'm at Revision 2.0) and there to my complete shock is a little blue gear labeled 'RenderPanel'.

And I can add it to my form. And it works.

Completely unbelieveable. But who am I to argue?

Sunday, June 21, 2009

.NET 3.5, Windows Forms and DirectX


So, I got to do a little work on my at-home project this weekend (not lots, but a little). One of the things that I'm starting to play around with is Windows Forms in .NET. So I thought I'd do a little editor work, migrating from a pure Windows application into a .NET forms based app. Seems like a good idea, right?

Well, to a point it was. I got the form build, a simple layout setup and then I went to link in my existing libraries.

No go. When I tried to call a static initializer in my library, I got the following linker error:

1>Sanity_2.0.obj : error LNK2001: unresolved external symbol "public: static void __clrcall Wanton::Graphics::CViewportFactory::Init(void)" (?Init@CViewportFactory@Graphics@Wanton@@$$FSMXXZ)

__clrcall? That shouldn't be an issue. The library isn't a CLR library ... is it? A little investigation of my library indicates that it isn't. So. for fun I decided to explicity declare the method in question as __cdecl. Doing so (just adding __cdecl to the method signature) resulted in the following error:

4>Graphics.lib(ViewportFactory.obj) : fatal error LNK1313: ijw/native module detected; cannot link with pure modules

Well now. That certainly gives us a bit to chew on. Why does it think that the new form I've created is a *pure* clr app? I just asked it to create a Windows Form app, using .NET 3.5. In Visual Studio 2008.

OK, so I'll just set the clr type to non pure. Simple enough. Let's see, where's that setting ... under linker probably ...


OK, under C/C++ then



Wait, where the Fuzzy Hell is it defined? Looking in the C/C++ Command line view, the value is shows up ( /clr:pure, for those wondering ).

So, I start at the top (normally I start at the bottom of lists ... things tend to be at the bottom of piles, but this time, I had a gut feeling) and look in the 'General' section.

Lo and Behold, there it is, under 'Common Language Runtime Support'.

I *suppose* it makes sense, but you know, that seems like an odd place for it to live.

Anyway, linking with just a simple CLR option resolves the issue and all is once again cool in the world.

Wednesday, May 20, 2009

Usefull tools - NiftyPerforce

Tired of Perforce's woefully awful SCC plugin for Dev Studio. Try NiftyPerforce. It's fairly lightweight and does what it advertises ... Allowing you to check out files in Perforce.

I'd used this in the past, but had forgotten about the link.

Monday, May 18, 2009

So, it's been a while since I posted anything

The new job has been keeping me plenty busy. However I think it's time I started some home coding projects. Being a guy that likes to build world editors in his spare time (because, you know, I have so much of it), I also thought I'd get back into a bit more of a rendering focus. It's been a while, I've forgotten a great deal, so this should make for some interesting reading.

One of the first things that I'm working on is a simple Rendering subsytem that I can plug into my apps. Nothing fancy, just something to get me familiar with D3D 9 and OpenGL, as well as get me a framework for learning shader/fragment coding. More on that as I develop it.

However, something that I think I will post about, especially with D3D programming, is mentioning the DirectX control panel. Specifically the ability to enable using the Debug version of the DirectX DLL's and increasing the verbosity of the debug information that is spewed out. This is really helpful, as it helped me track down a stupid memory leak that I had in my code (my underlying system wasn't releasing a D3DDevice that I thought it was). I'll put up a screen shot of the DirectX control panel shortly.

Anyway, I'm back at this part time (summer fun, when it rains and since there's nothing good on TV during the summer). I'll keep everyone updated as the progress continues.