Tweet
Some of you maybe already knew this. I didn't, and so my hair has
become a bit grayer than yesterday. Thank you, Microsoft, for
making life as programmer so interesting..
Here's story:
I create a setup dialog for an editor. As I usual do when I create
additional dialogs for a program, I create a sub-folder with the
same name as the dialog and build it as a stand-alone exe first.
Faster to load and rebuild, etc, that way.
Okay, so the file name is "SetupDlg.bas", the folder is named
"SetupDlg" and the exe becomes "SetupDlg.exe". Standard DDT used.
I design, add a tab control and all that's needed, compile and it
looks fine. When I close the dialog I notice that the hourglass
mouse pointer blinks a couple of times, indicating that something
happens, just after the dialog has been closed. ?
I tear the dialog apart. Uncomment it piece by piece, and the
hourglass keeps on blinking at exit. Finally, there's only the
actual creation of the dialog left - DIALOG NEW.. Hourglass
blinking just after exit is still there.
I become slightly desperate. I move the dialog to another folder
and test, same thing happens. I test another small app', almost
identical code - no hourglass blinking at exit. Now my mind also
starts blinking. What's up?
I move the "non-blinking" exe to first dialog's folder, start,
close, and the hourglass mouse pointer shows up - blink, blink.
Eh..? I rename the folder to "OptDlg", rename the original code
to "OtpDlg.bas", compile and voila - the blinking is gone!
To confirm my suspicions, I test "non-blinking" code again. Rename
it to "ASetupB.bas", compile - and the hourglass mouse pointer
blinks at exit. Aha! Change it back to original, "TestApp.bas",
compile, and the blinking is gone. Move TestApp.exe to "SetupDlg"
folder, and blinking at exit is back. Also test with the word
"install" in exe name - blinking is back.
Case closed. I suspect some registry issue - whenever an application
includes the words "setup" or "install" somewhere in the full path
name, the system seems to make some automatic checks/writings when
that program is closed down. Really weird, IMHO, but good to have
in mind for future design..
------------------
become a bit grayer than yesterday. Thank you, Microsoft, for
making life as programmer so interesting..
Here's story:I create a setup dialog for an editor. As I usual do when I create
additional dialogs for a program, I create a sub-folder with the
same name as the dialog and build it as a stand-alone exe first.
Faster to load and rebuild, etc, that way.
Okay, so the file name is "SetupDlg.bas", the folder is named
"SetupDlg" and the exe becomes "SetupDlg.exe". Standard DDT used.
I design, add a tab control and all that's needed, compile and it
looks fine. When I close the dialog I notice that the hourglass
mouse pointer blinks a couple of times, indicating that something
happens, just after the dialog has been closed. ?
I tear the dialog apart. Uncomment it piece by piece, and the
hourglass keeps on blinking at exit. Finally, there's only the
actual creation of the dialog left - DIALOG NEW.. Hourglass
blinking just after exit is still there.
I become slightly desperate. I move the dialog to another folder
and test, same thing happens. I test another small app', almost
identical code - no hourglass blinking at exit. Now my mind also
starts blinking. What's up?
I move the "non-blinking" exe to first dialog's folder, start,
close, and the hourglass mouse pointer shows up - blink, blink.
Eh..? I rename the folder to "OptDlg", rename the original code
to "OtpDlg.bas", compile and voila - the blinking is gone!
To confirm my suspicions, I test "non-blinking" code again. Rename
it to "ASetupB.bas", compile - and the hourglass mouse pointer
blinks at exit. Aha! Change it back to original, "TestApp.bas",
compile, and the blinking is gone. Move TestApp.exe to "SetupDlg"
folder, and blinking at exit is back. Also test with the word
"install" in exe name - blinking is back.
Case closed. I suspect some registry issue - whenever an application
includes the words "setup" or "install" somewhere in the full path
name, the system seems to make some automatic checks/writings when
that program is closed down. Really weird, IMHO, but good to have
in mind for future design..
------------------
Comment