Zugg Software :: View topic

Posted: Fri Oct 12, 2007 11:20 pm

Well, I'm having a very bad day with this. I was all ready to release 2.06 and then it started doing something really weird: It will no longer exit. When I click the X button or use File/Close, it closes the various docked panels, but the main window never closes. I cannot figure out what has possibly caused this. It is properly calling the PostQuitMessage API in Windows, but then it never sees the WM_QUIT message in the message queue.

What's weird is that it was working fine this morning, and I haven't done anything today that would mess up the message loop. Maybe I'll reboot Windows to see if that helps. Otherwise, I'm really stuck here and I can't release 2.06 until I fix this one.

Looks like I'm not going to get it released before dinner like I normally do. Hopefully later tonight. I don't know why this kind of stuff always happens on release day Evil or Very Mad

Posted: Fri Oct 12, 2007 11:31 pm

Leprechauns.

On a slightly more serious note (only slightly - those leprechauns are tricksy!) it's probably just that the times it happens on release day stand out more than the times when it doesn't. Often, if this sort of thing is going to happen, it happens shortly after release, so be happy about that, at least :)

Posted: Sat Oct 13, 2007 12:00 am

OK, this is the weirdest problem I think I have *ever* encountered! It's driving me completely crazy!

When you close the main form in the application, it calls the PostQuitMessage(0) Windows API routine. This routine is supposed to post the WM_QUIT message to the message queue. When the WM_QUIT message is processed, the application exits.

So, right after the call to PostQuitMessage(0) I do this:

B := PeekMessage( Msg, 0, WM_QUIT, WM_QUIT, PM_NOREMOVE)

to test to see if WM_QUIT is in the message queue. It returns FALSE!!! This is impossible!!! I have verified that it is running in the main thread. If I replace the PostQuitMessage(0) with this:

PostMessage( 0, WM_QUIT, 0, 0)

then it works! Now PeekMessage returns true and the application properly exits.

So how the hell can PostQuitMessage(0) not work? I've Googled this and I can't find anything that would explain it. Since I *immediately* do a PeekMessage, then nobody else can be secretly removing the message from the queue. And since we are in the main thread, it should be going to the proper message queue.

Of course, I can't see the Microsoft source code to determine what PostQuitMessage really does. And I have NO IDEA why this is suddenly happening today when it's never happened ever before.

This just makes absolutely no sense at all. And I'm really leary of releasing something with this kind of problem. It's got to be some sort of corruption somewhere, but I can't track it down. I've rebooted Windows multiple times, but it's almost like the Windows API is screwed up somehow.

I really don't know what I'm going to do about this. I need to go eat something and think about it. This version was going *so* well up till now. I don't know why this kind of stuff happens!

Posted: Sat Oct 13, 2007 12:05 am

Well, here is a Microsoft blog about this: http://blogs.msdn.com/oldnewthing/archive/2005/11/04/489028.aspx

Apparently they are trying to do something fancy with PostQuitMessage. It doesn't really get posted and only gets returned when the message queue is "idle". So, maybe something is in a loop generating other messages so that the WM_QUIT never gets generated.

Something to think about I guess...although I find this a really annoying "kludge" for handling WM_QUIT.

Wizard Joined: 14 Aug 2004 Posts: 1269

As a bit of light relief from this stress, a little Delphi anecdote from today: my boss was nearly tearing his hair out today (if he had any) because Delphi (v5) wouldn't open any of his Delphi files. It could create new files - just not open an existing one. He'd even tried rebooting to no avail. I suggested he checked the files were still readable in Textpad - yes, they were. He was not looking forward to having to reinstall Delphi and all his components! I suggested he tried saving a new Delphi file and see if he could reopen it - he could! And, hey presto, he could now open all his old files! Very Happy

So, it's not just you who has been having weird Delphi issues today!

Posted: Sat Oct 13, 2007 1:19 am

Wow, that is pretty weird. Must be "gremlins" day around the world today. Interesting that he is still using Delphi 5. I noticed that Developer Express officially stopped supporting Delphi 5 in their last component release.

Anyway, I'm back from dinner, so now I'll try to find out if something is flooding the message queue with other events.

Posted: Sat Oct 13, 2007 2:06 am

The MS Spy++ program shows that when I click the X button, a bunch of messages are being sent. Here is the output:

Output moved so this thread's width isn't annoying - Fang.

