[LifeTimer]

Excellent, thanks!

[LifeTimer]

I have now sent you a new PoC that reproduces the problem 100%.

The bug is seemingly related to the “Show as Tool Tip” output option for external tools. If this option is selected for an external tool, it will be impossible to move the cursor (with the arrow keys, but not with the mouse) inside the editor window for as long as the external tool is executing.

I hope this will make it possible to fix this bug.

(so, it seems that this cursor freeze and the other previously discussed (by now fixed) cursor problem were two separate bugs!)

[LifeTimer]

Addition: I just noticed that this problem seems to be the same for all filter items containing backslashes.

[LifeTimer]

Any thoughts at all about my previously posted idea above yet?

Absolutely, possibly or never? :-)

[LifeTimer]

In the most recent beta version (16.0.0 beta 1) filter entries containing TABs don’t work to export and then reimport again. It doesn’t corrupt the filter export file line format now like before, but the TAB:s are instead double escaped when reimported now, and thus don’t work.

That is, if you export a filter like this:

\tABCD\t

it becomes the following after you re-import it:

\\tABCD\\t

and thus won’t work anymore.

(if it matters, I used the new macro functionality for exporting/importing it)

[LifeTimer]

I’ve tested it now, and it seems to work great, thanks!

One detail is that the entire macro crashes if you try to export an empty filter (which could be desirable in some situations), so perhaps this should be possible, or at least it should only return some error code instead of crashing the entire macro? (it’s still no show-stopper for me since I can just check the filter count and then delete the file instead, but it still might be more robust through)

An error code might perhaps also be preferable to crashing the entire macro (which currently happens) if you try to import a filter file that does not exist?

[LifeTimer]

Excellent, thanks! I’ll take a look at it and get back to you if I find any problems.

[LifeTimer]

Ok, I have now created a PoC exe file instead, and emailed it (together with the other requested information) according to your request above.

Also, one more important thing I noticed about the bug is the following:

When you execute the PoC external tool using a shortcut, the Output Bar will appear and the GUI focus in EmEditor will go to that (I don’t mean that this is part of the problem, it’s just the normal behavior leading up to my next step in the description here below).
If you then click the editor part of the GUI once after this, the cursor will appear and you will seemingly be back in the editor, and this is when the cursor will behave strangely while the PoC program is running (try to move the cursor with the arrow keys at that point, for example to the left, and you will see).
BUT, if you click the editor window once again, the cursor problem will disappear!

That is, important to note:
This bug only happens if you click the editor part of the GUI once to get back to it from the Output Bar while the external tool is running, BUT if you click it again, the bug will disappear and you won’t be able to reproduce it!

[LifeTimer]

I already thought that my test case was as simple as possible (while at the same time being exactly described). :-)

But ok, I can instead describe it like this then:

1.
Take ANY terminal program that will read its input in a non-immediate fashion (i.e. first read some input, then do some processing/waiting, then read some more input, etc), using $(CurText) as custom input.

2.
Try to move around the cursor with your arrow keys in the editor meanwhile it’s still running and reading input.

Also, a terminal program is a terminal program (i.e. it should not be able to affect anything like this beyond the common terminal interface between the programs), so the fact that my sample is a Python program should make absolutely no difference in any way, I just chose to make the example in Python because it makes it easy to exactly describe a common terminal program to test it with (since I guess you would be hesitant to run an exe file that I send you? :-)).

Also, it sounds really strange that you should have to give up shortcuts or other keyboard interactivity just because you’re running a child process and attach to it’s output via pipes, that’s not a common Windows limitation anyway (I’m a programmer myself btw)? If all else fails, execute the pipe-polling code for the Output Bar in a separate thread, and you should then be completely safe from any such effects for sure.

I understand that perhaps most external tools that people use with the Output Bar will run for too short time for people to notice this, but for the ones who do run such external tools, this is quite a frustrating bug, so it would be really great if you could take a look at fixing it, if possible.

(oh, and I can of course send you an exe-file to demonstrate the problem too, if you would prefer this after all?)

