1

I currently run a 64bit Windows 10 development box. I have old VB6 source that I have to unfortunately keep updated for the time being. For some reason all the sudden I noticed that one of the applications I have just built seemed to stay running in the background after the GUI was closed.

I started debugging the issue more and more until I found out that the only time it would seem to persistently stay open in the background after the GUI was closed was if I clicked the button on my form that would call the Common Dialog control to show the file open GUI. I only have to show the file open window and then hit cancel for this to happen.

This ONLY seems to happen on ONE of my dev machines (not the other). Every time I use that CD file open box I have to open task manager up and end the task. I also tried to make sure all forms were closed when my main form starts to Unload. Nothing seems to work or shed any clue on what the issue is. I have also double checked that the following files are now all the same coping them from the known working dev machine to my broken one and re-registering them.

  • COMDLG32.OCX
  • comdlg32.oca
  • comdlg32.dll
  • COMDLG32.DEP

Both machines are running the same exact OS Win10 Pro 64bit.

Arvo Bowen
  • 4,524
  • 6
  • 51
  • 109
  • Might there by different Windows Explorer extensions running on the two systems? –  Oct 20 '18 at 01:23
  • @PeterCooperJr. Yea both machines are very different but what would cause an app that uses the common dialog window to not close? – Arvo Bowen Oct 20 '18 at 01:50
  • @ArvoBowen This is not "an app that uses the common dialog" but a whole lot of legacy app you are testing. Just start from an empty project, place comdlg and a button and test if the app is closing after showing open file dialog. If again it's not, then there is a problem with the target OS, not your legacy app per se. – wqw Oct 20 '18 at 10:18
  • It sounds like something, perhaps a shell extension in that folder or a logic path in your program, has a reference to your program. COM rules are you can't exit till reference count is zero. – CatCat Oct 21 '18 at 18:52

1 Answers1

0

That does sound strange, getting different results on the two machines. Pragmatically, you can work around the problem (without actually understanding it) by making sure that you execute an End statement. (You can put it in the QueryUnload event to make sure it's hit if the user clicks the "X".)

Mark Moulding
  • 549
  • 2
  • 5
  • Thought of that hack first thing... Even that bad code habbit will not work. I have that in the QueryUnload sub and it has no effect. PS: I have given up trying to understand VB6 for 10+ years now. It does whatever it wants sometimes... And unstable... Gezz! – Arvo Bowen Oct 20 '18 at 01:48