Is there a way to force a Delphi application to always start on a particular desktop in Windows 10? I'm using multiple desktops, and sometimes switch between them when waiting for the application to compile. This has the effect that when it's finished compiling, the application is launched on the currently active desktop, i.e. not necessarily the "main" one where the IDE is placed.
It would be nice if there was a way to force Delphi to always use the main desktop when launching applications. Or if that's not possible in the IDE, could I at least force the application itself to always use the main desktop?
Note that I'm not talking about multiple monitors, but multiple Windows 10 Desktops.
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 pro and debugging an older ISAPI app with IIS 7.5 (Windows 7).
Everything works fine except that if I place my cursor over a property to see the current value, sometimes Delphi will just display "evaluating" and hang - the only thing I can do at this point is reset the program.
Does anyone know if there is a setting I can adjust to prevent this hanging?
Check these settings:
Is the ISAPI dll running in a separate dedicated Application Pool?
Is "Maximum Worker Processes" set to 1?
Is the "Identity" set to a normal user, preferably your own account or the account you run the Delphi debugger with?
(If the ISAPI dll is 32-bit running on a 64-bit server: Is "Enable 32-bits applications" set to "True"?)
Are limits, timeouts and intervals set high enough or disabled so IIS won't try to recycle the worker process while you're debugging.
With Windows 7/8, this very nice ole2 interface IWebBrowserDisp is no more working properly, for some reason it now opens the IExplorer Window behind the actual currently running delphi application, not to the front of the screen as it used to be work earlier.
This makes the application to fail as user cannot see the opening web page without manually switching to Iexplorer and locating the correct window.
The code that I use to launch the link is:
WB : TEmbeddedWB;
wb.Navigate(URL,x,x,x,x);
This problem does not exist in older Windows or while I use my Delphi IDE ( I use Delphi4 and run it as ADMIN).
I have an exe file compiled with Delphi 6 under Windows XP that uses a combination of EnumWindows and GetWindowText to find a window (not belonging to the exe itself) with a specific title.
The behaviour is as expected under Windows XP. On Vista computers however, it doesn't seem to work.
As the mentioned Delphi version doesn't run on Vista, I cannot change and test this directly.
However, I will try to create a modified exe on the XP computer that outputs some additional data and copy it to the Vista computer.
I would just like to ask whether anybody has any information whether there are specific problems known with exe files compiled with Delphi 6 running on Vista regarding EnumWindows/GetWindowText.
The exe uses EnumWindows and GetWindowText to find the handle of a certain window in order to then parse the title of that window in a timer event. The window title is the application name plus the name of the file opened in that application (if any file is opened). The Delphi exe analyses/uses this file name, does something with it and behaves in a certain way.
On Vista the expected behaviour does not appear, thus I presume that the window handle is not found cause GetWindowText does somehow not return the text. Another reason of course could be that EnumWindows does not work properly and the window handle of the window that the exe is looking for is never send to the EnumWindowsProc.
Assuming that there has been no change in window title from XP to Vista, there's not much that can go wrong here. I'd hazard a guess that the problem is due to UIPI. This is part of the security enhancements of Vista and it means that processes can only send messages to other processes that have equal or lower integrity level. Is this other process running elevated?
Other than that your best bet is to run this under the debugger. Delphi 6 most certainly does run on Vista. It was written before UAC and so doesn't get on well with having no rights to write to its install directory. So, install it to somewhere in your user profile or C:\Delphi6 – basically anywhere that standard users have write access.
Finally, don't fall into the trap of running Delphi elevated. This will confound the UIPI issue if indeed that is an issue here.
Good luck!
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.