Notice how suddenly the messages have all the ... in front of them? That indicates something called the "nesting" level. So it seems like something is in a loop sending the WM_WINDOWPOSCHANGING event. But there is no way to tell where this event is being sent from.

Posted: Sat Oct 13, 2007 2:23 am

OK, I have narrowed it down to something in the damn docking system. It only seems to happen when the mapper window is open and the X button for the main application is clicked. Still hunting. (oh great, now this thread has a screwed up width :( )

SubAdmin Joined: 18 Nov 2001 Posts: 5182

If I am reading that trace right then the same section of code is sending and receiving the messages. That means it is actually sending a nested one to other controls after sending one good one to the first control.

Looking at the API docs it would appear that a WM_CLOSE would spawn this message, although it makes no sense for it to be done that way. Another of those wonderful MS documentation things "...of a call to the SetWindowPos function or another window-management function." Those other window management functions cover about 50% of the API, perhaps a little stupid sauce would go well with our vague steak.

I wish I could help figure this one out more, but with such crappy docs it become very hard to make sense of it. Do you even have any processing for this message or is it all cause by the DefWindowProc?

Posted: Sat Oct 13, 2007 2:45 am

While I can't offer much help with this problem (though it seems that Microsoft can't either, so I don't feel so bad), I can help with the thread width.

Posted: Sat Oct 13, 2007 3:05 am

Thanks Fang :)

Yeah, almost everything called SetWindowPos these days, and of course I can't set any breakpoints for the Windows stuff.

I found that the docking system was just hiding the mapper docking panel even though the mapper window itself was being destroyed. The docking panel should have been removed, not just hidden. Fixing this made the problem go away.

I'm still completely perplexed as to why this would only start happening now. I've been playing with the mapper open a *lot* over the past few days and this problem wasn't happening before. So I still have no idea what changed. That makes me nervous.

And now, I started some final testing and discovered that changing variable values on the command line are not getting saved to the database. I don't know if this was happening before or not, but it's something else serious that I need to fix before the release. I think I'm just cursed today.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Gremlins2 was on one of the movies channels earlier. We can't really be sure if the electric gremlin died, and we know the female one didn't by the end of the movie. Who knows maybe the movie makers wren't just creative geniuses, perhaps they had some sinister plot in mind when they made Gremlins.

Roll your chair back, lean back some (slowly so the cat is not disturbed). Now let out an insane laugh that causes the cat to jump to keyboard and type the solution.

Posted: Sat Oct 13, 2007 3:32 am

I guess that would probably be better than me cursing at the computer at the top of my lungs? Wonder what the neighbors think?

When I called the Lock routine to prevent the changing of the database from calling various UI routines from a background thread, it turns out that calling Lock also prevents the kbmMemTable database from ever setting the Modified flag for the database. And since Modified isn't set, the background thread that updates the database file doesn't think anything was changed.

So, I've had to modify the DataEvent routine so that even if the dataset is locked, it still always sets the Modified flag. Now, let's see what kind of side effects *that* has.

Oh, and the Gremlins are definitely out in force tonight. The Microsoft Spy++ completely locked up my computer twice, requiring a hard reset. And Delphi has crashed to desktop about 3 times tonight already. That isn't helping at all.

Posted: Sat Oct 13, 2007 3:36 am

OK, now one of my triggers isn't firing. Was working fine last night. This is just never-ending!

Posted: Sat Oct 13, 2007 3:45 am

Well, that was weird too. According to the trigger editor, there was only a single space at the beginning of the pattern. But it was trying to match a trigger with *two* spaces at the beginning. I edited the pattern and then it worked again and saved properly. So I have no idea how the extra space got into the cache. Yet another thing to worry about. Let me play some more and see if I'm willing to release this thing or not.

Posted: Sat Oct 13, 2007 4:15 am

OK, it's out. See the version history for the long list of bug fixes.

Yesterday I was feeling *really* good about this version since I had played without any hangs or crashes for many hours, including letting it run overnight. But after some of the frustrating weird problems today, I'm still not sure how good this version will be. Hopefully it will be better than previous beta versions. I'd really like to think that this is getting close to public release status. The number of bugs on my list is getting shorter and shorter (but there are still plenty left to fix).

Hopefully I fixed your favorite bug in this version. Like I said, at least I personally have found it *very* useable at this point. Good luck with the testing this weekend. I might be playing with it myself (yes, I'm addicted to MUDs once again :)

Wizard Joined: 14 Aug 2004 Posts: 1269

BTW, good change with the flyout windows! Much less annoying now!