4

I have an application written by Delphi 7 and this application works fine in windows XP.

Now i has upgrade my pc to windows 7 and everythings works fine with this application except when i click the button which will execute the TOpenDialog and TSaveDialog then hangs.

Anyone have this problems when using delphi 7 in windows 7?

menjaraz
  • 7,551
  • 4
  • 41
  • 81
delphi beginner
  • 41
  • 1
  • 2
  • 2
    I can't answer this without seeing some code. Could you show us the code which invokes the file dialogs. – David Heffernan Mar 30 '11 at 10:30
  • Unfortunately I had this problem with Delphi 2010 and Windows 7. Doesn't work from the debugger, works fine from outside the debugger. The same code works fine under the debugger on a different machine. Probably has something to do with the interaction between the debugger and some windows shell extension. It was too weired, I didn't manage to find a solution. – Cosmin Prund Mar 30 '11 at 10:49
  • Does it hang or does 'execute' return doing nothing? If the latter, this is a duplicate of ["SaveDialog.Execute not doing anyting in window 7"](http://stackoverflow.com/questions/2156013). Anyway, see if the answers there would help.. – Sertac Akyuz Mar 30 '11 at 12:03
  • I had a similar problem (Delphi 2009) that one of my users experienced. It would take around 60 to seconds for Windows to bring up the open dialog (not in debug mode). It only happened on his computer and stopped by itself after a while. We never figured out what caused it. – boileau Apr 01 '12 at 13:12

1 Answers1

5

Most likely reason is an issue with COM. The Open/Save dialog needs to run in an STA COM apartment otherwise some shell extensions can lock up.

If you have anything in your application which initializes COM in a different mode for the main thread, lots of strange things can happen.

menjaraz
  • 7,551
  • 4
  • 41
  • 81
Thorsten Engler
  • 2,333
  • 12
  • 13
  • I thought that the dialogs spun up separate threads for the shell extensions and set the threading mode appropriately. I don't recall ever seeing any documentation to back up what you say. – David Heffernan Mar 30 '11 at 11:28
  • NexusDB used to have a "COM Transport" in the past (It's deprecated now as the shared mem transport fills the same role). One of the problems with it was that in it's first version it initialized whatever thread it was being used on as a free-threaded MTA. This caused a lot of problems things like open/save dialogs (that was with D7 and under XP, things may have changed since). – Thorsten Engler Mar 30 '11 at 12:52
  • You could very well be right. Certainly the dialogs on Vista/7 spawn a lot of threads. I assumed it was to keep things segregated. – David Heffernan Mar 30 '11 at 12:56
  • As far as I know, most of the main code is running in the thread that opened the dialog. The dialog itself has it's window handle belonging to that thread, which means that also it's IFolderView interface must run in this thread which means that pretty much all the shell extensions must run in that thread. Any additional threads you see are probably threads started internally by various shell extensions, not by the main shell code. – Thorsten Engler Mar 30 '11 at 15:53
  • A very good answer - as I have to find the cause for similar problems (frequent crashes when opening dialogs) in a PDF viewer application which uses Acrobat Reader ActiveX controls. – mjn Apr 01 '12 at 13:32