[LifeTimer]

The #include directive in EmEditor macros is very useful for simple includes of other macro files (typically for simple static code reuse).

BUT, I need to include other macros dynamically. I.e., depending on certain conditions, I need to include (or otherwise execute) different other macros from my macro, and the #include directive only seems to support a static string as its parameter, right?

Example:

Works:
#include "my_other_macro.jsee"

Does NOT work:
#include "my_other_" + "macro.jsee"

So, how can I call/execute other macros dynamically from my EmEditor macros?

[Patrick C]

Executing macros is simple:
editor.ExecuteMacro( “d:\example.jsee”, eeRunFile | eeMacroLangJScript );
http://www.emeditor.org/en/macro_editor_editor_executemacro.html

However, I don’t whether or not dynamical includes are possible.

[LifeTimer]

Thanks!

I need to be able to communicate data between my “parent macro” and the “sub macro” that it executes using this editor.ExecuteMacro() method though, and the execution contexts seem to be completely different when using editor.ExecuteMacro(), i.e. they cannot access each other’s variables it seems? Is there any elegant way that this can be done?

(I’d rather, if possible, avoid hacky solutions like using the eeRunText flag combined with prepending self-generated Javascript source code for setting the variables in question locally, or the eval() equivalents of this solution)

If pure variables are currently completely impossible to share between “parent macros” and “sub macros” like this in EmEditor, are there any other “elegant” ways to share data between “parent macros” and “sub macros”, e.g. by using some kind of common property in the Document or Window object? This would otherwise be a nice thing for EmEditor to provide in future versions! E.g. a property like Document.TempGlobalData, which any macro could read from and write to (this would also solve this previous request from another user by the way).

[Patrick C]

So far I used the Windows Registry «semi-hack ‘solution’», the following is an example:

In script 1:

var WshShell = new ActiveXObject( "WScript.Shell" );

WshShell.RegWrite( "HKCU\\_Patrick_custom_\\str1", "ab cd",  "REG_SZ"    );
WshShell.RegWrite( "HKCU\\_Patrick_custom_\\str2",  "1234",  "REG_SZ"    );
WshShell.RegWrite( "HKCU\\_Patrick_custom_\\num1",   1234 ,  "REG_DWORD" );

 editor.ExecuteMacro( “d:\\script2.jsee”, eeRunFile | eeMacroLangJScript );

In script 2:

var WshShell = new ActiveXObject( "WScript.Shell" );

var str1 = WshShell.RegRead( "HKCU\\_Patrick_custom_\\str1" );
var str2 = WshShell.RegRead( "HKCU\\_Patrick_custom_\\str2" );
var num1 = WshShell.RegRead( "HKCU\\_Patrick_custom_\\num1" );

OutputBar.writeln( "str1     = " + str1                                                                      );
OutputBar.writeln( "str2 + 1 = " + (str2 + 1)   +  "  // an imported string is not automatically a number"     );
OutputBar.writeln( "num1 + 1 = " + (num1 + 1)   +  "  // an imported DWORD really is an integer"               );

Hope this helps

[Patrick C]

btw – for more information on WScript.Shell with RegRead and RegWrite:

https://msdn.microsoft.com/en-us/library/aew9yb99(v=vs.84).aspx
https://msdn.microsoft.com/en-us/library/x05fawxd(v=vs.84).aspx
https://msdn.microsoft.com/en-us/library/yfdfhz1b(v=vs.84).aspx

[LifeTimer]

Thanks Patrick for your suggestion, as usual!

I’ve actively been staying away from using the registry (or files on disk) due to its “non-thread-safeness” though, i.e. if two people on the same computer are running macros at the same time, there will be a “race condition” with unpredictable results, which makes me prefer even the above mentioned “eval based” hack solutions in my original post to this. (oh, and there will also be a need for much cumbersome serialization/encoding for saving somewhat more complex data using the registry, e.g. objects/arrays and nested such).

I therefore urge you Mr Emura, can’t we please just have one generic Document.TempGlobalData property (of Object type), and preferably also an equivalent Editor.TempGlobalData property (i.e. one that is editor-global and one that is document-global), that we can use freely for writing/reading as we please inside any macro, and all these problems would then be solved for good?

(Please also note that I’m not looking for persistence beyond running editor instances or open documents. For that scenario, registry data and/or files on disk will be just fine!)

[LifeTimer]

Any chance this (implementation-wise) very simple feature request could be fulfilled in a coming version too?

It would be extremely useful for more advanced macro programming in EmEditor!

[LifeTimer]

Any possibility of considering (or at least replying to) this?

I’m waiting in hope of such a feature to be implemented in EmEditor, in order to be able to implement some advanced features in my own macros…

[Author]

Posts