wxWidgets strange modal dialog crashes

Recently, I wrote one program with Code::Blocks version 12.11 and wxWidgets version 2.8.12. Logic of the program required invoking modal form (inherited from wxDialog, created with wxSmith). Once, during debugging, I found that the program continiously crashed after showing this modal form. The crashes usually occured either just after constructing of this dialog instance, or after a few seconds of this dialog being active. I revised all places in the source code which were somehow related with construction of this dialog, and with passing parameters of its construction and initialization. But I was unable to find any error(s) in the source code itself. At last, I got a flash of inspiration: I actually created this dialog from secondary ("worker") thread. After reimplementing this fucntion as running in the main thread (via combination of auxiliary window, SendMessageW with WM_USER and pointer to the structure with function parameters packed into WPARAM message argument, and MSWWindowProc functions), all crashes stopped. So the error was not in some line of the source code itself, but in the wrong architecture and lack of attention to this fact. The accompanying factor was that in previous version of the program, I used simple standard wxMessageBox function in that place. wxMessageBox apparently invokes WINAPI MessageBoxW function, and this works fine from secondary thread. But when I changed this to invoking of custom wxDialog form, in order to gain additional functionality, crashes began, and it took some time for me to understand where the problem resides.

Radio-controlled all-wheel drive Robot based partly on Arduino modules

Today I have attended Chaos Construction 2012 (in Russian) - computers and computer graphics, 8-bit music and demo scene annual festival. For me, one of the most interesting things there was presentation of all-wheel drive radio-controlled robot made partly based on modules from Arduino open-source electronics prototyping platform.

Robo-hobby blog (in Russian) is the official current webpage of these guys (those who are working on a robot, not those who develop Arduino). If you will ever want to learn anything about relatively easy-to-reproduce hand-made radio-controlled robots based on open-source hardware & software components, I would advice to check this blog. Authors share their experience about working on such a project. This is really interesting, even for me, professional electronics developer. I've already added RSS feed of their blog into my feed reader.

Broken WM_DROPFILES (Drag-and-Drop) functionality in Windows 7

Yesterday I spent at least one hour in finding and fixing cause of error due to which in one of my applications Drag-and-Drop functionality did not work in Windows 7 OSes, as was thankfully reported by one user. The reason traced to be that Microsoft decided to disallow applications to receive certain types of messages which are related with inter-process communication. This was done to enhance system security, of course. WM_DROPFILES is one of messages which are now not working by default. Now you need to explicitly tell OS that you want to receive and process this message, via calling appropriate API function: solution for problem with WM_DROPFILES in Windows 7. It is not difficult to call one more function during program initialization, but I'm really tired of various problems which arise from incompatibility between different Windows and Office versions. In this aspect, development for microcontrollers appeals to me much more, since there you can control everything, and tested procedures will not unexpectedly stop working because of some changes in underlying OS logic. I'm speaking here about MCU hardware+software projects where OS is still not necessary, (i.e., not high-performance high-cost complex monsters) and so you have some confidence in all parts of the system.

Bugs in Windows Application Development

Today I at last have found time to fix some long-lasted bugs in one of my programs. Some of these bugs have been annoying users for about one year. They inconspicuously appeared after some phase of editing of source code. During fixing, I found two other previously completely overlooked bugs. They are not critical in nature, but annoying. It seems that this process (of finding and fixing bugs) can last forever. Development for Windows OS, comparing to development for microcontrollers, allows you to employ many ready-to-use system (as well as third-party) libraries, thus freeing you from the task of implementing service code for yourself, but at the same time, bugs and inconsistencies in system and third-party libraries can force you to spend much time in efforts to figure out why your application is not behaving as you expected, and I'm pretty tired of it. Conclusion is to test as big fraction of program's functionality as possible after every source code change.

Requiem to Phobos-Grunt

Yesterday, after about two months of orbiting the Earth on an intermediary, low-altitude elliptic orbit, Russian interplanetary station had finally fallen back to Earth, luckily into Pacific Ocean, not on some populated area.

