Leaderboard

my advice: create a new app with just form and deploy it to test! if run, then, pay attention in your "real" app with all calls done on "create/run" app! note: I dont use IOS/macOS - I dont have it!

Mine shows 28.0.46481.1287.

If there's anything you take away from this discussion, it should be that understanding Properties (with their getter and setter methods) is helpful, but when you get into discussions involving passing data in and out of Forms, it usually turns into something more akin to a religious debate. There are lots of common practices that apply to interacting with classes, starting with the basic principles of "objects" which are: encapsulation, inheritance, and polymorphism. The whole point of classes is twofold: (1) model behavior; and (2) maintain state. In most GUI-based apps, a form's behavior is going to vary with how it's used: maybe to simply display a message; get an input value; display and/or edit some data; and more complex forms that combine several of these. However, there are several ways to get and set the state (field values) inside of that form class. Worse, the way people employ these methods is very inconsistent, which can be observed by looking at a lot of different code written by may different people. Properties are properties, and Dalija did a great job explaining them. The "why" part wasn't really addressed: it's because properties afford the programmer some latitude in terms of 'encapsulation'. For instance, you put 'i' and 's' in front of some property names to clue the programmer into how they're used (handy if you're not using an IDE that already ensures the types match up). The point here is, right now you might have implemented those as one type that makes sense today; but in a month or a year down the road, it might make sense to change those types or where the values are stored. And that's where Getters come in -- they enforce the promise that the property is whatever type you say it is, regardless of how it occurs inside the class. So an integer could change to a string, or vice versa, because of some other change. If you accessed that variable directly by name, and its type changed, that could have incredibly wide-ranging repercussions on the rest of the application. But by using a property that says CustomerNum (with or without an 'i' in front) is always an Integer, you don't have to worry about whether the underlying variable changes to a string or a field in some other record or object -- references to CustomerNum will always refer to an integer. Even if you replace it with a DB query. As for Setters, they have a totally different set of uses that can be equally important. Their main use is to ensure the integrity of the internal state of the object. If the state of a given variable can only have three distinct values, you'd use a Setter to make sure it isn't assigned something else, which can cause problems for the behavior of the entire object later on. So the Setter can act as a sort of "door bouncer" to keep disreputable characters out of the club, so to speak. That's the "why" part in a nutshell. Here's where we get into what's behind the religious debate part... In Delphi, a "form" is a TForm which is a class derived from something in the VCL that's intended to act as a container for visual components -- hence VCL = Visual Component Library. When you create a 'class' in Delphi, it inherits from TObject and it's pretty much a blank slate. You get to define what's in it and how its clients are supposed to use it. When you create a 'form' in Delphi, it's actually a TForm, a class in itself, and it's FAR from a blank slate. It's part of a complex inheritance tree and it acts as a container for VCL components that depend on things present in the TForm inheritancy hierarchy. This imposes a bunch of fixed rules as well as guidelines to follow, some of which are required and some optional. How you get data into and out of a form should be guided by how you do that with any other class. However, in practice, people tend to not follow those rules very much. And you can tell from all of the back-and-forth between different folks here that some hold rather strong opinions about what to do and not do. I did a presentation for CodeRage 9 where I discussed this very topic in some detail, entitled "Have You Embraced Your Inner Software Plumber Yet?" The essence of this presentation is that getting data in and out of forms is more aligned with the whole domain of Dependency Injection than anything else. Unfortunately, when people hear that term, they tend to think of Unit Testing, not managing the lifetime of forms in their apps, including Dephi's forms. There are three types of DI for classes: (1) constructor injection; (2) property injection; and (3) setter/getter injection. People have described all of these earlier in the thread. Neither of them is "best", although some are better for certain situations and needs than others. Complicating things, the data they represent can be input only, output only, and bi-directional. So the DI part needs to account for this dynamic as well. (FYI: a DI framework / Service Locator lets you save and lookup different instances of things is a totally different and unrelated discussion. It would have been nice if the original developers built Delphi's form management on top of a DI framework, as that would have codified how to get data in and out of forms consistently, but ... they didn't go that way. I've seen it done in large applications, and it simplifies the hell out of things because the way you interface with every form is the same. It's quite refreshing to see!) And in my talk, I don't even address the situation where the form is interacting with a database maintained implicitly in another unit than the one that's dealing with it. This is the situation where you say, "Open this form to edit the current record in some DB based on whatever the user is doing right now." It's extremely common, and takes very little effort on your part because the form is simply mirroring both data and state being managed by some database components that probably live on a Data Module elsewhere. You just call Create and ShowModal and everything else is handled automatically. A guy named Mark Seemann has written a lot on this topic; he has a blog, has written some books, and gives talks on the subject. He has written a book, Dependency Injection for .NET that's quite popular, and while the code is focused on .NET, the principles apply equally well to Dephi. He seems to have co-authored a newer version of it recently that I haven't seen but is probably worth checking out. There's also the book Dependency Injection in Delphi by Nick Hodges. You can use Mark's book to learn the principles and Nick's book to see a lot of the examples in Delphi. I don't think Nick intended that, but it just shows how universal these patterns are. (It looks like all of Nick's books are on sale at Amazon right now.)

Last patch - 4 oct. November nothing.

Hi, You need to give the type of the enumeration, use Edit1->TextSettings->HorzAlign =TTextAlign.Leading Edit1.TextSettings.HorzAlign :=TTextAlign.Leading It's only some ways to change. I use Delphi from D3 version, my new applications are all FMX, it took me 1-2 years to take the plunge, but now I much prefer FMX

TThread internally checks its Terminated property before calling Execute(). When you destroy a TThread that hasn't finished yet, the TThread destructor calls Terminate() and WaitFor() on itself. So, if you destroy a TThread before it even begins running, Execute() won't be called. That is nothing new, TThread has behaved this way for many years.

@David Schwartz would be some like this: of couse, you will needs create your "class" to better usage this. Look that it's not necessary hack any class. For FMX you can do it with same idea ( I think that is more easy than VCL) NOTE: all panels is aligned on "TOP" {$R *.dfm} var LFormHeight: integer = 0; function MyGetAllChildsHeight(const AControl: TWinControl): integer; begin result := 0; // for var i: integer := 0 to (AControl.ControlCount - 1) do if (AControl.Controls is TPanel) then result := result + TPanel(AControl.Controls).Height; end; procedure MyReSizeAllChilds(const AControl: TWinControl; const APerc: integer); begin for var i: integer := 0 to (AControl.ControlCount - 1) do if (AControl.Controls is TPanel) and (TPanel(AControl.Controls).ShowCaption) then begin AControl.Controls.Height := Trunc(AControl.Controls.Tag * (APerc / 100)); // <---- // for test... TPanel(AControl.Controls).Caption := AControl.Controls.Height.ToString; end; end; procedure TForm1.FormCreate(Sender: TObject); begin // I'm using "Panel2.ShowCaption" just for test [resize it or not in "MyReSizeAllChilds()"] // you'll should have a property for this usage in special!!! // LFormHeight := Self.Height; // ******************************************* preparing childs setup: // *********** panel 1 Panel1.Tag := Panel1.Height; // <--- Panel1.ShowCaption := false; // Edit1.Anchors := [akLeft, akTop, akBottom]; Edit1.Constraints.MinHeight := Edit1.Height; Edit1.Constraints.MaxHeight := Edit1.Height; // ComboBox1.Anchors := [akLeft, akTop, akBottom]; ComboBox1.Constraints.MinHeight := ComboBox1.Height; ComboBox1.Constraints.MaxHeight := ComboBox1.Height; // ListBox1.Anchors := [akLeft, akTop, akBottom]; ListBox1.Constraints.MinHeight := ListBox1.Height; ListBox1.Constraints.MaxHeight := ListBox1.Height; // Memo1.Align := alRight; // // *********** panel 2 Panel2.Tag := Panel2.Height; // <--- Panel2.ShowCaption := true; Panel2.Constraints.MinHeight := 150; // Edit2.Anchors := [akLeft, akTop, akBottom]; Edit2.Constraints.MinHeight := Edit2.Height; Edit2.Constraints.MaxHeight := Edit2.Height; // ComboBox2.Anchors := [akLeft, akTop, akBottom]; ComboBox2.Constraints.MinHeight := ComboBox2.Height; ComboBox2.Constraints.MaxHeight := ComboBox2.Height; // ListBox2.Anchors := [akLeft, akTop, akBottom]; ListBox2.Constraints.MinHeight := ListBox2.Height; // Memo2.Anchors := [akLeft, akTop, akBottom]; Memo2.Constraints.MinHeight := 160; // Self.Constraints.MinHeight := 450; // MyGetAllChildsHeight(Self); end; procedure TForm1.FormResize(Sender: TObject); var LPerc : integer; begin // ******************************************* all logic is here! no needs hack any class // Needs verify: // (n div 0 ) = exception!!! // If "LPerc value it's ok for usage on Height's" // LPerc := Trunc((LFormHeight / Self.Height) * 100); // if (LPerc > 100) then { form is shrinking in size... } LPerc := (100 - (LPerc mod 100)) else if (LPerc < 100) then { ...now it's growing } LPerc := (100 + (100 - LPerc)) else LPerc := 100; // MyReSizeAllChilds(Self, LPerc); end;

Deleted post to avoid showing my ignorance . (I confused static linking with static binding.)

No, I mean that linking C++ static libraries is exceptionally hard, because where do you get the runtime support from? No. It calls the standard Delphi MM. Also, there's no concept of freeing heap memory directly. That makes no sense. You always have to free from the same heap that was used to allocate.

I think David meant it's NOT exceptionally hard. However, you can't export C++ classes in your DLL. You must use simple structures (records) as parameters in your exported functions, ie structures that can be understood by other languages. The other thing to watch our for is memory management because structures created by DLL functions (ie heap allocoated memory) can't be freed using Delphi's memory manager. Here is an example in my Polygon Clipping library and the C++ export header. Edit: And of course Delphi routinely links to numerous operating system DLLs that would have been written in C and C++. Edit2: I haven't properly researched this but it looks like Delphi's FreeMemory function bypasses Delphi's memory manager and frees heap memory directly. So FreeMemory could probably be used to free structures created by (C++) DLLs. Nevertheless, IMHO, all DLLs that create heap allocated structures - ie any structure returned as a pointer - should also export functions to destroy these structures. Edit: The OP was asking about static linked libraries, and my reply was about dynamic libraries. Sorry.

Yes it's exceptionally hard. Just put the code in a DLL.