Leaderboard

You are of course correct. Thanks. I should've looked and thought harder before posting.

The form streaming process relies on run-time type information (the old styele), and that is only generated for published members of a class.

Actually, the component will be created at runtime even if its associated field is private, or indeed not existent. What happens is that the streaming framework creates the component, assigns it properties, but is unable to field a field into which to store the reference to the component.

This information is documented http://docwiki.embarcadero.com/RADStudio/Rio/en/Delphi_Compiler_Directives_(List)_Index

Did you try this? {$IFOPT C+}

I was trying to find an updated reference for this but it goes something like this... TComponent and all its derivatives (components on forms) are designed to be loaded and save to the DFM files, in binary format or text. The IDE uses this when you visually design a form and places all event handlers and component references in the top of a class which is a published scope. These contain RTTI information for the loading and saving mechanisms. When you run your application the same streaming mechanisms are used to load your forms from the DFM which are resources within your EXE. If you've moved the declarations to another scope other than published then they cannot be loaded either by the IDE or by your application at run-time.

I filed a feature request for a new sort option to normalize the code while sorting.

No, GExperts can't (because nobody answered that question yet).

AFAIK, that won't work. As an alternative you can use the built in Delphi code format feature with <Ctrl>-D.

If you use MMX, with right margin sent to some high value, then edit the routine: Ctrl-E, Enter, the result will be to put the signature all on one line. It will do so in both the interface and implementation sections, in one action.

Guys, are all of you missing this? Due to the Pascal calling convention, the first (plain!) argument of a function maps into the same register(s), so in fact this is valid and correct code. Though strictly I agree it looks weird and like as if in 'normal' cases the Value members aren't assigned to Result members. Bit in fact, they're already there! So what is actually needed is a 'type size limiting' cast, which is exactly what Result.x:=SmallInt(Result.x); is.