Its short flight raised many questions to Roscosmos and even state's officials. Combined with several other satellite launch failures during last year, these questions are especially vital today. Maybe something in the area of top management of Roskosmos is really going wrong, maybe someone still think that world-class high-tech unique things can be developed for amount of money much less than world market suggests. Maybe something is broken at the bottom end of a technological chain, say poor quality control of production.

But here I want to point to only one side of the problem: nowadays, we have many strong rigorous math instruments that can be used to assess reliability and probability of failure for virtually any piece of hardware and software. Researches in the area of development of error-tolerant and reliable hardware and software systems allow one to employ many scientifically proved methods of designing and testing. This is XXI century, at last.

If scarce funding had really taken place, why main engineers and their bosses who were responsible for device subsystems could not just say: "Hey, guys, this is not enough to achieve the project's goals. You either will give us enough resources (time, money, people, equipment, etc.), or we will not sign for the work.". It seems that something is broken in the whole chain of decision making in Roskosmos. Sadly, but such conclusion came to mind after reading news.

Multi-Platform User Interface and GTK+

During last days, I have being working with one program which uses GTK+ 2.22 for its user interface. It works, but some things look as something foreign on Windows XP. In particular, this is strange folder opening dialog, lack of flashing of active modal window title when clicking with mouse on inactive parent window, and some other small things.
My conclusion is trivial: if you target only one platform, it is better to use GUI libraries created for this particular platform that fully complains with established de-facto standards.

CRM and Electronics/Software Development

In my spare time, I like to read one aviation forum. From there I learned that in the area of civil aviation there exists the whole concept about how members of aircraft flying crew should communicate and behave with each other, in order to achieve the best possible flying safety. I think, that something similar can be adopted to the field of electronics/software command development projects.

Crew Resource Management explanation on Wikipedia

CRM is all about preventing, detecting and correcting (even potential) human errors at the earliest possible stage, thus achieving the best flight results and safety. If you will regard flight of an aircraft as a multi-people PROJECT, you may naturally see that CRM principles can be applied also to electronics/software multi-people development PROJECTS. Unfortunately, I did not hear that even basics of such approach are studied in any university. This leads to very big role of project leader and his personal communication skills in overall success of any development project.
Such dependency could be mitigated, in my view, by working out and accepting concept of interpersonal communication in software/electronics development industry.

In particular, co-pilots are specially trained to correct the captain and to question potentially wrong decisions if it seems appropriate in a given situation. But in the area of electronics/software development, authoritarian project leader often has too much power and possibilities to send a project in totally wrong direction.

Forms (Windows) Interface Font

Delphi 7, while being very powerful IDE for Windows development, has some deviations from standards set by Microsoft. One of them is that by default, VCL forms use MS Sans Serif, 8pt font for all controls. This may look good on developer's machine, but on some target machines, this may look very bad because of lack of this font and substituting it for some another.
Standard behavior would be to use default OS Dialog font.
To overcome this, in each form's OnCreate event, invoke the following procedure:

procedure SetFormFontToSystemDefaultFont(Form: TForm);
var
  NonClientMetrics: TNonClientMetrics;
begin
  NonClientMetrics.cbSize := SizeOf(NonClientMetrics);
  SystemParametersInfo(SPI_GETNONCLIENTMETRICS, 0, @NonClientMetrics, 0);
  Form.Font.Handle := CreateFontIndirect(NonClientMetrics.lfMessageFont);
  if Form.Scaled then
  begin
    Form.Font.Height := NonClientMetrics.lfMessageFont.lfHeight;
  end;
end;

(Set ParentFont property to True for all controls on the Form for this to have effect).

Delphi Inactive Forms Behavior

In Delphi 7, there is one drawback in VCL, which appears as lack of any indication of which window is active when user clicks with mouse on inactive window. Standard behavior of compliant windows application is to flash the title bar of active modal window in that case, but Delphi forms do not respond to this action.

To remedy this, add the following code to your modal forms:

type
  TMyForm = class(TForm)
  ...
  protected
    procedure CreateParams(var Para: TCreateParams); override;
  ....
  end;
