vc++


18
May 06

Alpha Blended Toolbar Images on XP+

I wanted the next release of PN to have some nicer icons, as the roughness of the toolbar images was jarring. The best way to get good looking smooth images on a toolbar is to use images with an alpha channel. Unfortunately this is only supported in XP and up, but I think it’s a worthwhile change for users on those platforms.

PN Alpha Blended Toolbar

It took me a long time to find a good way to produce bitmaps in the correct format for windows to handle the alpha. The bitmaps must be stored as 32-bit where 24 bits are used for the colours and 8 bits for the alpha channel. Very few tools seem to support this format. So here are two methods you can use:

Believe it or not, use MS Paint

First create your image using a good transparency aware design tool like Photoshop or The Gimp. Now save your image as a PNG with transparency. Next, load the PNG into MS Paint and immediately save the file as a bitmap. If you look at the bitmap in a normal editor now you will see a black background but this is caused by the alpha channel. MS Paint claims it’s only a 24-bit bitmap but it truly is 32-bit with alpha.

Alternatively, use a handy tool!

I spent a long time looking for utilities to do this and was beginning to think I’d have to do it myself when I stumbled across AlphaConv by Adam Najmanowicz. This useful tool will transform between .png, .tga and .bmp formats keeping the alpha channel.

Nice Icons

You may recognise the glyphs in the above toolbar as coming from the Silk icon set from famfamfam.com. This excellent set is free, and my thanks to the designer for making PN a prettier piece of software!

At the moment the PN development builds only support the toolbars properly on XP. I have yet to work out the best way to continue using older icons for older OS versions.


17
Feb 06

Middle Click Close in Visual Studio

A long time ago I added middle-click to close tabs in PN – a popular choice. At the time I moaned about this not being supported in Visual Studio. When the VS 2005 development betas were out, myself and many others requested this feature.

Microsoft’s response was that this was not a standard windows UI feature and therefore they would not be implementing it. Leaving aside the fact that Visual Studio often invents UI features of its own and also that IE 7 supports middle-click closing for tabs, this was a really poor response from Microsoft given that it would have been so easy to add this feature and make people happy!

Fortunately for all us Visual Studio users, Jonathan Payne wrote VSTabs, a sort of mini WndTabs for VS 2003 and 2005. This gives you tabs that group paired files (like .cpp and .h) and also gives you middle-click close – wahey! Finally, the source is available so you can tweak to get them working as you like.

Current downsides are that the add-in breaks the right-click context menu, and doesn’t show the modified status of the file (no * for modified files). Oh, and some that I work with hate the colours – who’d have thought?! This should all be relatively easy to fix though.


18
Jan 06

Build PN with Free Tools

Microsoft Visual C++ Express is available for free, but doesn’t come with an up-to-date version of ATL meaning that using it to build PN (which depends on WTL/ATL) has been impossible until very recently.

Baryon Lee has posted an article on CodeProject explaining how to get the latest WTL working with Visual C++ Express. This means you can now build PN2 using all free tools!

Visual C++ Express

CodeProject Article


27
Oct 05

Programming Fonts

Still think Courier New is the best (only?) suitable font for programming? You might just be missing a trick, there are a whole bunch of freely available fonts out there designed specifically with programming in mind.

Rather than write up the whole lot myself, I’ll point you at an excellent write-up of several of the most popular by Jeff Atwood.

I’m currently using Dina (a derivative of Proggy ) for my development, and find it very clear and easy to read. I also often use Lucida Console and Typewriter as scalable alternatives.


17
Oct 05

Exposing Functions to Embedded Python

So far, instead of exposing functions to Python, we have (the reverse I guess) embedded the Python interpreter in our process using Boost::Python. So, running Python from within our process is all good and well but we want the Python code to interact with our C++ code as well.

We’ll add to the previous example:

const char* greet()
{
	return "Hello World from C++";
}

BOOST_PYTHON_MODULE(embed_test)
{
	def("greet", greet);
}

Here we have defined a python module embed_test which we will now expose to our embedded Python interpreter. The module has one function, “greet” in the Python module calls the C++ greet function.

Now we add to the main function:

if(PyImport_AppendInittab("embed_test", initembed_test) == -1)
		throw std::runtime_error("Failed to add test module to builtins");

The initembed_test reference is the function name generated by the BOOST_PYTHON_MODULE macro. Once we have made Python aware of this built-in module, we can modify the python code we run in the example to print out the result of the greet function:

handle<> ignored((PyRun_String(
	"import embed_test\n"
	"print embed_test.greet()"

	, Py_file_input
	, main_namespace.ptr()
	, main_namespace.ptr())
));

The techniques used here are all based around the basic functionality available in the Python C API. However, the Boost::Python library does make it easier to expose your own code to the Python interpreter. Next we’ll look at exposing classes and then move on to the use of SWIG.


12
Oct 05

Hello World from Boost::Python

I just created a “Hello World” application in Boost::Python. I’m comparing the Boost and SWIG options for embedding Python and making PN code available to it so this is the first step for the Boost implementation.

Here’s the code:

#include <boost /python.hpp>

int main(int argc, char* argv[])
{
  Py_Initialize();

  object main_module((
    handle<>(borrowed(PyImport_AddModule("__main__")))
  ));

  object main_namespace = main_module.attr("__dict__");

  // Run some python!

  handle<> ignored((PyRun_String(

    "print \"Hello World from Python!\""

    , Py_file_input
    , main_namespace.ptr()
    , main_namespace.ptr())
  ));

  Py_Finalize();

  return 0;
}

Not very much code at all to get going! boost_python.dll (required to use Boost::Python) comes in at 180kb. The initial test app (as coded above) in Release configuration takes 40kb.

The differences between this and the SWIG embedding version will be minimal, boost doesn’t hide much of the embedding code for you. The real differences will be in creating wrappers for functions and classes. With boost I have to write wrappers, SWIG will automatically generate them. The interesting bit will be the size of the code created.


17
Dec 04

USES_CONVERSION – a cautionary tale

Yesterday my team at work finally got to the bottom of a crash in a product that was very difficult to track down. We had a thread running in a product that was now being required to run for much longer, and was eventually producing a stack overflow exception (which we’d not seen before). As is the nature of such an exception, it often came from different points in the thread depending on the work that was being done.

To cut a long and painful bug-tracking story short, it turns out that the memory allocation performed by the macros related to ATL’s USES_CONVERSION text-encoding conversion system is performed by the alloca function. This function allocates memory on the stack (an AHA! moment) and what’s more this memory does not obey the standard stack-scoping rules:

void fn()
{
    while(true)
    {
        {
            USES_CONVERSION;
            DoSomething(A2W("SomeString"));
        }
    }
}

Some might expect the above code to release the memory allocated by A2W each time around the loop – wrong! The memory allocated by alloca does not get released until the current function is left, so to fix this problem you have to write code like this:

void fn2()
{
    USES_CONVERSION;
    DoSomething(A2W("SomeString"));
}

void fn()
{
    while(true)
    {
        fn2();
    }
}

This code was part of a Visual C++ 6 project, and apparently in VC7 there are alternative better macros that use proper stack scoping for allocation – good! We found the first signs of the true location of the bug by converting the project to VC7 and running it there – where the stack trace exception always seemed to occur on the line where the A2W macro was being used. I think this was probably just good fortune rather than VC7 being exceptionally helpful (no pun intended!).

So: Don’t use USES_CONVERSION and friends in thread functions or tight loops – you have been warned!