After reinstalling Delphi (and installing the Update 1 on top of it) it needs 19-20 seconds to start.
In the beginning it shows nothing (about 17 seconds).
Then it finally shows the splash screen and the modules it loads. I already have DelphiSpeedUp plugin.
How can I make is start faster? Or is this the typical loading time for Delphi XE with Update 1?
Update:
'Process monitor' shows that Delphi accesses the HKLM\system\currentControlSet\Services\TcpIp\Parameters and stays there to about 10 seconds. No other registry key or file is accessed after this, for 10 seconds!!!!!!!
Probably is the Embarcadero's protection that tries to 'call home'. I guess I have to unblock Delphi in my firewall. Maybe if it can call home it will load faster.
Also, does anybody tried to make Delphi XE .Net free?
20 seconds for click-on-icon to IDE-ready-for-input?
Don't change anything! I wish mine was as fast as that!
I was so damn right!!!! By default, my firewall block all programs except Firefox and Thunderbird. So, I let Delphi XE call home and guess what: It loaded in 10 seconds!
With the firewall off it connected to two different IP addresses and exchanged some data.
One of the addresses is server155.autometadqa.com (64.34.176.155:80).
Probably I will have to install some network package tracker to see what kind of data it sent out of my computer and in which qualities (KB, MB).
Solution1-Make Delphi fast
Let Delphi through the firewall.
Solution2-Keep computer isolated from internet
Don't let Delphi through the firewall.
I know absolutely nothing about Embarcadero except that they make Delphi now. But since they had money to buy it, it means it is a big company and because of this case, also respectable. So, I will let Delphi through the firewall in order to cut those 20 seconds to 10.
Try to add following line in your HOSTS file:
127.0.0.1 server155.autometadqa.com
Repeat this for all servers if there are more then this one.
Is Delphi phoning home, or is it checking for updates?
What happens if you change your firewall setting back and simply turn off the check? In XE, the registry key is:
HKEY_CURRENT_USER\Software\Embarcadero\BDS\8.0\AutoRun\UpdateCheck
You can disable the auto-update, if indeed that is the cause of the delay, by removing these registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\CodeGear\BDS\7.0\AutoRun\UpdateCheck
HKEY_CURRENT_USER\Software\CodeGear\BDS\7.0\AutoRun\UpdateCheck
I'm not sure that you need to remove both, but I always do. And this is for a 64 bit machine. On a 32 bit machine you need to remove:
HKEY_LOCAL_MACHINE\SOFTWARE\CodeGear\BDS\7.0\AutoRun\UpdateCheck
HKEY_CURRENT_USER\Software\CodeGear\BDS\7.0\AutoRun\UpdateCheck
I do this because the auto-update doesn't play nice with UAC on Delphi 2010 (perhaps they fixed that in XE) and in any case, I don't like the idea of my production compiler changing without my consent.
Related
I have an ancient program that I use for reading and writing data from AutoCAD. This program is written in Delphi 5. I have tried to update it to a newer release but several of the libraries I use no longer exist and it is a huge program with lots of libraries used.
The program uses the ACAX##ENU.TLB type library that is provided with AutoCAD. Where ## changes for each AutoCAD release. Every time Autodesk sends out a new AutoCAD version I import the new type library and life goes on.
Now I am faced with Windows 10. For some reason the automation links between my program and AutoCAD are not working in Windows 10. Did something change about the way the type libraries work between Windows 7 and Windows 10? Something that Delphi 5 is no longer compatible with? Maybe it's a 16bit vs 32bit vs 64bit issue. That is all over my head but I understand that Windows 10 dropped support for some 16bit operations. But my program itself runs perfectly. Even the BDE can be made to work which is amazing to me.
Is there anything I can do for an experiment? I am really lost about what to even experiment on.
Thanks.
Well, it's been a long time since I asked this question but here is an answer:
I was able to get my Delphi 5 compiled program working with AutoCAD 2017 in a Windows 10 environment. I am pretty sure that the solution was to run the program WITHOUT administrative permissions and WITHOUT any compatibility modes switched on. Apparently Windows places restrictions on COM communications as soon as you turn on either of those features. There may have also been issues with Windows 10 still having UAC active even when you set UAC all the way off. There is a registry setting to actually set UAC to off but my corporate IT prevents turning that off even with admin rights.
So in the end it was not a problem with Delphi, my program or with AutoCAD. It was a Windows 10 problem.
There was a bit of a clue that might be helpful to others: with the admin permission and/or windows XP compatibility turned on the program took several extra seconds to boot. With the settings turned off it booted quickly.
Or maybe its something entirely different from any of this. But the program is working now.
Thanks.
I am using Delphi 7.
TOpenDialog.Execute hangs the program if launched from the standalone
EXE.
When the project is executed from Delphi 7 it does not hang.
It does not matter what I add, even a blank project with a button
that has OpenDialog1.Execute on it will cause the hang when clicked.
This problem is recent. Projects compiled before a while ago do not have the hang.
I used the same Windows installation (Windows 7 Ultimate 64bit) and
the same Delphi 7 for years now.
Projects compiled before a while ago do not have the hang.
Projects from Delphi 7 that are complied in Delphi 10 will also cause the hang.
It does not happen in CLX applications, whether in debug or standalone.
Here's an example of what seems to be causing the hang:
procedure TForm1.Button1Click(Sender: TObject);
begin
OpenDialog1.Execute;
end;
Update:
Cause might be "InitialDir" being the Desktop. If it's set to c:\ for example, it won't happen.
Another thing to look at is Project -> Options -> Compiler Messages (are there any unchecked?) If so, those are exceptions begin ignored by the IDE's built-in debugger. Check them, and run, then you might see what is causing the hang-up.
The only time I have been able to produce this is when I have a network share that is sluggish or not there... during the IDE debugger it timesout and keeps going, however, standalone it will eventually timeout, but, much longer.
(Most likely it is something in your Project -> Options screen). As I do strange things that most people never do :-) (sshfs for example will cause this).
I once had this problem in some of my application if i wanted to access network shares. By including the compiler switch
{$SetPEOptFlags IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE}
I could get rid of the problem. See also this blogpost. But be aware, that this switch has some restrictions.
As Microsoft mentions, "The /TSAWARE option is enabled by default for Windows 2000 and later, for Windows and console applications", meaning every .NET application has this switch turned on by default.
I'm using PCSCConnector from http://nobbi.com, last update - April 2004.
All work fine with Windows XP but with Windows 7 there has been some trouble.
When I press CTRL+F2 in the Delphi IDE (terminate) and a card connection had been opened by my software then any software (including my own) can't open a new connection to the card. I need to physically reconnect the card (USB in my case) to be able to create new connections to it.
I try to change dwScope in SCardEstablishContext to SCARD_SCOPE_SYSTEM (from SCARD_SCOPE_USER) and dwDisposition in SCardDisconnect to SCARD_LEAVE_CARD (from SCARD_RESET_CARD) but the problem persists.
When you use Ctrl+F2, it's a forceful termination. No code gets a chance to properly clean up, close things, or free anything - it's just shut down. No changes you make to the library's exit code is going to help, because it never gets a chance to run. You've stopped that from happening by forcefully terminating the app.
The solution: Don't use Ctrl+F2 for anything except runaway code you can't stop any other way. Close down your application normally the way it's supposed to be closed down, so it has a chance to clean things up and call finalization code and so forth.
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.
Ok, I'm going nuts here. For the last (almost) four years, I've been putting up with some extremely bad behavior from my Delphi 5 IDE. Problems include:
Seemingly random errors in coride50.bpl
floating point errors on compiling
occasional deletions of my source code files
form and object sizes shifting between instances of working on them
Loss of links between files on compile: messages that it can't find a function even though it is explicitly referenced
The linker frequently fails to include valid .DFM files unless a full build is performed instead of a smaller compile
The biggest problem is that my boss isn't believing that this is happening without any user changes making these issues appear. I've already wiped and reloaded Delphi fresh a couple of times, but that is not something I can do again right now. Most of the issues listed can be easily recovered from (either reload the IDE or re-copy the files out of source control), but this is completely nuts. I've eliminated all the warnings and hints from compile time, haven't covered them up. I've done my best to follow Marco and Microsoft's best practices. Is this just me? Am I the crazy one? How can I stop Delphi from causing these headaches anymore?
Pretty sure it is a bad package. If you can come up with steps that fail repeatedly (which I know is tough) then try removing 3rd party (or home grown) packages 1 at a time until it is fixed. Then you at least know which package us causing the trouble.
Once you know what the troublesome package is, you can actually debug the design time code & behavior of the component in Delphi. Just set the Delphi exe as the debug application, and then Delphi will launch another instance of Delphi in debug mode. Reproduce the steps that cause the failure, and hopefully you will get a good idea of what code in the package is causing the problem.
Good luck!
I have never seen any version of Delphi delete files under any circumstances.
Do you have any IDE plug-ins installed? This would be my first guess.
I've never heard of behavior like this from Delphi before. A couple of things to look at:
Are you sure the memory on your machine is good? Have you run Memtest on it?? The last couple of times I've encountered crazy behavior from a machine the culprit turned out to be the memory.
Beyond that, remember that anything you install into Delphi runs in the context of the IDE and if it's buggy it can mess up the IDE. Even a component that writes to a wild pointer could do this to you.
i used d5 for a long time & never saw that. i had some other strange things like you mention about needing to build rather than just compile. i have that in d2009 as well.
Just a thought; pikcing up one of your comments about you having D5 and D7 installed, I'd suggest;
uninstall D7
uninstall D5
reinstall D5
install D5 3rd party components
service pack D5
reinstall D7
install D7 3rd party components
service pack D7
then try again, having done the trick of deleting all the .DCUs in your own project directories.
In my experience I've always been careful to stick to installing them 'in numerical order' and if one needs to be removed, I usually end up removing them all before I start reinstalling.
GExperts ToDo list window... close it or any other GExperts Windows.. Watch the Task Manager for memory increasing and then stopping after you close any windows.
Pretty much out of Delphi 5.0 these days. But I do recall it was important to have the latest Build for various reasons. Do you have it?? Go Help->About. I believe this is the latest version:
Version 5.0 (Build 6.18) Update Pack 1
Which OS are you using? If it's Windows 7, perhaps there are incompatibilities with Delphi 5, since it's a bit long in the tooth now. Perhaps you could try running Delphi 5 in a XP VM.
Since you had no problems with Delphi 7, is there any reason for not migrating this application to Delphi 7? It shouldn't be difficult to do, unless you have some third party components with no source.