.... 
procedure TMyForm.CreateParams(var Para: TCreateParams);
begin
  inherited;
  Para.WndParent := GetActiveWindow;//to allow title flashing of child modal dialogs
end;

On Interface Design

For historical reasons (it was chosen by management of our firm to process salary payments), I have an account in one bank, with Internet banking option. The problem with its bank-client application, which should be used to access an account and to perform financial operations, is that it is evident that in some points it looks very unprofessional. The most prominent things are appearing of default Borland C++ Builder Icon as an Icon for Alt+Tab window and in the title bar of some windows, and inability of built-in browser window to resize accordingly when its parent window is expanded to the whole screen size. I believe that their application does not contain flaws that may compromise data transfer security, but if I would choose from different banks now, I would not stick with such a poorly written software. Their offices look as they should be - clean, modern, with polite staff, but it seems that their management do not realize that when I work with Internet banking, the face of the bank is actually the software.
After noticing that, I began to tend to double-check all my user interface look-and-feel features and logic, although neither of my programs deal with user's financial data.

Reusing of Classes in a New Project

I recently started a new small software project (program). Part of its functionality and GUI is common with another my relatively mature program. The latter consists of many classes written during 2 years. Although I tried to apply the best principles of Object-Oriented design and programming, such as incapsulation, the least possible coupling between classes and units, programming via interfaces and not implementations, etc., but when code of your classes is used in only one project, it is very easy to leave some project (or domain-) specific code in places where it should not be found. This leads to more tightly coupled code and reduce overall system maintainability. When you attempt to use such classes in another application, all such poorly written places become obvious. I have already fixed several errors of that kind, and I see now that my first project also will gain benefits from it, via improved code readability and structuring, despite the fact that I did not add features to it. I think it would be a good practice to always have at least two projects which both use a set of common classes, in order to be sure that those classes are written properly and do not make unnecessary assumptions about their usage.

64-bit Delphi version is ready

Embarcadero has finally released so long-awaited Delphi IDE version with 64-bit target compilation mode support. By far, I have been using Delphi 7 for about 10 years, and it still allows one to create first-class windows apps. I reluctantly considered an idea of upgrading to newer versions of IDE because of large amount of source code written during these years and of old habit. But I feel that now it is time to upgrade. For me, three main reasons are:

1. 64-bit compilation support

For example, if you have MS Office Add-In, clients will inevitably ask for support of 64-bit MS Office. You have to create 64-bit DLL in order to be able to integrate with any of 64-bit MS Office application, 32-bit, no matter how good it is, will not work. The only plausible solution before was to create a 64-bit stub DLL in Microsoft Visual Studio. Now one can provide 64-bit support without using another IDE.

2. Native Unicode support

Although using of WideString type instead of AnsiString everywhere, and components such as TNT Unicode Controls, in general solves the problem, there still remains some artefacts. For example, you can not register COM server with regsvr32 command, if DLL resides in a path that contains characters which are not representable in the default system Ansi Code Page. And WideStrings was designed to be compatible with system OLE interface calls, and thus they are not reference-counted and use a special system memory allocation routine, which degrade performance. In
contrast, since Delphi 2009, the new native UnicodeString type was introduced, which is reference-counted and uses internal memory manager to allocate space, more efficiently than system-wide does. TNT Unicode controls are also, while work, look a bit like a crutch.

3. Bugs fixing in the IDE

Delphi 7 is convenient IDE, but some intricate bugs sometimes annoy. These include "internal compiler error", AVs, and inability to customize the IDE watches and debug windows in arbitrary way (I constantly got AV after effort to do this). The same applies to C++ Builder 5.5 which I also used for several years.
Embarcadero seems to pay much attention to quality in last years, I hope that their latest products are much more stable.

Unfortunately, C++ Builder XE2 does not yet include 64-bit compilation mode, but its next version anyway seems to fix that. All what is said above, applies also to C++ Builder (I used it for several years).

During last years, Embarcadero are making great efforts to rehabilitate Delphi & Builder IDEs reputation in comparison with MS Visual Studio and open-source competitors. I hope that when demand of support for ARM CPUs will become evident, they will add it in time.

About testing

