[LifeTimer]

Thanks a lot for your quick response and fix, as usual!

[LifeTimer]

Sure, here is a simple test case:

1.
Save the following macro code to a macro:

col = document.selection.GetActivePointX(eePosCell)
document.Filter(document.selection.Text, col, eeFindKeepPrevious | eeFindNegative);

2.
Load a CSV file with the following contents in the most recent version of EmEditor (in Cell Mode):

LineNr,String,Description
1,aaa,This line SHOULD be filtered-out
2,aaa,This line SHOULD ALSO be filtered-out
3,,This line and the line below should NOT be filtered-out
4,bbb,This line and the line above should NOT be filtered-out

3.
Select the cell on line 1 with the string “aaa” in it.

4.
Run the macro (I use a hot-key to run it).

5.
The result is that ONLY line 4 remains visible, while the expected result is that BOTH line 3 and 4 should remain visible, right?

If you don’t agree, please explain to me why empty cells should match the filter when I explicitly tell the filter to match a certain string (in this case “aaa”)?

Thanks!

[LifeTimer]

I’m bumping this thread too in hope of a reply, since it has now been more than three years since Mr Emura said here above that he would look into this bug, but it’s still there in EmEditor today.

Could it possibly please be fixed? It’s messing up my macros, and there’s unfortunately nothing I can do about it myself it seems. :-(

[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…

[LifeTimer]

Hello, any possibility of a reply to this?

If I cannot configure this setting in my future installs of EmEditor, my macros will be broken. :-(

[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]

Super, thanks a lot as usual for being responsive to feature requests!

[LifeTimer]

Great, thanks a lot Mr Emura, as usual!

[LifeTimer]

Thanks for your reply Mr Emura!

To answer your question, let’s say that for some certain document, I have two different complex filters (10+ filter levels targeting different columns with different filtering options etc). I have many such complex filters that I use daily in EmEditor myself.

In order to be able to apply both these filters to the target document from a macro at the same time (i.e. the same thing as if the exported macro files would be appended before being re-imported as a single imported filter), using the method you suggest above, I would have to emulate the entire filter import functionality of EmEditor from my own macro, i.e. parsing the exported filter TSV files myself (or even emulating the export functionality too, and storing the filter data in my own custom files on disk), and then read the saved filter data line by line, applying each individual filter level from these custom-parsed exported filters to the target document using the flags for document.Filter() that you suggest above.

This seems very inefficient and long-winded considering the excellent import/export functionality that is already implemented directly in EmEditor (i.e. the document.filters.Import() and document.filters.Export() methods), so what I’m suggesting here is to instead just make the minimal addition to the document.filters.Import() method of allowing it to support these two flags directly, which would then allow the user to apply both the two complex filters in this example to the target document at the same time, simply by making two subsequent calls to document.filters.Import(), with the eeFindContinue used for the first call, and the eeFindKeepPrevious flag used for the second call.

As I have hopefully been able to explain with this example, this small addition would make the macro-scriptable filtering capabilities of EmEditor a whole order of magnitude more powerful, which seems like a very good “implementation time”/benefit quota to me!

Please let me know if my explanation is still unclear, and I will do my best to fill in the blanks.

[LifeTimer]

Any chance to get a reply to this from Mr Emura?

This suggested (and easy to implement) feature would be extremely useful to me, and most likely many others too!

[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]

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

[LifeTimer]

Yep, it just happened to me too, in the most recent version (17.2.2, after being upgraded from 17.1.3), so it does not appear to have been properly fixed after all. :-(

(and I never had multiple installs of EmEditor on the system either, so that theory is most likely a red herring in regards to debugging this, provided this and the other answers above in this thread)

[LifeTimer]

Any news about this?

I’m currently getting much problems from this issue too. :-(

Also one addition that might be of importance for reproduction/fixing of this:
In my tests, it only seems like the provided macro refuses to execute if the document is already open in EmEditor and is the currently focused document in EmEditor (i.e. that it is in the editor tab that is currently selected in the EmEditor window when the command-line is executed).

[LifeTimer]

Thanks, I was running 17.1.3.

I just upgraded though, and then I found an apparently other bug that made the macro shortcuts stop working completely. :-(

I had a macro mapped to ctrl+i and another mapped to ctrl+u for example. When I try these (in cell mode) now, the only thing that happens is that the cell that is currently selected goes into “edit mode” and is also emptied. The shortcuts don’t even show up in the “Keyboard” config dialog anymore, are they completely deleted now? :-(

Please take a look at this as soon as possible, since I now cannot run macros at all after this upgrade to 17.2.2.

[LifeTimer]

Thanks, that worked!

A related question though:
In an instance of EmEditor on my old computer (latest version of EmEditor also though) I get the dialog “The specified file does not exist. Open as a new file?” if I specify a non-existing file path on the command line to EmEditor, but in my reinstalled instance of EmEditor on my new computer, I instead only get the message “The system cannot find the file specified.” (and then EmEditor doesn’t even start the editor at all), without any option to create this new file at all!? What option did I change in the old install to get the “Open as a new file?” question in this situation?

I’m placing this question on this thread, since it will be important to anyone trying to create a new file from the command line in this manner.

[LifeTimer]

Thanks a lot!

That seems to have solved the filter problems completely as far as I can see here, but yes, as usual I will report any bugs I may find, filter-wise or otherwise!

[LifeTimer]

Thank you very much Patrick for yet another very hacky (and accordingly messy ;-)), but yet very functional solution to work around this problem! :-)

Just to be a pain in the ass though, I will present yet another problem that I would have with using this solution in production:
We are planning to have multiple users being logged into the same terminal server (using the same user account), which would then result in the risk of race conditions with undefined outcomes if more than one person run the same command (with different parameter data) at the same time. :-)

Of course a quite low-probability problem, but I wouldn’t want Mr Emura to think that the problem is fully solved already, so that he doesn’t want to implement the macro parameter passing inside EmEditor itself anymore, as per my enhancement suggestion. ;-)

[LifeTimer]

Great, thanks a lot!

Any chance of getting my hands on an alpha/beta/special build now right away, since this problem is affecting my daily work so much?

Changing the filter parameters as you mention above would require me to rewrite multiple macros that I use, and also changing the already existing (many and large!) exported filters that I use, which would require a huge effort. :-(

I promise to report any other bugs, as usual, so that they all can be fixed in the next official release. :-)

[LifeTimer]

Sorry, I just tried now, and the problem with filtering away lines containing backslashes still isn’t fixed completely – such lines still remain in some cases. :-(

Here is a proof of concept for reproduction of the bug:
——————————————————————————

Input text file:

aaaaa
C:\some\path\some_file.exe
aaaaa
C:\some\path\some_file.exe
aaaaa

TSV export data file contents for the filter mentioned below in the instructions:

on something -1 EN 0 -1

Source code of the macro that is used (i.e. the exact same line hiding macro as above, and still executed with a shortcut key, while the entire contents of some line should be selected in the document), but please see more instructions below too though:

if(document.CellMode)
{
	document.Filter(document.selection.Text, document.selection.GetActivePointX(eePosCell), eeFindKeepPrevious | eeFindNegative);
}
else
{
	document.Filter(document.selection.Text, 0, eeFindKeepPrevious | eeFindNegative);
}

Steps for reproduction of the bug:

1.
Open the text file, select a line containing “aaaaa” and then run my the above line hiding filter macro. All such lines are now hidden, as expected.

2.
Close and re-open the text file, select a line containing “C:\some\path\some_file.exe” and then run the same line hiding filter macro. All such lines are now hidden also this time, as expected.

3.
Close and re-open the text file, and then apply the filter described by the TSV filter export file above to it (nothing will happen at this point since there are no matches in the filter, as expected). Select a line containing “aaaaa” and then run my line hiding filter macro. All such lines are now hidden, as expected.

4.
Now, close and re-open the text file, and then again apply the filter described by the TSV filter export file above to it (nothing will happen at this point since there are no matches in the filter, as expected). Now, select a line containing “C:\some\path\some_file.exe” and then run the same line hiding filter macro. All such lines NOW REMAIN, CONTRARY to what is expected, and CONTRARY to what happens in the exact same situation with the “aaaaa” lines in step 3 here above!

So, to be clear, the bug is what is described in step 4 here above, and it is of course very strange that it only happens during these particular conditions (both in regards to the previously applied filter levels AND to backslashes in the filtered data), rather than always (e.g. in the described step 1, 2, and 3 here above)?!

Please, if possible, let me know as soon as possible what your findings are in regards to this, since this is still crippling my daily work.

Thanks a lot as usual!

[LifeTimer]

Excellent! I have now upgraded and will let you know of any other problems I may find.

Once again, EmEditor proves to have the best and fastest support of all software I have ever owned – thanks a lot as usual!

[LifeTimer]

Hello Mr Emura, thanks for your reply.

Will the 17.1.2 version come very soon? Otherwise, could you possibly release a beta, or even send me a temporary custom build as you’ve done before, where this and my other reported filter problem are fixed?

The reason for the hurry is that these problems affect my daily work very severely, and I might otherwise have to downgrade to an older version of EmEditor in the meanwhile (is this easily done, or will there be problems for the older versions to read the settings of the later versions or similar if I have to downgrade like that?).

[LifeTimer]

Hello Mr Emura, thanks for your reply and this confirmation.

Unfortunately I cannot use any external data source like files or registry values, since I need to be able to call these command-lines from another software that I use, which can invoke external tools like EmEditor by using command-lines, but not write any files or registry values prior to that (and there are of course other cases where also only self-contained command-lines work, e.g. if I need to send a command-line to my colleague, which they then quickly can use on their computer for some task).

I think that such command-line parameter passing for macros would be a highly useful feature to go with the already super useful possibility to execute macros from the command-line with the “/mf” switch, so I have now created an enhancement suggestion for this, which I hope that the higher powers would at least take into consideration. :-)

[LifeTimer]

Hello Mr Emura, and thanks for your reply.

I’m not quite sure I understand what you mean though, or that I managed to explain my problem/goal to you properly.

What I want to accomplish is this:

With a single command-line (i.e. from outside EmEditor, from the normal cmd.exe command-line) I want to:

1. Open EmEditor with a certain text file (which is of course done simply by specifying the path to the file on the command line after “emeditor.exe”).
2. Execute a certain macro on this file (which can be done using the “/mf” switch).
3. Provide this macro with some further parameter data before it executes (which is what I’m asking you here how it can be done from the command-line???).

As I stated in my initial post above, such a macro could for example be one that will delete every n:th line from the current file, and I then want to be able to provide this macro with the “n” value (i.e. so that it can delete for example every second line, every third line, every fourth line etc, based on my current choice).

The command-line would then be as follows for deleting every third line from the file “c:\some_dir\some_target_file.txt”, and then displaying the result in EmEditor:

emeditor.exe c:\some_dir\some_target_file.txt /mf c:\my_emeditor_macros\delete_every_nth_line.jsee -macroparam “n=3”

The “-macroparam” switch is something I made up just now, as an example for how this could be done, and what I’m asking you is if some similar way to provide parameter data to macros directly from the command-line already exists in EmEditor today (or how I otherwise could accomplish this)?

[LifeTimer]

Thanks for this handy hack!

Unfortunately, I already have an open EmEditor instance most of the time when working (also with many active tabs in it, so it cannot be easily closed either), but perhaps this could in turn be worked-around by adding the “/sp” parameter, thus forcing the creation of a new EmEditor process? I will try.

It would be great though with an “official” confirmation from Mr Emura, that this environment variable hack is the only way to provide parameters to macros from the command line (in which case I would like to submit a feature suggestion for a new method to provide such parameters to macros directly on the command-line when starting EmEditor). Mr Emura?

[Author]

Posts