View Issue Details

IDProjectCategoryView StatusLast Update
0036083LazarusIDEpublic2019-11-03 21:10
ReporterserbodAssigned ToMartin Friebe 
Status resolvedResolutionfixed 
Product VersionProduct Build61897 
Target VersionFixed in Version 
Summary0036083: TIdeMacroEventReader.ParseNextEvent() treats Pascal reserved words as errors
DescriptionTIdeMacroEventReader.ParseNextEvent() function treats Pascal reserved words as errors.

For example, if imported macros contain 'procedure' identifier, it silently ignored. But if macros recorded and edited, same script accepted as valid and works fine.
TagsNo tags attached.
Fixed in Revision
Attached Files


Martin Friebe

2019-09-18 18:10

manager   ~0118106

How to trigger/reproduce?

I can see that it would reject "procedure". In fact it only allows known macro-commands like ecChar, ecDelete, ...
But that should be correct. (ParseNextEvent is only for basic / none-PasScript macros)

"procedure" only has a meaning, if the package EditorMacroScript (should be by default) is installed (which brings in PascalScript).
But then TIdeEditorMacro.SetFromSource is overridden by TEMSEditorMacro.SetFromSource. So ParseNextEvent should not get called.

Note that, if EditorMacroScript fails its self test, is becomes unavailable. In that case macros based on pascal script can neither be loaded, nor played, nor in any other way be used.
The self test can be requested to run again from the IDE Tools > Options.


2019-09-19 08:54

reporter   ~0118112

Is there a way to visually separate Editor Macro window tabs to 'macros' and 'scripts'?

Macro - plain text, sequence of editor action names. Can be recorded from user actions and edited in simple text editor, with trivial validation. Maybe, there can be some action to run desired script

Script - Pascal script, edited in main editor, with sintax checking, autocompletions, hints and other features. There can be function, that run desired macro. Scripts disabled if PasScript not available.


2019-09-19 11:47

reporter   ~0118117

Bug reproduced on trunk with default settings, and not reproduced on stable release.

1. In stable release create some Editor Macro Script. For example:
procedure FindNextSelectedText();
  sText: string;
  pt: TPoint;
  sText := Caller.SelText;
  if sText <> '' then
    pt := Caller.CaretXY;
    Caller.SearchReplace(sText, '', []);
    if pt = Caller.CaretXY then
      Caller.SearchReplace(sText, '', [ssoEntireScope]);


2. Export script to file

3. Build Lazarus from trunk with default settings,

4. Import script from file.

Martin Friebe

2019-09-21 01:32

manager   ~0118143

Last edited: 2019-09-21 02:04

View 2 revisions

I saved that macro with 2.0.4, and copied the file to my trunk config. I do not get an error in the specified function (nor any error loading the macro).

I suspect that somehow PascalScript may have gotten disabled on your install.
Please go to menu: Tools > Options
Then in the tree to "Editor Macro Script" and check that scripting is active.
If it is not, then request are re-test, and restart the IDE, and check again.

Depending on how you did build your trunk IDE, also make sure the package EditorMacroScript (components/macroscript) is installed.
If it is not, the above entry in the Options will not exist.

If it still is disabled (you should have gotten a message while starting the IDE), then in your config path find the file
and copy the contents to this report.
Also in this case add the following info:
- What OS are you on?
- OS bitness 32/64bit
- Lazarus compiled for 32/64bit
- CPU (e.g. Intel / arm)

If the macro loads, you may still get an error when trying to execute (play) it.
At least I got the following:
  Error: Exception: "Type Mismatch" at 6/3

I will be looking at this part of the issue in the meantime.

-- EDIT:
The "play" error is fixed in revision 61908


2019-09-23 14:49

reporter   ~0118152

I followed instructions and discover, that EditorMacroScript package was not installed into IDE.