[LifeTimer]

Are you able to reproduce this too (or at least similar abnormal cursor/input behavior in the editor for such external tools taking their input over a non-instant period of time)?

[LifeTimer]

Great, thanks!

[LifeTimer]

Sorry for not providing enough details. After trying to put together a PoC, it appears that the problem is a bit more specific than I first thought.

My external tool is indeed a terminal program, and it’s using the Output Bar.

Here is a PoC that you can use to reproduce this bug-like behavior:

Run the following Python script as an External Tool:

import sys
import time

print "Starting processing, arrow keys (cursor handling) won't work correctly in the editor from this point."
sys.stdout.flush()
for line in iter(lambda: sys.stdin.readline(), ""):
	print ("You entered: " + line).strip()
	sys.stdout.flush()
	time.sleep(2)
print "Processing complete, now the arrow keys (cursor handling) will work again."

Using the following external tool settings for it:

Command: C:\Python27\python.exe (or whatever your Python path is)
Arguments: C:\your\script\path\emeditor_bug_poc.py
Use Output Bar: Yes (checked)
Input: Custom: $(CurText)
All other fields empty/default.

Now simply select multiple rows of text in the editor, and then run this external tool (either by using a shortcut or by executing it from the menu, it doesn’t matter).

For my test, I selected the following rows:

111
222
333
444
555
666
777

Now, while it is running, try to move the cursor with the arrow keys (first click in the editor to get the GUI focus there), or insert text into the document. You will see that the cursor turns “grey”, and in my case it jumps all over the place when I press some arrow keys, even to positions outside of lines, where it could not normally be placed. Also, all characters you enter in the document end up in the output bar instead of the document, even though GUI focus is still in the document.

It also seems that this only happens when I define the custom input as “$(CurText)”, or at least not when I define it as the same static contents that I’m selecting when using “$(CurText)” (i.e. 111, 222, 333, as described above), so this might be an important clue to reproduce and solve this too.

In my original (non-PoC) use-case where I discovered this behavior, the cursor just freezes completely instead and becomes impossible to move at all, but I guess it depends on the input behavior of the external tool program that is running. It seems like somehow the input of the running program is mixed together with the actions performed in the document anyway, which does indeed seem like some kind of bug, or at least a problem for the user.

[LifeTimer]

Excellent on both accounts, thanks as usual for your responsiveness!

[LifeTimer]

I just found it (sort of anyway, as long as the auto detection will work every time, which it has indeed done in my case so far):

Configuration –> File –> CSV files to Detect

Sorry for bothering you with this.

[LifeTimer]

Thanks as usual for being so responsive!

About the methodology you mention above, of always returning an error if trying to write an empty filter, it is indeed a good safety precaution for the situation I mention, but unfortunately it might also have unintended side-effects in other situations.

