Archive for the ‘Visual Studio’ Category

Inconsistent GUI programming of Visual Studio

    The Visual C++ 6.0 has existed for long time compared to unfortunate Visual Studio .NET 2003. The 2000 versin changed a lot in respect to GUI and it introduced .NET. The 2005 version was somewhat stabilized, and 2008 version looks to continue its tendency.

    With this Visual Studio products, there are some problems. They are :

  1. GUI was changed too much.
  2. Approach in respect to GUI programming is not consistent

    The GUI was changed too much. Visual C++ 6.0 provided easy approach for dynamic data exchange on its class view dialog box. You could select what messages would be handled by a selected class on the same dialog box.

    2003 version was changed a lot, so adoption rate was not good.
From 2005 version, things were streamlined well. However there are still lots of difference.

    For example, does the 2005/2008 version provide a way to set up window message handler? It is pretty difficult to find it.
But here it is.

Inconsistent_VC

After selecting a class, open its property pane. Then you can find where you can set up message handlers.

    Second, the way to add / modify event handler is different.
At least adding one is same.

EventHandler

    However, to browse existing event handler, you cannot double click a button. As far as I remember, Visual C++ 6.0 allowed it, existing event handler was opened.
Also, most importantly, the way to add message handler and event handler are very different. Why classes like dialog is in resource file to be represented visually and thus provides a way to add event handler by clicking, while those for views are not visually represented in resource file and its message handler can’t be added/modified by clicking?
This is very important inconsistency.

    So, for .NET, MS introduced “form” programming, whcih is property programming. With property programming paradigm, setting properties, or class member variable, is enough to set up things, e.g. fonts, etc. Also, view classes in .NET framework are also visualized in its resource file.
This was originally pushed by Borland. As far as I know, MS hired a Borland programmer to implement “form programming” paradigm for Visual Studio.

    Because this difference, it is confusing to prepare code with VS from time to time. However, thanks to .NET framework, programming for Windows feels similar to that for Mac nowadays. For last two years, I tried .NET programming. It was quite easy to learn it and found out that .NET classes and its approach is very similar to that of Cocoa/Objective-C.
So, I decided that I could easily start writing in .NET. So, I kept focusing on MFC.

    By the way, I couldn’t decide whether to post this to my Hot Potato blog or here, but this is more about development. So I decided to post it here.

Debugging a release build with the Visual C++ 2005

Sometimes debug build doesn’t crash but release build crashes. This usually happens when memory area which is not valid is accessed. Debug build usually has some fence around allocated memory area.

However, recently I suffered somewhat different case. In this case, you need to debug a release build.
Yeah.. It is quite easy. Just enable debug information for a release build. However, in my recent case, doing so didn’t reveal symbols or display correct values for variables.
At first, I thought a stack is corrupted. However, I found out that optimization option did affect the symptom.

So, disabling optimization was the solution to check content of variables.
coptimization

The cause of the crash was due to #pragma pack.
In one of its header file, #pragma pack (push, 1) is used, and at the end of the file #pragma pack(pop, 1).
It should have been #pragma pack(pop) to reverting.

So, in a influenced class implementation file, it used correct alignment, while in other source file which included a troubled header file, the alignment of this class is not interpreted as it should have been.
So, it caused a vtable evasion in a source file which includes the troubled header file. Therefore, it crashed when it called one of the method of the influenced class.

It is strange that this didn’t cause problem with a debug build. There is not explanation on the MSDN site whether this is disabled in debug build or not.

%d bloggers like this: