Perhaps it is necessary to clarify some of the features of writing code for MCK. Unlike "direct" programming in KOL, in MCK a form holder object is created for the form, produced directly from TObj (you can do the same with manual KOL programming, but this is entirely at the discretion of the programmer). This object is "parallel" to the VCL form, but is not a visual object. The form itself (as an instance of an object of the PControl type) is represented in it by the Form field. That is, for example, if a TForm1 form was created in your VCL project, an object of the TForm1 type with the PForm1 pointer type is created in the MCK project "at the same place". Those. here it is seen by the compiler. And all the components thrown onto the form during development, including the form itself (mirrored to the non-visual TKOLForm component lying on the form),

 

Note. In fact, the commonplace banality of this description of the use of the word Form hides truly fantastic phenomena. For example, if you write the code proposed in the next paragraph in the OnFormCreate handler, then at the very moment when you type it from the keyboard, you may find that Code Completion, i.e. automatic code completion system, perfectly "sees" the Form variable. And you can go to the declaration of this field in the field structure of the "former VCL-form" (ctrl + click). The great thing is that this variable is "visible" at the same time as the code is being written, to the compiler when the code is compiled, and to the debugger when stepping through it. Probably should have applied for a patent ... but now it's too late. *

 

The conclusion from the above is the following. The difference between writing code for VCL and for KOL + MCK is that in order to access a property, method or event of the form itself in KOL, you must use Self.Form instead of Self. For example, to change the title of a form in the OnFormCreate event handler, the code should be like this:

 

Form.Caption: = 'new caption';