One such situation is the functionality that I mentioned above that I’m implementing, i.e. automatic “default filters” for a large bunch of files on my disk (every file will have a corresponding filter export file in a certain directory, which will be imported by a macro based on the directory and filename of the currently edited file in EmEditor). In some cases I will therefore want to empty this default filter for a certain file, and if exporting an empty filter has been made completely impossible, as you suggest above, there will be no way to reset such a default filter once it has been exported with any contents at any one point. :-(

If the EmEditor macro capabilities include the possibility to delete arbitrary files on disk (I’m not aware if it does this though?) I could of course just make my macro delete the exported file completely as soon as I try to export an empty filter, BUT, as long as there is also no way for me to inspect if the current filter is empty from a macro (for example by the kind of method I suggest above, querying the current number of items in the filter) I cannot even do that, since the macro would in this case never be able to tell if the filter is empty or not. :-(

So, if you choose to implement the “impossible to export empty filter” functionality (and if it is at the same time possible to somehow delete arbitrary files from disk from EmEditor macros), please do indeed consider adding at least the possibility to query the current number of items in the currently applied filter from inside macros, so that I can implement an “empty filter” special case myself for the situation of wanting to “clear” an exported filter file.

If there is not a possibility to delete arbitrary files from within EmEditor macros though, I cannot see any other way of solving this except somehow making it possible to export empty filters after all, possibly by using some kind of special flag to the export command (for example FORCE_EMPTY_FILTER_EXPORT or similar).

In my opinion, being able to query the number of items in the current filter from macros would make the absolutely cleanest solution though, since the macro developer can then be responsible himself for any extra security measures he might want to implement in order to avoid unintentionally writing an empty filter over an existing filter export file.

[LifeTimer]

Thanks so much, I’ve downloaded it now and it works great! What an excellent service you provide!! :-)

One small thing related to this that I just came to think about is the following:

Is there any way to inspect the items of the currently applied filter from a macro? At least how many they are? The reason I’m asking this is that I just got a little nervous about mistakenly pressing the shortcut for my export filter macro instead of the import filter macro, and thus overwriting the currently exported macro with an empty filter, which would not be very fun. :-( If I could just inspect the number of items in the current filter from my export macro, I could at least implement a warning when trying to export an empty filter, that’s what I thought.

I cannot find any separate Filter object in the macro reference, but rather just the Filter() method of the Document object, so I unfortunately cannot imagine how to accomplish this currently? Is it possible, or could you perhaps otherwise implement a quick method/property for this too (i.e. returning the number of items in the current filter)?

Thanks so much again for your excellent support!

[LifeTimer]

Thanks a lot for adding this, it works great!

[LifeTimer]

I’ve tried it now and it works great!

Here is the full source code of my new JSON beautifier macro:

document.selection.Text = JSON.stringify(JSON.parse(document.selection.Text), null, '\t');

:-)

By the way, you should really mention the new JSON / Javascript 5.8 support in the releasenotes for EmEditor 15.9 I think (if I’m not blind and you already did?), since it’s a very big deal I think!

Thanks a lot!

PS.
The email notifications from your forums started working for me again yesterday, did you do something about them, or did they just fix themselves in a very well-timed fashion?

[LifeTimer]

I just noticed that you had replied recently in the referenced thread above, about ongoing attempts to activate the full JScript 5.8 feature-set in the EmEditor macro engine (according to the details in my other MSDN link here above), and I’m now awaiting a reply about the status of this work in that thread. Sorry for the confusion!

[LifeTimer]

Sorry, I missed this reply before (missing forum email notifications again…).

Did you ever get it working in the 15.9.0 final version?

If not, there really must be a way to get it working, since it’s such widespread functionality, used by thousands of applications around the world, right?!

I could absolutely help you to search for clues towards a solution if you just describe the problem a bit further here (i.e. if you didn’t already got it working in the 15.9.0 final version?).

The following info might be of value:
http://stackoverflow.com/questions/14811458/how-to-use-jscript-9-features-in-a-vb6-host

Perhaps especially the following quote?

“The undocumented ‘feature’ of the SetProperty with SCRIPTPTOP_INVOKEVERSIONING is that the value must be a VT_I4 or VT_I2 – any other integer type will be rejected as invalid.“

[LifeTimer]

Excellent, thanks!

[LifeTimer]

Excellent, thanks, works like a charm!

[LifeTimer]

Excellent, thanks!

Is there any way to customize this highlight effect too? Right now it seemingly consists of only making the brackets a tiny bit more bold than usual, which unfortunately is quite hard to see on my current screen?

PS.
I missed your reply above for a while because lately the “Notify me of follow-up replies via email” feature of your forums seems to have stopped working for me, any idea why? I have checked the spam folder and no notification emails are there either, and it also always worked for me before?

[LifeTimer]

Yes, I already tried that too (that’s what I meant with “repinning” here above). The icon is the same both before pinning it again and after pinning it again.

[LifeTimer]

Yes, it’s only the taskbar icon that has this effect. The Start menu and desktop icons are the normal high-color ones, as ever.

I just tried unpinning/repinning from the taskbar too as per your request, but it made no difference.

[Author]

Posts