Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #22584

    LifeTimer
    Participant

    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?

    #22586

    Patrick C
    Participant

    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.

    #22597

    LifeTimer
    Participant

    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).

    #22599

    Patrick C
    Participant

    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

    #22600

    Patrick C
    Participant
    #22601

    LifeTimer
    Participant

    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!)

    #22640

    LifeTimer
    Participant

    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!

Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.

Share with friends... Tweet about this on TwitterShare on FacebookShare on Google+Email this to someone