- October 26, 2017 at 6:55 pm #22584
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?
Does NOT work:
#include "my_other_" + "macro.jsee"
So, how can I call/execute other macros dynamically from my EmEditor macros?October 27, 2017 at 12:18 am #22586
Executing macros is simple:
editor.ExecuteMacro( “d:\example.jsee”, eeRunFile | eeMacroLangJScript );
However, I don’t whether or not dynamical includes are possible.October 27, 2017 at 4:15 pm #22597
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?
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).October 28, 2017 at 12:51 am #22599
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 helpsOctober 28, 2017 at 1:10 am #22600
btw – for more information on WScript.Shell with RegRead and RegWrite:October 28, 2017 at 3:43 pm #22601
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!)November 21, 2017 at 2:00 pm #22640
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!
You must be logged in to reply to this topic.