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.

Android-powered Tablet PC for reading books

A few days ago, I bought MoveO TPC-1VX Tablet PC (in Russian) with Android 4.0.3 on board. It features 7" multi-touch 800x480 screen, 4 Gb of built-in flash memory, 512 Mb RAM, and other characteristics are on the line of other devices in this price sector. I wanted low-cost handheld PC mainly to be able to read books (PDF, HTML, and other standard formats). It is much more convinient to do this on 7" than on 3.6" screen. It even fits into pocket of my sleeveless jacket. By far, I have not observed any bugs or software freezings. Maybe one day I will write a program for Android platform. At last, Android today is the most popular OS for mobile devices.

P.S.: well, I already have bicycle and Tablet PC. The only thing left to buy is reflex camera, and I will completely fit controversial folklore image of a young programmer :)))

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.

Dummy bicycle lanes in Moscow

This summer, I was in Moscow for a few hours, walking through the city while waiting for my train. My attention, among other things, draws to the fake (dummy) bicycle lane on prospekt Vernadskogo, near the "University" metro station. This "bicycle path" is actually one metre wide green band drawn on the pavement. The problem is that people do not regard it as a road for bicyles - instead, all pedestrians treat this piece of asphalt simply as part of pavement, and behave accordingly. Everyone who will try to move on this path on bicycle with a speed more than 15-20 km/h, will inevitably bump into someone else (pedestrian) during the first minute of trip. So this "bicycle lane" is absolutely useless, this is essentially just a mock-up. Even more, it is not only useless, but harmful for all cyclists. This is because if anyone wants to cycle with reasonable speed here, right solution would be to move in traffic area of this prospekt, in the first traffic lane, near the border. But Russian road laws states that cyclists should move through the special "bicycle lane", if there is one. So if any cyclist would bump into another object (car, bus, or pedestrian), while moving on traffic area of this prospekt, one could say that this happens because of he/she do not abide this particular rule of road laws. Shame on those who were responsible for this fake "bicycle lane".

Reanimating NiMh Battery Pack in home cordless phone

At home, we have cordless "TELECOM" phone. This summer, after two weeks of idle time during our vacations, it refused to continue working. It also refused to charge its pack of 3 NiMH batteries (T160 600 mAh 3.6V D4 marking). I.e., green LED which should indicate chraging process and presence of phone tube on the base module did not turn on when I tried to start charge the cordless receiver by putting it to its place (its dedicated socket). I tried to apply the same method I used for my LiIon smartphone battery (see my previous post on it): firstly to charge battery directly via lab DC power supply. The difference is that this pack of 3 NiMH batteries does not have internal built-in charge controller, so there is no need to disclose internal connector pins. I set up output voltage to about 4 Volts, and max. current to about 50 mA. After approximately 2 hours, power supply switched from constant current into constant voltage regulating mode, and I disconnected the battery. After placing this slightly recharged battery back into cordless phone tube, and putting this tube back on base station, green LED which indicates charging process, turned on, and device continued to work in normal mode. Apparently, charge controller built into this phone tube needed for its operation higher voltage than discharged battery was able to deliver. So be aware of this method, and do not throw out your battery prematurely.

UPD: the same method works with NiMh AAA accumulators, I've just checked this today. 900 mAh acc. battery discharged to ~0.7 volts has been charging with ~90mA current for a few hours, after that I was able to complete the process with standard charger.

P.S.: Caution! In absense of temperature monitoring circuit, do not charge the battery with currents more that 0.1*C, for example, in my case I had battery with 600 mAh Capacity (designated by capital "C" letter), so max. safe charging current was 60 mA. Also, do not try to repeat this without proper setting of output voltage limit in your power supply. Put the battery into protective box for a period of charging to prevent damage from its possible explosion. Make sure that you are ready to quickly disconnect the power supply and to extinguish a fire in case if it will arise.

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.