Calendar causes app to stay resident

[Josh-Ferrus]

Hi Roger, sorry for the delay in responding, we have a lot of balls in the air at the moment.

Most of the computers in our office are running express build 254. However, I just updated mine to 255 to check, and it is still staying resident. It also doesn't seem to matter what sort of operating system it is - I have tested on a 64 bit windows 7, 32 bit windows 7, and windows XP computer; in all cases the program didn't close properly.

To clarify, the app doesn't stay visible in the Applications tab of the task manager. It's only if you go to the Processes tab that you will find a Calendar.exe. It's a pretty low memory app, so it is easily buried in the list of other apps.

After doing some research online, I'm thinking this is likely actually a codejock issue, and not something to do with xbase or Express at all. Other people using the codejock calendar in other programming languages have reported similar issues. However, they seem to be pretty scarce, so I don't know if that's just because not many people are using it, or if there's just something specific that we're doing wrong. The one thread we found on the subject seemed to indicate that it was only happening on 64 bit computers, but my own testing doesn't seem to match that.

I'm sure a possible fix would be to change how we exit our program, but that would require rewriting our entire program flow, which I'm not sure is worth it just for a pretty calendar.

Thanks.

[rdonnay]

Please try this DCLIPX.DLL. I do not have the problem with this one, however I do have the problem with build 255.

I'm not really sure what changes would have made the difference, but I think it may be related to changes to the way the tooltip thread is destroyed.

http://donnay-software.com:8080/donnay/dclipx.dll.

[Josh-Ferrus]

That seems to have worked! The calendar in my sample app is no longer staying resident. I will re-enable the calendar in our main app and verify that it works there. Is this an old dclipx dll, or a change that you made specifically to fix this problem?

[rdonnay]

This is my most current beta of build 256.

Let's hope it works on your main app.

[Josh-Ferrus]

Okay, so, the new dll didn't work directly out of the gate with our main app. After some testing I determined that it's because in our main app we are using QUIT to break directly out of the program, while the dc_readgui event loop is still running, instead of allowing the event loop to finish and the cleanup code to execute. I tried just replicating your cleanup code in our exit procedure, but that had no success - possibly because I only have the source for your 355 dc_readgui() function, not the 356 one you provided.

Eventually, I ended up just reworking our program flow enough that the event loop is allowed to terminate. This seems to be functioning fine so long as we use your 356 dll (the 355 one we still have issues closing). I will monitor the solution and make sure the problem doesn't manifest again, but for now we seem to be solid.

Thanks for all your help. There shouldn't be any incompatibility issues using your 356 Dclip.dll while the rest of our express library is 355, right?

[rdonnay]

Thanks for all your help. There shouldn't be any incompatibility issues using your 356 Dclip.dll while the rest of our express library is 355, right?

I always work very hard to prevent regression. Should be no problem.