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?
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.
Related
I updated my Windows 10 from 16179 to 16184 and since then, the Delphi ide does not appear anymore, but bds.exe is running normal in task manager.
Anybody has any clue whats going on?
Delphi is the only application so far which does not start properly.
When I revert back to 16179, Delphi works again as usual.
Pressing F12 while the program is running in the debugger should break the execution and open the debugger. This works correctly on Windows XP (tested with D2007 and XE2) but fails on Windows 7 and 8 (also tested with D2007 and XE2; tested on three computers).
Registry is set up properly (Windows 7):
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug]
"UserDebuggerHotKey"=dword:00000000
"Debugger"="\"C:\Windows\system32\vsjitdebugger.exe\" -p %ld -e %ld"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\AutoExclusionList]
"DWM.exe"=dword:00000001
The XP installation also sets "Auto"="1" and omits the AutoExclusionList but duplicating those changes on the Windows 7 machine accomplishes nothing.
The weird thing is that Delphi seems to be aware of the F12 being pressed. When I run a program in a debugger on a Windows 7 machine and press F12, Event Log window in Delphi shows
Thread Start: Thread ID: 4080. Process Project73.exe (7108)
Thread Exit: Thread ID: 4080. Process Project73.exe (7108)
It's just that the breakpoint is not triggered and application keeps running.
Does anybody know how to restore this functionality in Windows 7/8?
The Debugger sees that a new thread is started by Windows, but it doesn't know what that thread is. In XP this thread runs into a int 3 break point (DebugBreak()), but under Vista and Windows 7+ the breakpoint isn't hit anymore even if you set the registry key.
There exists a Delphi IDE plugin that catches the thread and calls the DebugBreak() WinAPI function.
http://andy.jgknet.de/blog/ide-tools/unsupported-tools/
I have an application developed in Delphi 5 that works very well in Windows 7 using the XP Mode, except for one code:
TQRCompositeReport.Prepare
That function only works if I am using an administrator account.
If I am using an account that don't have administrator privileges, it works only if the "XP Mode" is disabled.
Since I have some errors runing my app in Windows 7 without XP Mode, I have to activate this option. Then, I can't preview or print any reports using this command to prepare it.
I have the idea that it may concerns to some temporary files that quick report generates, once it does work using administrator accounts. However, the default temporary folder in Windows 7 is "C:\users\username\App Data\Local\Temp\ and the user has privilege to create and modify files in this folder.
I am really stumped.
I am running delphi 2007 on vista. I have built many applications and run them in XP with no problem. This latest app had to make use of threads. I'm pretty sure my code is correct. It runs fine on Vista, but when I run it on XP (tried multiple PC's) my program seems to lag (both os's 32 bit, XP sp3 and Vista sp1, dotnet v2). Best example being if I unplug the serial port my coms will continue to run etc.
I was installing delphi on my xp machine, and ran my program while delphi was running. As in I ran it from the exe built in vista. It ran fine then. Close delphi, and the comport starts to lag again.
If I unplug and replug a flash drive, the coms catches up again.
I want to build the app on my xp based machine, but have like a million 3rd party components that makes it a real mission to setup.
Oh fyi, i built a simple application with just the main thread, and a comport thread. Same problem. All the comthread will do is fetch data off the comport. Not even display it, i used a serial port monitor in the background to check for the lag.
Any suggestions welcome.
OK quick edit: the XP pc is freshly built. I opened msn messenger, and the program runs fine. I'm obviously missing some setting...
If you're using Sleep in your threads (hence my comment/query to your question), you should use timeBeginPeriod to indicate your desired resolution. As you've already found out it doesn't matter where you call it; can be the main thread or even an entirely different application.
See this thread on embarcadero forums, and of course the documentation (remarks) on MSDN.
Are your OS installed on two diverse PC?
I guess one of your computer has a true dual-core processor (the one with XP), and the other (the one with Vista) has a one-core processor. Sometimes multi-threaded app reveals their problem when run on true multi-core processor.
The Delphi debugger sometimes change the CPU affinity, so it could work on the debugger, but not outside it.
Another possibility to check: try your software under XP with setting affinity to only one CPU.
I've seen that before. But it's likely something else, since you said you've tried your SW in multiple PCs.
I have a Delphi 2007 application that has a TAnimate control with a FindFile Common AVI. It works perfectly when the application is run on Windows XP, but nothing ever appears on Windows 7. I've heard it now requires its own thread, but I am not certain.
Does anyone know how to get TAnimate's Common AVI control to work on Windows 7 (or Vista)?
You must add the unit ShellAnimations to you project or add the component TShellResources from the Win32 tab of the component palette. (Tested in Windows Vista- Delphi 2007)
uses
ShellAnimations;
this unit adds the following replacement animation resources to your executable:
FindFolder.res
FindFile.res
FindComputer.res
CopyFiles.res
CopyFile.res
RecycleFile.res
EmptyRecycle.res
DeleteFile.res
Bye.