delphi-2009

问题 The application I am now trying to support (a former creation of mine) is a complete mess, and so I programmed an extension to it as a separate executable which I then launch, call application.minimize; and WaitForSingleObject (the recently created process). Right after that I call application.restore to get me back to where I left off. application.Minimize; WaitForSingleObject(ProcInfo.hProcess, INFINITE); Application.Restore; Application.BringToFront; BringToFront; //the topmost form which

问题 Is there any way to determine the size in bytes of something like TItem <T> = record Data : T; end; Can I write something like function TItem <T>.GetByteSize : Integer; begin if (T = String) then Result := GetStringByteSize (Data as String) else Result := SizeOf (Data); end; or perhaps with the help of specialization? function TItem <String>.GetByteSize : Integer; begin Result := GetStringByteSize (Data) end; function TItem <T>.GetByteSize : Integer; begin Result := SizeOf (Data); end; Thanks

问题 I am in the process of porting a Delphi 2006 app to Delphi 2009. Out of the box support for unicode has been easy - almost no work required. Most 3rd party controls already have Delphi 2009 updates available. Rave Reports (latest version 7.6.1, available here) has also been updated, but I cannot seem to get it to correctly display RTF text containing Japanese characters. In Delphi 2006, I loaded RTF to the DataMemo component in a RVCustomConnection's OnGetRow event by reading the RTF from a

问题 For static code analysis tools, it is necessary to know all effective source paths for a given Delphi project, which are defined on project level and in the global IDE configuration. Is there a Delphi library which can collect this kind of project information? As far as I know, the registry settings for the Delphi IDE can be in different places, to support multiple configurations. But for a given combination of the IDE registry location and a project file, it should be possible to collect the

问题 We create via "Tools | Options | Environment Variables" Variables like that: $(Sources) = D:\Sources\Delphi $(OurLib) = $(Sources)\OurLib\Src $(OurApp1) = $(Sources)\Applications\App1\3.x $(ThirdParty) = $(Sources)\ThirdPartyComponents We use these Variables in the project search path like that: ($OurApp1)\Src\Core;($OurApp1)\Src\GUI;($OurApp1)\Src\Plugins;$(ThirdParty)\JVCL But this is broken (meanwhile fixed) since Delphi 2009 as these variables are not evaluated completely anymore (see QC

问题 In the process of transforming a given efficient pointer-based hash map implementation into a generic hash map implementation, I stumbled across the following problem: I have a class representing a hash node (the hash map implementation uses a binary tree) THashNode <KEY_TYPE, VALUE_TYPE> = class public Key : KEY_TYPE; Value : VALUE_TYPE; Left : THashNode <KEY_TYPE, VALUE_TYPE>; Right : THashNode <KEY_TYPE, VALUE_TYPE>; end; In addition to that there is a function that should return a pointer

问题 Does Delphi support internationalization in any way? I've seen that I can add different languages for a project, but that seems to create multiple instances of the dfm files. Am I right that the language therefore cannot be changed at runtime? How do you handle internationalization (if you do)? Are there any best-practices? 回答1: I have once experimented with runtime change of languages. It worked great, but I needed to write lots of code myself (and circumvent the dfm files). The problem is,

问题 Does that mean that I can't share a Form between delphi 2007 and 2009? 回答1: Yes. It is not possible unless you remove the properties that are not published in Delphi 2007 from the DFM. 回答2: DoubleBuffered has been in TWinControl for some time now. The difference in Delphi 2009 is that it's published now. If you can live with only ignoring the errors (and not making the properties work instead), here is a possible solution: unit Delphi2009Form; interface uses Windows, Classes, SysUtils,

问题 I am upgrading from Delphi 7 to Delphi 2009. In an existing app, the code completion does nothing at all. If I start a new project, it works fine. Any idea what is going on? 回答1: Finally found the solution to this one, took awhile. Added "WinTypes=Windows;WinProcs=Windows;DbiTypes=BDE;DbiProcs=BDE;DbiErrs=BDE" to: Project Options -> Delphi Compiler -> Unit aliases There is a whole big reason why, but to tired to explain it. 来源： https://stackoverflow.com/questions/1169271/code-completion-not

问题 I'm producing builds using MSBuild, and build configurations set up in the dproj on the command line. It's slightly disconcerting that the size of the executables thus produced are different (not by much, but still!) to what an IDE build produces. Any ideas why? I would have thought the same compiler is used? 回答1: To see what IDE is doind, check Tools | Options | Environment Options | Compiling and Running | Show Command Line And you can check the compiler messages. 回答2: The main power of