Why We Need to have Control over CodeGen

Have you ever wished that when you double clicked an event handler that the method generated by the IDE had some comments regarding the arguments passed so you didn’t have to consult the third party vendor’s help?

What about a simple TAction.OnUpdate handler, have you ever wondered why Delphi doesn’t inject the following code?

(Sender as TAction).Enabled := ^

or since it knows the component whose handler it’s creating (in this case let’s assume it’s named actTakeAction):

actTakeAction.Enabled := ^

BTW, the ^ would be the position were the cursor would be left.  The choice as to what code was generated could be a code style preference setting.

It’s this kind of polish you might expect if EMB practices dogfooding, or CANI (Constant and Never Ending Improvement) - QC97158.


5 Responses to “Why We Need to have Control over CodeGen”

  1. Chris Says:

    ‘why Delphi doesn’t inject the following code? … It’s this kind of polish you might expect if EMB practices dogfooding’

    I disagree. Your second variant is a poor one, given the same event handler can serve more than one component. More generally, your suggestion sounds very much like the ‘Live Template’ system taken to even more annoying heights - having ‘typical’ code automatically inserted when you actually want something different (if only slightly!) is a pain in the posterior.

  2. batman Says:

    I think it’s a good point perhaps an option to be able to turn it on and off for Chris, but then again I don’t understand why Delphi still have things like the TPanel created with Panel1 name already in the caption when most of the time the first thing you do is getting rid of that anyway..

  3. Larry Hengen Says:


    I understand your reluctance for code generation. I always end up removing the {private} and {public} comments Delphi injects when creating a unit. They’re redundant! That said, I am advocating the ability of the IDE to generate more useful code, under the control of the developer (component and end user) as much as possible.

    Your point about my 2nd code sample is well founded, IF you re-use the event handler. I generally avoid that practice as it can be quite dangerous when someone is later modifying the handler and doesn’t realize that it’s shared. When I do share a handler, I rename it from the default name to reflect this.

    The whole point about settings is so you can control what the IDE does, and customize it to your liking, but get the IDE to do more of the mundane work so you can focus on the bigger picture.

  4. Fred Weller Says:

    Why not take this all the way to the wall? It’d be Real Nice if I could either have control over the prototype (say a new form) or the code gen if a non-visual. Visual Studio allows this with the use of their T4 template system. But even they make it difficult to get to the “default” code that is used to create the various responses to selected items.
    Set me up with a system that allows me to inspect the prototypes and change them to suit me, everything from the much maligned TPanel to third party controls. Let me *truly* customize my IDE.

  5. Deksden Says:

    i m think that ide can select generated default code, so If u start typing different code - default code will be erased.

Leave a Reply