- #Delphi xe findinfiles update#
- #Delphi xe findinfiles code#
LiveBinding is easy, we will first present 3 tutorial examples : To make sure that readers casually looking at the article understand that However, knowing what's under the hood, especially given the current state of the documentation, could not hurt too much. Daily use of LiveBindings is quite simple and straightforward. In this article, we will explore the architecture of LiveBindings using the simplest possible binding.īut before starting the deep dive, let us stress that going this deep into the innards of LiveBindings is not at all required in order to implement LiveBindings in your applications. Management, since no db_xxx are available : linking any FireMonkey visual control to a Database using LiveBinding is possible. And for Firemonkey it is at the heart of the database visual For the Vcl, it allows us to bind tWinControls for which no db_xxx data sensitive controls were provided.
hardware used : Pentium 2.800Mhz, 512 M memory, 140 G hard discġ - Delphi LiveBindings Livebindings are the new data binding technique which allows us to link objects to each other using String expressions.ĭelphi LiveBindings is available for both the Vcl and FireMonkey. #Delphi xe findinfiles update#
software used : Windows XP Home, Delphi XE2, update 1 installed. TBindingOutput, tCompiledBinding - Interface to Object conversion key words : tBindingExpression, iScope, iValue, tNestedScope,. #Delphi xe findinfiles code#
Dump of the pseudo code and UML Class Diagram of the LiveBinding architecture
abstract : analysis of the architecture of the Delphi LiveBindings : how the tBindingExpression compiles a String expression to build an environment referencing objects which can be evaluated to fill component. (5) As (4), using a RTTI-Stripped RTL/VCL.Delphi LiveBindings Spelunking - Felix John COLIBRI. (4) Compiled with Delphi XE, replaced unit "Oleserver" with a dummy unit so no unnecessary VCL code is pulled in. (3) As (2), using a RTTI-Stripped RTL/VCL. (2) As (1), replaced unit "Oleserver" with a dummy unit so no unnecessary VCL code is pulled in. That RTTI stripping is much easier to achieve with XE because the in the DPR. I use a RTTI-stripped version of the XE libraries since ages, because when I migrated from Delphi 2009 to XE my executable sizes also grew a lot. This cannot be because XE already had extended RTTI. I wonder what Cantu, Millington or Arefiev can publicly say about this case. Why they polluted the code only to be used in the IDE? Most probably it could be moved in some package used only by the IDE and not pollute user executables. I've no idea where is this used as find in files returns that RegGroups is only used in System.Classes so my guess is that it is for the IDE. As I scanned the code most probably only the initialization section requires the VCL.Controls and for this one: I think is a poorly engineered code for the IDE. For example, projects like "inno setup" might benefit from it. I am in the process of writing a tool to automate the "rtti stripping" of the RTL/VCL which I plan to release as open source. With these executable size reductions I am finally able to port this project to Delphi Sydney. My DLL's have now typically lost 80% of their size, going from 2MB+ to only 400kb. When I link my projects against a "stripped" version of the RTL/VCL (recompiled without extended RTTI), the size difference becomes astronomic. So it seems to me that this whole OleServer unit is an unnecessary thing in my projects.Īnother thing. And the best thing, the project still worked as expected. The project compiled fine, and this change alone instantly reduced executable size with a whopping 1 MB. No code in the unit itself is called, but the initialization section manages to pull in most of the VCL for whatever reason.Īs a test, I made a dummy unit "oleserver.pas" and referenced it as the first file in my COM DLL applications. I am absolutely sure that I don't use these routines anywhere and still they make up over 60% of the executable's code! The underlying cause is that all of the xxxx_TLB.PAS files, which the IDE auto-generates, use a unit called OleServer which has an initialization section. I noticed that all of my non-visual COM DLL's nevertheless pull in huge chunks of the visual VCL, including units VCL.Forms, VCL.Themes, VCL.Imagelist etc. 
Trying to strip off some MB's wherever I could, I started studying the MAP files to make sure no unnecessary stuff was linked in. The project was already huge before, and a doubling or tripling in size would cause deployment problems (the software is used on oil wells on remote locations and bandwidth is often costly and slow). Most of that growth, of course, is due to the new extended RTTI (which I do not use).
Each and every DLL in my project group had grown between 1-4 megabytes and that really added up painfully. In my quest to port a very large project -containing dozens of COM DLL's- from Delphi XE to Sydney, the main obstacle for me was the exploding executable size.
0 kommentar(er)
