Hi,

Is it possible to have the following in the code tools:

I would like to be able to specify a code snippet that is inserted at the start and end of a procedure (after begin, before end keywords). The code snippet should contains some macros like $(CLASSNAME) $(METHODNAME). Conceivably, other macros can be thought of: parameters, unit name etc.

The intended use is that the IDE generates stuff like

Procedure TMyClass.MyMethod;
begin
   {$IFDEF LOGPROCESSFLOW}Log('Entering TMyClass.MyMethod');{$ENDIF}
   {$ENDIF LOGPROCESSFLOW}Log('Exiting TMyClass.MyMethod');{$ENDIF}
end;

If I have specified as code snippets

{$IFDEF LOGPROCESSFLOW}Log('Entering $(CLASSNAME).$(METHODNAME)');{$ENDIF}

for the begin keyword, and for the end keyword:

{$IFDEF LOGPROCESSFLOW}Log('Exiting $(CLASSNAME).$(METHODNAME)');{$ENDIF}

Similarly, I'd like to be able to specify a code snippet to insert before/after the procedure header:

{ ---------------------------------------------------------------------- AUTHOR: $AUTHOR
PURPOSE:
ARGUMENTS:
RETURN VALUE:
---------------------------------------------------------------------}

(just an example)

Maybe some additional snippets can be imagined. I am specifically looking for the first one.

Additionally (and quite importantly) this behaviour should be easily toggled on/off, without having to empty the templates.

Maybe such a thing already exists, but I have not been able to locate it ?

Michael.

If the compiler could track the current procedure (or function, or class.method etc.) name, then couldn't that be done with a macro? Then the app source would be a less-obtrusive:

Procedure TMyClass.MyMethod;

begin_logged

end_logged;

Otherwise, since this is such a common requirement, how about a non-fatal equivalent of Assert()?

I prefer not to use macros. This is not C.
I like to see explicitly what is happening.
Pascal macros are also not customizable/parametrizable (as the IDE macros are).

Otherwise, since this is such a common requirement, how about a non-fatal equivalent of Assert()?

I don't think this should be a promoted to a language feature either.

There may be additional use cases for this feature, which we cannot all cover with language features.

The comment header for one is something encountered quite often in teams that need to follow some standards, for ISO 9001 etc.

In the IDE, at the level of generated sources, the user is able to control every aspect of what happens.

That may well include inserting any hypothetical pascal-language-level macro.

Michael.

There are several such things. They need some work to make them more comfortable though:

1.
You can add code templates (Ctrl-j). For example for the method start
go to Tools / Code templates,
then add a new one,
give it a name, e.g. 'pb' and a description 'procedure begin', click "enable macros"
And as source:
{$IFDEF LOGPROCESSFLOW}Log('Entering $ProcedureName()');{$ENDIF} Click ok to save and close dialog.

Move cursor behind the "begin" and type pb and Ctrl+j.

2.
I wrote a small command line utility for Graeme that can add/remove code to starts/ends of procedures. He needed it for profiling. The tool is here:
components/codetools/examples/addfpprofcalls.lpi
It is merely a demo, but maybe someone wants to write a dialog and/or IDE package.

3.
Donald Ziesig added templates to the IDE to configure some parts of class completion. You can try it by compiling Lazarus with -dEnableCodeCompleteTemplates. Then you should see new options on the code creation page. I had not the time yet to finish it.

Mattias

Not an exact match to your question, but: Do you know LazLogger! It has DebuglnEnter/DebuglnExit which will add a nice intend (so long as you do not skip them by raising an exception.

You can use a code template, to insert (['$ProcedureName() '|]);

If you are at the begin of a procedure, you can record a macro, using the key stroke for "find block other end", that allows to insert opening and closing statement.

In addition, you do not need the IfDef.

Debugln is in unit LazLoggerBase or LazLogger.
If you change the "uses" to LazLoggerDummy, then all debugln are replaced by empty inline methods (the inline does not work for "array of const" though).

LazLoggerBase gets a working debugln, but logs to nowhere. (use in packages, and units)
LazLogger installs the actual Logger (to file or console). Affects all debugln that where used from LazLoggerBase (use in your main unit)

it allows on command line
--debug-log=
--debug-enable
--debug-disable

debuglneEnter/Exit can be grouped to be enabled/disabled Debugln(GROUPNAME, ['msg', data])

see gdbmidebugger units how to "RegisterLogGroup"

Would you be happier if it were described or implemented like an ALGOL control card? This is a clear case of something which is needed fairly regularly by all users of the language, rather than just by those who use Lazarus, and having a decent way to implement it at the language level is preferable even if there were an IDE shortcut.

Rejecting a feature out-of-hand simply because it's "not invented here" is highly undesirable in my opinion. Everybody agrees that C has problems and many agree that even the current C++ standard is basically putting lipstick on a pig, but that's no reason to avoid coopting and reimplementing the good bits /properly/.

Besides which, macro replacement predates C by many years. Don't get me going on that one since I risk being an olympic-grade bore :-)

This is what I do now (useful for adding to existing code), but I want to make it even more simple.

Aha... Good for backfitting existing code :)

This seems to be what I am looking for. I will try this and report.

Thanks. You confirmed once more that Lazarus is simply the best code editor around ;)

Michael.

I do now :)

But I want the ifdef :)

The reason is that I very often add some code inside the $IFDEF to check for assigned props, params and whatnot. So, having it there from the start is an advantage.

And like I said: the feature can be used for a lot more than just logging.

Nevertheless, I am going to check out lazlogger in more detail. Seems like good stuff for an article. Thanks for the tip !

Michael.

Well, we differ in our opinions here.

The less we do at the language level, the better.
It's getting bloated enough as it to my taste.

So yes, it stops there as far as I am concerned.

Michael.

Michael Van Canneyt wrote

On Thu, 27 Mar 2014, Martin Frb wrote:

Indeed. It would be usable for implementing "Design by Contract" checking scheme, for external code beautifying/printing/version control tools for example. Or maybe tool driven license enforcement, changing the license checking code and it's positions often by using templates. Maybe code injection, but I'm not really sure with that.