Well, problem is solved. But about 2 years I was thinking, that editor scripting was broken in trunk. =(

So, my proposals:

1. In "Editor Macros" form, place some warning/disklaimer text, about EditorMacroScript package, that it needed for scripting.

2. Replace EditorMacroScript package decription
  "access to additional properties and methods."
to something more informative -
  "allow use PascalScript for Editor automation".

Martin Friebe

2019-09-26 20:04

manager   ~0118171

The full description text of the package is:
IDE-Extension: Adds PascalScript to editor-macros.

This package requires: PascalScript from REM Objects (

Extends the Editors macro recorder and player. Macros can be written in pascal script. They also have access to additional properties and methods.

So it already states that it adds PascalScript. Anyway the last sentence is a bit obscure, so I changed it a little bit.

Martin Friebe

2019-09-26 20:18

manager   ~0118172

Last edited: 2019-09-26 20:40

View 2 revisions

" In "Editor Macros" form, place some warning/disklaimer text, about EditorMacroScript package, that it needed for scripting."

Unfortunately that is not that easy.

If the EMS package is NOT installed, then the IDE has no idea it even exists (or at least what it does). So the IDE does not know that there could be macros in PS, until and unless EMS is installed.
And that is exactly how it should be. The package is optional to the IDE. (Otherwise it would have been added in a way that prevents it from uninstall / Like you can not uninstall SynEdit)
More important, that means a user who deliberately uninstalled it does not want to be bothered by some warning.

The package is part of "make bigide". So it is only missing, if you choose to build less than bigide. Or if you did "svn up" since before the package existed. (Then you may miss other packages too)


However, if the package is installed, but failed the self-test, then it could add an alert, if individual macros can not be loaded.

The only other thing that could be added is, if EMS is installed, it could warn that macros might not run in any IDE where it is not installed. But I am not a fan of that. A proper running and correctly used system should not give warnings.
Also that would warn for all Macros. Because if EMS is installed, *ALL* macros (even the simple ones) are treadet as PascalScript. (That could be distinguished, but at quite an effort. Svn users are expected to know what they do)

I am keeping the issue open for the "self test failed" warning. (only that one)


2019-09-27 11:40

reporter   ~0118173

> Unfortunately that is not that easy.

Then, in base TEditorMacro class can be properties MacroClassName and MacroClassDescription.

MacroClassName - contain class name of macro player, for example 'TEMSEditorMacro', and that name exported in XML. If imported script from XML have unsupported class name, then script will be ignored (optionally with warning).

MacroClassDescription - contain meaningful description of macro player, his abilities and restrictions. It can be displayed in Macro Editor form and in Tools -> Options -> Editor Macro page

The goal of that - is eliminate potential incompatibility of scripts, prevent IDE crashes, and make difference in TEditorMacro descendants visible for user.


2019-09-27 12:01

reporter   ~0118174

> The full description text of the package is

Sorry, my "Install/Uninstall Packages" window show only some last lines from full description. I will report about that in separate tracker issue.

Martin Friebe

2019-11-03 21:10

manager   ~0119021

In r62178 I added a warning that will show in the macro-list window, IF the PascalScript self-tests failed.

That requires this package to be installed.
If the package is not installed, then it is assumed that it was intentionally left out, and the user therefore does not want to be bothered.

0036083:0118173 "MacroClassName "

Extending each Macro with a class in the xml is a possible idea.
It would require quite some refactoring.

At the moment, none-pascal-script macros are stored as such. So that would need to be changed.

Instead of currently one player class inheriting the other, they would all have to be in parallel (inheriting a common baseclass). That would also improve design towards allowing several different scripts allowed.

I do not currently plan to work on this refactor. But if anyone wants, details can be discussed, and based on the details a patch could be accepted.

Issue History

Date Modified Username Field Change
2019-09-18 15:06 serbod New Issue
2019-09-18 16:53 Martin Friebe Assigned To => Martin Friebe
2019-09-18 16:53 Martin Friebe Status new => assigned
2019-09-18 18:10 Martin Friebe Status assigned => feedback
2019-09-18 18:10 Martin Friebe LazTarget => -
2019-09-18 18:10 Martin Friebe Note Added: 0118106
2019-09-19 08:54 serbod Note Added: 0118112
2019-09-19 08:54 serbod Status feedback => assigned
2019-09-19 11:47 serbod Note Added: 0118117
2019-09-21 01:32 Martin Friebe Status assigned => feedback
2019-09-21 01:32 Martin Friebe Note Added: 0118143
2019-09-21 02:04 Martin Friebe Note Edited: 0118143 View Revisions
2019-09-23 14:49 serbod Note Added: 0118152
2019-09-23 14:49 serbod Status feedback => assigned
2019-09-26 20:04 Martin Friebe Note Added: 0118171
2019-09-26 20:18 Martin Friebe Note Added: 0118172
2019-09-26 20:40 Martin Friebe Note Edited: 0118172 View Revisions
2019-09-27 11:40 serbod Note Added: 0118173
2019-09-27 12:01 serbod Note Added: 0118174
2019-11-03 21:10 Martin Friebe Status assigned => resolved
2019-11-03 21:10 Martin Friebe Resolution open => fixed
2019-11-03 21:10 Martin Friebe Note Added: 0119021