While working on my software projects, I often encountered a situation when almost all was ready for releasing a next version, but after starting final tests on different systems, many unexpected bugs were revealed. Sometimes after a small change in one part, other, presumably totally unrelated functionality, started to work wrong, sometimes the program worked right on one OS, but not on another, sometimes something very strange at first look appears.
The end conclusion that I have drawn is that testing should never be neglected or shrunk. It takes time, but if not done well, the end users will be whose who will find bugs and errors.

Similar thing has to be said about hardware testing. You should never be confident that a given part of device is working properly if it was not properly and thoroughly tested.

Object-Orieneted Systems Analysis and Design using UML

I'm currently reading the mentioned book from Simon Bennett, Steve McRobb, and Ray Farmer. Less than half of it already read, but I can say with confidence that the book is very useful, high-quality, with thorough and systematic approach.
I remembered that personally I too often neglected the software design phase and rushed to write a code, which led to far-worse-than-they-may-be solutions. I did not deal with large-scale systems as described in this book, all my projects were much smaller, but they definitely might (and should) be much better. I hope that even if I will not apply the exact techniques from this book, the systematic approach to software development process described by authors, will remind me about necessity to assign more time for planning and design when the next project will start.

This book on Amazon

Hard-to-find lack of variable initialization issue

Another bug which I once encountered, raised from using local (i.e., stack) method (or procedure/function) variables of record type. When you forget to assign some value to simple local variable, and then try to use it, Delphi compiler warns about it:

Variable "VarName" might not have been initialized

But when you have record-type local variable, and somewhere passes it as a parameter to another function, the Delphi (7) compiler does not check that you have initialized all fields. It will silently use whatever values was in memory at the call stack on the location that was taken for such record field. So you must be especially careful when using local record vars. Doing ZeroMemory on all such records at the very beginning of the function (or procedure/method), seems to be a good habit, otherwise it is a big chance that you will lose some valuable time trying to understand why the program behaves so strange.

To illustrate what has been said, take a look at the following code:

type
  TFoo = record
    a, b: Integer;
  end;

procedure A(Foo: TFoo);
begin
end;

procedure B;
var
  Foo: TFoo;
begin
  A(Foo);
end;

Compiler will not say anything on A(Foo) source code string.
The following string

ZeroMemory(@Foo, SizeOf(Foo));

before A(Foo), if will not make your program free of logical errors, but at least will make the program behavior predictable and reproducible.

Hard-to-find object variable overwriting issue

I write software programs in Delphi, version 7 (also in C++ Builder, but this post is about Delphi). Once I decided to optimize the code and to add "const" specifier to all parameter declarations of methods which are not changed in the method body itself. This is recommended for better readability and for performance reasons. For variables of WideString type, if you do not use "const" specifier in function parameters list, the compiler will create new copy of  passed WideString variable upon function entry and release it after function will return. This is because WideStrings are not reference-counted, as opposed to AnsiStrings. But when "const" is specified, the compiler passes pointer to string content (2-byte-wide chars) as is. So, I added "const" specifier everywhere when applicable, and did not receive any copiler warning. But during following testing, it turned out that something had became broken after this change. Strange error sometimes appears, which resulted in wrong value in some object field of type WideString. This error did not appear always, and only on one of two tested MS Windows versions.
I started to seek for the reason, and finally it traced to using WideString-type field of the object which passed as now "const" parameter. The code was something like:

procedure TFoo.SetProperty(const APropValue: WideString);
...
begin
...
  FPropValue := APropValue;
end;

....

procedure TFoo.DoSomething(const APropValue: WideString;...);
...
begin
...
  SetProperty(APropValue);
  DoSomethingElse(APropValue);
end;

procedure TFoo.DoSomething2(...);
...
begin
...
  DoSomething(FPropValue);
...
end;

The compiler did not detect any issues, yet the problem was
that after invoking of SetProperty, the previous pointer to WideChars array contained in FPropValue field, and in APropValue parameter, becomes invalid, but this old pointer value was used when invoking DoSomethingElse method.
I fixed the problem by eliminating "const" specifier from DoSomething declaration.

Be aware of such a pitfall!