So I finally got around to writing something here! This isn’t quite a miracle, but it’s close. For some time now I have been re-learning C; my latest project is an encrypted password manager called Trove and recently progress was stalled for quite a while due to a couple of evil bugs. Trove is mostly completed as a console application and so next I’m making a GUI for it, learning Win32 API as I go. The first bug caused me long delays right at the last stages of the console app work, the second bug caused even worse delays in the very early stages of the GUI. The first bug was just my own stupid fault, but the second was a weird one which is why I’m writing about it here. Onwards…

While thinking the console app was at least 98% finished (ha) I was doing some testing and discovered a bug when changing the database password. Using a blank password was fine, using any non-blank password was also fine, changing from non-blank to another non-blank was fine, but going from blank to non-blank to blank would then finally fail to accept the (blank) password any more. Clear as mud?

As the database is encrypted and the password (or lack of) is used to decrypt it this meant losing the database on every test and made debugging difficult as the issue appeared to occur after the point of encryption with the changed password. Clearly this was a problem with my encryption method and couldn’t possibly be due to me doing something stupid so I spent a long time trying to trace the problem. I found it way over complicated to follow my own program logic flow by this point which showed that the overall design had become a mess over time. So, after a lot of refactoring I finished with a far simpler flow and exactly the same password problem.

Dev time at home is limited so all this took place over 2-3 weeks, with a lot of hair pulling and swearing. Eventually though I worked out that the password’s array was not being fully cleared when changing the password, only overwritten. When going from an existing password to a blank one it only replaced the first position with \0 and the rest of the characters remained. Then when later entering the password it then failed the comparison because it was compared against a null followed by other characters. That’s it. At least 3 weeks of constant frustration just to find this silly little mistake that had been in place throughout the entire development. Sigh…

Shortly after that the console app reached v1.0 and I moved on to the GUI. I had barely even seen the Win32 API before this so had little idea of what I was doing. I used some example code to throw a basic window together, and realized that was all I could do without external help. So I did a couple of tutorials, all good, ready to rock, off I go. My window becomes a real app with controls and data and life is good. I want to get all the basic GUI stuff in place before attempting to transplant the actual contents of the app into it, so step 2 is to open a second window (for editing a DB entry) on request.

As I was unable to find any good guide on creating a second window (not a dialog box) I just used the same code as for the main, and added some labels, buttons and edit boxes. However when running it only 1 label would appear and all the other controls were missing. Experimenting showed that I could display all the labels & buttons without issue but if the edit boxes were added only the problem re-occurred. I assumed I did something wrong in the window generation code so more tutorials, research, guides, experimenting ad nauseum. No google search ever found any example of this issue before, which is never a good sign.

I tried changing it to use a dialog window instead, same issue. Add the exact code to the first window, it works fine, round and round in circles of confusion. This dragged on for some weeks, blocking all progress as without being able to create the other windows I would need there was no way to move on. There was a lot of experimenting but always finished back with the same bug again. Eventually I found this question on Stack Overflow:-

This didn’t address my problem but was an example of one window creating another, and after fixing the bugs it worked just fine, so clearly it could be done after all! I could not find anything obviously different, it looked like my generation code was fine, and yet one program worked and one did not. I got to the sad, desperate stage of comparing line by line, character by character, trying to find what weird thing was causing my problem. Then copy-pasting code block by block, and suddenly it was fixed. I finally narrowed it down to the line the cause of this evil problem. Here is the code that had the problem:-

        wcEdit.cbSize = sizeof(WNDCLASSEX);
        wcEdit.cbClsExtra = 0;
        wcEdit.cbWndExtra = 0;
        wcEdit.hbrBackground = (HBRUSH)COLOR_WINDOW;
        wcEdit.hCursor = LoadCursor(NULL, IDC_ARROW);
        wcEdit.hIcon = NULL;
        wcEdit.hIconSm = NULL;
        wcEdit.hInstance = instance;
        wcEdit.lpfnWndProc = editWndProc;
        wcEdit.lpszClassName = “Edit”;
        wcEdit.lpszMenuName = NULL; = CS_HREDRAW | CS_VREDRAW;
Looks normal, right? Perhaps it’s an obvious problem to you, but this was something I did not expect and have never seen mentioned anywhere.
        wcEdit.lpszClassName = “Edit”;
This one line.
This one word.
I changed it to “TroveEdit” and lo, everything was fine. I assume the name “Edit” is reserved, or causing a conflict maybe, but there were no compilation warnings or errors, no mention of NOT using certain words as a window class name so never suspected it.
Finally it was done, my multiple windows could work as intended and everything else could start moving ahead. At this time Trove is mostly complete, just a few little things to sort out and it will be all over. If you need a simple, encrypted password database check it out on GitHub:-