if you compile a program in D2010 a manifest .res file is automatically generated. is it included in your program by default? or you have to include it yourself?if yes what level of privilage is given to you? my program modifies a registery key would it be able to do so with out any modifications to .res file?if no what modifications i need to do?
a side question: is there a component/expert(prefably free) that can generate/include .res file in my delphi 7 and delphi 2007 projects automatically just like delphi 2010?
edit: forgot to mention i do not have win7 or vista nor have i ever used them
edit2:i have included a manifest file just in case following this tutorial but the tutorial only talks about windows vista and not 7 would the .xml(manifest) file in this tutorial make my app capable of dealing with win7 UAC too
edit3 if i include my own manifest file and delphi is including it by default as well that will make 2 manifest files(1 with admin previlages and 2nd without) would this cause any problems/unpredictable behaviour
The manifest generated by delphi gives your process the lowest privileges (that is the default by the way).
You have to modify the manifest file in order for it to ASK for permission to be run under administrative rights (Called elevation).
Your application with the standard privileges should read/write to HKEY_CURRENT_USER without elevation.
Accessing %programfiles% and HKEY_LOCAL_MACHINE requires elevation. (Not so sure about the other registry hives)
This is a PDF that will help you A LOT with what you're up to.
http://pascalfonteneau.developpez.com/articles/delphi/vista/uac/VistaUACandDelphi.pdf
Related
Delphi IDE uses InstallAware as installer in last few releases (2010, XE, XE2, XE3, XE4). Using the normal setup.exe installation will copy a few GB of files into c:\programdata if you install all the IDE releases.
The installer consumes disk spaces quickly especially for users who use an SSD hard disk that is expensive.
Is it possible to setup the Delphi IDEs without copying files to c:\ProgramData? Is it advisable to delete those files manually after installation too? Uninstalling a previous version of the IDE does delete these files but as component maker, I need those IDEs for testing.
Partial answer here.
Is it advisable to delete those files manually after installation too?
Of course, official answer is NO. But you actually can delete these files at the cost of losing installer's "Repair" capability. (Repair is standard MSI feature, and InstallAway is merely yet another front-end for MSI). Also, it will render any manual restoration of particular file impossible, since files are stored in encrypted 7-zip archives on distribution medium (yet another unfriendly feature).
Unfortunately, I do not know any way to disable creation of such local copy of distribution medium.
I use FastMM4 in my Delphi 6 applications. Do I need to ship the include file (FastMM4Options.inc) with the installation files I create to install my app on a users PC? If so, should I put it in the same directory that I place the main EXE file?
I'm referring to the FastMM include file that controls the settings for FastMM at run-time. Currently this file is in a directory that is accessible via the Library Path specified in my Delphi IDE Environment options, but I never considered to include it with my installation program(s).
FastMM4Options.inc is an include file; it's source code. It doesn't affect anything at runtime; it affects how FastMM is configured at compile-time. So no, there's no need to ship it to anyone.
I've taken over a legacy application and I have the exe created. If I can configure the BDE then in theory it should be possible to run this. Someone indicated that Delphi needs to be installed in order for the app to run. I'm unsure of that - it doesn't quite make sense to me as there is an exe file. Any input from Delphi experts would be appreciated.
Roddy
If the application uses the BDE then the BDE has to be installed before the exe can run. The BDE files are not linked into the exe.
A Delphi installation normally also installs the BDE. This might give the impression that Delphi has to be installed to run the exe, but that is not true.
According to the deployment licence you have to use something like InstallShield Express that comes with Delphi to create some setup for the BDE, but I might be mislead here. You may even try to google for a BDE installer or have a look at this question.
Your application should work without installting Delphi if it wasn't built to use runtime packages(BPL files).
If it was built to use runtime packages, you'll need to deploy them with your application. Since all delphi's runtime package are installed with Delphi, that may give the impression that installing delphi is required for the application to run, which is not the case.
You might however need to install delphi to retrieve the required BPL files.
BPL files are special DLL files that delphi can refers to instead of linking all code into the .Exe, making EXE files much smaller.
So if you manage to get the BDE up, create the right aliases in it, and get all required BPL(if any), the application should start up correctly.
1 last thing that might need to be deployed with your application is midas.dll. (If the application use, for exemple, Tclientdataset)
That's all I can think of for now...
It seems very awkward to me that Delphi needs to be installed to run your application. Maybe your application is build with runtime packages which means you have to include the bpl's the application depends on, but Delphi itself should not be needed.
You can test this yourself, just run the app on a computer without Delphi installed. When it gives an error about a bpl not found, you have to find that bpl and add it to the directory where your application is located.
Uwe has the answer here. if your application uses any of the data components provided by Delphi it will almost always require the BDE to be installed and other drivers if for example you are talking to Oracle then the Oracle OCI drivers must be installed.
You do not need Delphi to install the BDE but you need to find the BDE installer and have it installed. MANY programs out there use the BDE and not just Delphi since it was licensed by many companies.
Every Delphi 7 developer knows that if he compile a application on Delphi 7, the style will be as Windows 2000 applications, but there is any method to make this better as the application can have the default theme of the Windows version, as C++ and C# applications?
Try adding the TXPManifest component to the main form of your application. located in the Win32 Tab.
The TXPManifest component has no methods or properties. All it does is include the XPMan unit in your project. This in turn causes a certain resource file to be included in your project's executable file. The resource includes a manifest - a small piece of XML that contains information about the application you are writing as well as information concerning the version of the comctl32.dll to use.
Alternatively add your own manifest resource manually - which allows you to tap into the even newer Windows 7 features, if you can be bothered to fathom out the syntax. See this link for more info but ignore the bit about enabling runtime themes as this doesn't exist in D7 (I don't think).
I have a Delphi .CPL currently written with Delphi 7 which needs to update settings in HKLM (to be used by a service application) and which must support Vista, Win7 and Server 2008. Currently this can be done by adding a RUNASADMIN value to AppCompatFlags/Layers, using the CPL file as the value name. This causes Windows to ask for elevation for a 'legacy control panel applet'.
I need to find a way to build the CPL in Delphi 2010 without it appearing to be 'legacy' and, if possible, not to require the registry setting or elevation. Adding the usual manifest resource to the DLL/CPL referencing Common-Controls v6 and "requireAdministrator" does not fix the problem: no elevation is requested and HKLM access fails. Both the original and the Delphi 2010 .CPL can be made to run correctly (after elevation) by navigating to the file in SYSWOW64, right-clicking, and running 'as Administrator'.
Later: I have found a succint explanation of why you cannot elevate a DLL in this way in a forum posting here.
I believe you need to use COM elevation. There was a wonderful blog posting on this which appears to have been taken down, but the source code behind the posting is still available on the VCL components website (way back machine link).
Some additional information can be found in the question/answers for: Delphi: Prompt for UAC elevation when needed
I think I have found a better answer to my question. There is such an animal as a 'non-legacy' control panel applet, which is described in MSDN here. "Now, in Windows Vista, you can add your own applet to Control Panel by creating an executable for your applet and registering it, instead of going through the trouble of creating a .cpl file."