Arquivo da tag: Delphi
Delphi XE2 changes DFM even though nothing has been changed
This is just a consequence of how Delphi’s form streaming mechanism works.
When you open a form in the Delphi designer, the .dfm file is used to create instances of each component on the form. In your case, the form designer will instantiate each of the objects in the .dfm file. Each property in the .dfm file will be read in.
Then, if you do anything in the designer that marks the form as having been modified, for example changing the active tabsheet, then the designer will re-create the .dfm file when you save. And it re-creates the .dfm file by asking the in-memory components to save themselves. This saving process makes no account of what the .dfm file on disk looks like. Each component just saves its properties as they are at that point in time.
So, in summary, there’s really nothing you can do to change Delphi’s behaviour. The best you can do is to work around it to minimise the impact.
If your forms have Scaled=True then you should make sure that all developer machines use the same font scaling. Otherwise when developer A saves at one font scaling, that .dfm file will be completely different from the one that developer B saves at a different font scaling. All positions will be altered. It sounds as though you have some developers that use 120dpi font scaling. And that’s going to give you no end of grief.
If benign edits to the form file result in large changes, commit those changes. Once you have every developer machine configured the same way, you’ll find things settle down. Those benign edits should no longer result in .dfm file changes.
This is just one of the occupational hazards of visual design with Delphi. You need to pay lots of care and attention to your .dfm files whenever you commit. I regularly find myself reverting changes to .dfm files from the Tortoise commit dialog. I also often elect to modify the .dfm file in a text editor rather than using the form designer!
Cursos AlbertEije
Delphi – System Error. Code: 8. Not enough storage is available to process this command
If your program uses a lot of windows resources it could be a Resource Heap shortage.
There is a registry entry that can be increased to raise the heap size for XP. For Vista Microsoft already sets the default value higher. I recommend changing the default 3072 to at least 8192.
This information is documented in the MS Knowledge Base (or search for “Out of Memory”). Additional details concerning the parameter values may be found in article KB184802.
I suggest you read the knowledgebase article but the basic info on the change is:
- Run Registry Editor (REGEDT32.EXE).
- From the HKEY_ LOCAL_MACHINE subtree, go to the following key:
\System\CurrentControlSet\Control\Session Manager\SubSystem - On the right hand side of the screen double-click on the key:
windows - On the pop-up window you will see a very long field selected. Move the cursor near the beginning of the string looking for this (values may vary):
SharedSection=1024,3072,512 - SharedSection specifies the System and desktop heaps using the following format:
SharedSection=xxxx,yyyy,zzzwherexxxxdefines the maximum size of the system-wide heap (in kilobytes),yyyydefines the size of the per desktop heap, andzzzdefines the size of the desktop heap for a “non-interactive” window station. - Change ONLY the
yyyyvalue to 8192 (or larger) and press OK. - Exit the Registry Editor and reboot the PC for the change to take effect.
Aprendendo Delphi 6 & Kylix
Nota do livro: 3.