dfm

A quick way to remove properties from .dfm files in Delphi

冷暖自知 提交于 2019-12-05 02:23:36
I have recently modified one of my components, and it so happens it is no longer using one of the properties it used before. However, those properties are written in multiple .dfm files throughout the project. Now, when i try to compile the project, i get "Error reading .: Property <...> does not exist" The complicated part is that the property value is binary data (stored in multiple lines), and i cant just delete it with Delphi replace or notepad++ regexp (since they are single-line based). So my question would be: Are there any third party tools or ways to easily remove properties from

Can we load a dfm file for a form at runtime?

匿名 (未验证) 提交于 2019-12-03 02:29:01
可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效,请关闭广告屏蔽插件后再试): 问题: Is it possible for a Delphi application to receive a dfm file with objects, its properties and event assignments, and load up all those information just like when how they do with internal dfm compiled with it? How could we do that? Is there a direct way? Note: the application will already have the code with the correct classes and methods, events included.We could also remotely receive some kind of script that could be read by my application which would create the objects necessary to match the dfm file specifications. Just like Web

Strange [number]s in Delphi DFM files - origin and necessity?

匿名 (未验证) 提交于 2019-12-03 00:46:02
可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效,请关闭广告屏蔽插件后再试): 问题: I need to change a large number of Delphi components defined in one package to similar ones in another package. Much of the grunt work can be done by replacing text (component types and properties) in the DFM files - saved as text of course. I have searched Stackoverflow and Google and am now adapting the Felix Colibri DFM parser from http://www.felix-colibri.com/papers/colibri_utilities/dfm_parser/dfm_parser.html I come across a 'feature' in the DFM files that the parser chokes on: [number]s after the type specifications like this:

Longevity of using the Delphi text DFM format for my own store and retrieve

帅比萌擦擦* 提交于 2019-11-30 20:07:31
Over time I've rolled my own formats for saving and loading object properties but on having to revisit this I'm wondering about using Delphi's own text DFM format. I know tha this is really an 'internal' format, but the reader for it now seems pretty well defined and it copes with all types of property. Has anyone any comments about possible pitfalls? I wouldn't really say that DFM is an 'internal format'. Sure Delphi uses it internally for forms and datamodules, but TReader and TWriter classes that perform streaming are publicly accessible and even documented. So they are clearly intended for

Longevity of using the Delphi text DFM format for my own store and retrieve

孤街浪徒 提交于 2019-11-30 03:29:47
问题 Over time I've rolled my own formats for saving and loading object properties but on having to revisit this I'm wondering about using Delphi's own text DFM format. I know tha this is really an 'internal' format, but the reader for it now seems pretty well defined and it copes with all types of property. Has anyone any comments about possible pitfalls? 回答1: I wouldn't really say that DFM is an 'internal format'. Sure Delphi uses it internally for forms and datamodules, but TReader and TWriter

Is there a Delphi option to 'lock' the design (layout) of a form against accidental changes?

大兔子大兔子 提交于 2019-11-29 10:20:01
After years of Delphi development I now have hundreds of forms shared throughout our Applications. Compilation ranges from Delphi 7 through to XE, thus one form might be opened in any IDE. The well-known Explicitxxx property addition after Delphi 7 has solutions to avoid a form accidentally acquiring properties that earlier compilers can't process (e.g Andreas's DDevExtensions ) but I'd like a more positive 'switch' that prevented Delphi from making or saving any form modifications at all. Period. Of course you could use the read-only flag, and a version control system provides additional

Delphi - Why does ExplicitWidth and ExplicitHeight keep appearing in .DFM files and what is it?

廉价感情. 提交于 2019-11-29 05:25:18
We've noticed that when checking in updates, our .DFM files have added ExplicitWidth and ExplicitHeight properties - but we don't know why. My questions are: What are these properties for? Why are they automatically added by Delphi? Below is an example showing the added ExplicitWidth property: object Splitter2: TcxSplitter Left = 0 Top = 292 Width = 566 Height = 8 Cursor = crVSplit HotZoneClassName = 'TcxXPTaskBarStyle' AlignSplitter = salBottom Control = BottomPanel Color = clBtnFace ExplicitWidth = 8 end From Googling.... Original article can be found here. The Explicit properties remember

Strange [number]s in Delphi DFM files - origin and necessity?

北城以北 提交于 2019-11-28 18:36:36
I need to change a large number of Delphi components defined in one package to similar ones in another package. Much of the grunt work can be done by replacing text (component types and properties) in the DFM files - saved as text of course. I have searched Stackoverflow and Google and am now adapting the Felix Colibri DFM parser from http://www.felix-colibri.com/papers/colibri_utilities/dfm_parser/dfm_parser.html I come across a 'feature' in the DFM files that the parser chokes on: [number]s after the type specifications like this: inherited DialoogEditAgenda: TDialoogEditAgenda ActiveControl