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

Grrrr

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.

Ugh.

So, I dig. A lot. I code. A lot. Nothing seems to help. Then I run across this little article: http://www.codeguru.com/forum/showpost.php?p=1571025&postcount=14

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

Hey!

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 ...

Nope.

OK, under C/C++ then

Nope.

....

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.