notepad.runMenuCommand in Hebrew

[Yaron10]

Hello Dave,

When Notpad++ Interface Language is set to English, the following script is executed successfully.

notepad.runMenuCommand("View", "Word wrap")

However, I couldn't find a way to run that script if the Interface Language is set to Hebrew.
I've tried various ".decode('utf8')" commands, but to no avail.

Thank you for this great plugin.

[Yaron10]

notepad.menuCommand(MENUCOMMAND.VIEW_WRAP)

Works even if the Interface Language is set to Hebrew.

[chcg]

@Yaron10 How is in case of Hebrew the command equivalent to

notepad.runMenuCommand("View", "Word wrap")

written and which direction do you use? RTL?

[Yaron10]

Hello @chcg,

Thanks for replying. I appreciate it.
And many thanks you for your work on this plugin. 👍

The command in Hebrew is notepad.runMenuCommand("תצוגה", "גלילת שורות").
It works from the console but not within a script.

I use NPP in Hebrew and the layout is RTL.

---

Two related request:

1) Could you set the console layout to LTR even if NPP layout is RTL?
Please see this discussion (the RTL part).
@ClaudiaFrank kindly found the relevant code (thanks again Claudia).

• As I've mentioned in that thread, Dave uploaded PythonScript v1.1.1 without committing the changes.
  Have you committed the fix included in v1.1.1?

2) Could you add Unicode support to the menu?
Hebrew file-names are displayed as gibberish.

---

Allow me two more questions:

1) Dave's latest official version is 1.0.8.0. Why did you start with 0.6.3.0?

2) I've downloaded your latest PythonScript_Full_1.0.9.0.zip and replaced the DLL and the lib folder.
from ctypes import windll, byref, wintypes, WINFUNCTYPE, Structure, sizeof in startup.py triggers an error.
Why is that?

---

Thanks also for your contribution to ComparePlugin. :)

Best regards.

[ghost]

Yaron, what error do you get?
How is your python (not python script) setup? Local version or the dll from the zip.
Short test

Why do you think 1.0.9.0 was created out from 0.6.3??

[Yaron10]

Hello Claudia,

Thanks for replying. I appreciate it.

I'm using the DLL from the zip package.
I've replaced python27.dll and PythonScript.dll with the new ones.

I don't get the error now. It was certainly there a few hours ago.

However, NPP consistently hangs when I'm using the following script.

if RIGHT_CLICK_MODE:
	console.hide()
	editor.grabFocus()
else:
	console.show()

With the following startup.py (thanks again :) ).

# The lines up to and including sys.stderr should always come first
# Then any errors that occur later get reported to the console
# If you'd prefer to report errors to a file, you can do that instead here.
import sys
from Npp import *

# Set the stderr to the normal console as early as possible, in case of early errors
sys.stderr = console

# Define a class for writing to the console in red
class ConsoleError:
	def __init__(self):
		global console
		self._console = console;

	def write(self, text):
		self._console.writeError(text);

# Set the stderr to write errors in red
sys.stderr = ConsoleError()

# This imports the "normal" functions, including "help"
import site

# This sets the stdout to be the currently active document, so print "hello world",
# will insert "hello world" at the current cursor position of the current document
sys.stdout = editor

##################### Right-click mode and Change console output to LTR. #####################

# See https://notepad-plus-plus.org/community/topic/13510/python-lua-script-detect-if-a-modifier-is-pressed-when-running-a-script.

# console.write('parent:{}\n'.format(parent))

from ctypes import windll, byref, wintypes, WINFUNCTYPE, Structure, sizeof

WNDENUMPROC = WINFUNCTYPE(wintypes.BOOL,
                          wintypes.HWND,
                          wintypes.LPARAM)

WndProcType = WINFUNCTYPE(wintypes.LONG,
                          wintypes.HWND,
                          wintypes.UINT,
                          wintypes.WPARAM,
                          wintypes.LPARAM)

GWL_WNDPROC = -4
RIGHT_CLICK_MODE = False

GWL_EXSTYLE = -20
WS_EX_LAYOUTRTL = 0x00400000

class NPPchildWindows():

	def EnumNPPCallback(self, hWnd, lParam):
		curr_class = (wintypes.WCHAR * 256)()
		windll.user32.GetClassNameW(hWnd, curr_class, 256)

		if lParam == 0:
			if curr_class.value.lower() == "toolbarwindow32":
				self.toolbar_handle = hWnd
				return False
		else:
			curr_name = (wintypes.WCHAR * 256)()
			windll.user32.GetWindowTextW(hWnd, curr_name, 256)
			if curr_name.value.lower() == "python script":
				self.python_script_hwnd = hWnd
			elif curr_class.value.lower() == "scintilla" and windll.user32.GetParent(hWnd) == self.python_script_hwnd:
				self.python_script_sci_handle = hWnd
				return False

		return True

	def __init__(self):
		self.toolbar_handle = None
		self.oldWndProc = None
		self.python_script_hwnd = None
		self.python_script_sci_handle = None

		parent = windll.user32.FindWindowA("Notepad++", None)
		windll.user32.EnumChildWindows(parent, WNDENUMPROC(self.EnumNPPCallback), 0)
		console.show()
		windll.user32.EnumChildWindows(parent, WNDENUMPROC(self.EnumNPPCallback), 1)

	def registerRightClick(self):
		if self.toolbar_handle:
			self.new_wnd_proc = WndProcType(self.sciWndProc)
			self.oldWndProc = windll.user32.SetWindowLongA(self.toolbar_handle, GWL_WNDPROC, self.new_wnd_proc)
			console.write("Toolbar right-click mode registered.\n\n")

	def sciWndProc(self, hWnd, msg, wParam, lParam):
		global RIGHT_CLICK_MODE
		if msg == 0x0204:		# WM_RBUTTONDOWN.
			windll.user32.mouse_event(0x0002, 0, 0, 0, 0)	# Left down. WM_RBUTTONUP is sent although the right button is still down.
		elif msg == 0x0205:	# WM_RBUTTONUP.
			if RIGHT_CLICK_MODE:		# Another WM_RBUTTONUP is sent when the right button is released. Send "Left up" now.
				windll.user32.mouse_event(0x0004, 0, 0, 0, 0)	# Left up.
			else:	# The right button is still down.
				RIGHT_CLICK_MODE = True
		elif RIGHT_CLICK_MODE and msg == 0x0201:		# WM_LBUTTONDOWN.
			RIGHT_CLICK_MODE = False

		return windll.user32.CallWindowProcA (self.oldWndProc, hWnd, msg, wParam, lParam)

	def consoleToLTR(self):
		if self.python_script_sci_handle:
			exStyle = windll.user32.GetWindowLongA(self.python_script_sci_handle, GWL_EXSTYLE)
			exStyle = exStyle ^ WS_EX_LAYOUTRTL
			windll.user32.SetWindowLongA(self.python_script_sci_handle, GWL_EXSTYLE, exStyle);
			console.write("Console output changed to LTR.\n\n")

_NPPchildWindows = NPPchildWindows()
_NPPchildWindows.registerRightClick()
_NPPchildWindows.consoleToLTR()

console.hide()
editor.grabFocus()

I've added several right/left toolbar buttons (using CustomizeToolbar; executing various scripts) and they all work properly except the Show/Hide one.

Actually, just using console.show() causes NPP to hang.
Reverting to the original startup.py, console.show() works as expected.

Replacing the new PythonScript.dll with the old one - the Show/Hide button works properly.

---

Why do you think 1.0.9.0 was created out from 0.6.3??

https://github.com/bruderstein/PythonScript/releases

0.6.3 was released a few days ago and I was just wondering why those numbers were chosen when 1.0.8.0 was out a few years ago. Isn't that confusing?

Best regards.

[ghost]

Isn't that confusing?

Ah, I see - you are right but I guess this is related to appveoy automatically pushing the artifacts
but chcg would know better. I will take a look to your issue and see if I can find out what it is causing it.

[Yaron10]

Great. 👍
Thank you very much.

[ghost]

Would you mind restart npp, show console and post the output?

[Yaron10]

Toolbar right-click mode registered.

Console output changed to LTR.

Python 2.7.14 (v2.7.14:84471935ed, Sep 16 2017, 20:19:30) [MSC v.1500 32 bit (Intel)]
Initialisation took 47ms
Ready.

Thanks.

[ghost]

ok - and problem still exists?
The reason why I'm asking is that I can only reproduce it if python script dll and python dll
are from different builds like new 1.0.9.0 python script and old python dll from 1.0.8.0

[Yaron10]

Yes, it does.
I've tried those combinations. :)

[ghost]

You took the zip - you didn't build it yourself, didn't you?

[Yaron10]

The original zip.

[Yaron10]

And it also happens with the original NPP.

[ghost]

It seems toolbar related

[Yaron10]

I'm using some other buttons which work flawlessly.
And the Show/Hide works with the old DLL.

[ghost]

Did you try to run this from the menu? - For me it looks like running from the menu doesn't cause the issue
but clicking the toolbar button freezes it (but only in release version, not under VS2017 debugger :-( )

[Yaron10]

Works fine from the menu.
Clicking the button either left or right causes the hang.

[ghost]

OK - now we need to understand what is causing it and why it isn't happening under debugger.
Keep you updated

[Yaron10]

Many thanks.

[ghost]

Looks like there is a boost exception which cannot be handled.
Temporary workaround: instead of
console.show()
use
notepad.runPluginCommand('Python Script','Show Console')

[Yaron10]

👍
I'd like to hide it too with the same button. :)
Actually, wouldn't it be good to make Show Console toggle the console regardless of this issue?

Thanks again for looking into it. Appreciated.

BTW, is there an updated PythonScript.chm?

[ghost]

The zip contains the help file of the current version - do you miss some infos?
Note notepad object hasn't been updated yet as it is still in testing phase.

Show Console button - agreed, but currently the focus is getting a stable 64bit version and updating
notepad object but who knows - maybe it will come sooner than later.

[Yaron10]

The zip contains the help file of the current version

Great. I somehow missed that.
I didn't have a specific issue in mind.

but currently the focus is getting a stable 64bit version and updating
notepad object but who knows - maybe it will come sooner than later.

Sure.
I've had a quick look at the list of fixed issues. Great job.

Thank you and good night.

[chcg]

@Yaron10 @ClaudiaFrank Just wrote @bruderstein a mail to get some info about "missing" version 1.1.1.

[chcg]

@Yaron10 Regarding the release dates. See https://github.com/bruderstein/PythonScript/tags. They show the original dates, but some days ago only the tags existed without a corresponding release info. So I created them from the changelog (http://npppythonscript.sourceforge.net/changelog.shtml), but it seems it is not possible to modify the creation date.

[Yaron10]

@chcg,

Thank you for writing to Dave and for the explanation.
👍

[ghost]

@Yaron10 - looks like this PR Console GIL fixes #51 from Dave solves your freezing.

[Yaron10]

Thanks for testing and letting me know.

Trying to build the solution, I got the following errors:

In the meantime, may I ask you to upload the DLL?

• Including Console GIL fixes #51 and your fixes issue #34 - put on hold #53.
• In StaticDialog.cpp please comment the lines:

	DLGTEMPLATEEX *pMyDlgTemplateEx = reinterpret_cast<DLGTEMPLATEEX *>(*ppMyDlgTemplate);
	if (pMyDlgTemplateEx->signature == 0xFFFF)
		pMyDlgTemplateEx->exStyle |= WS_EX_LAYOUTRTL;
	else
		(*ppMyDlgTemplate)->dwExtendedStyle |= WS_EX_LAYOUTRTL;

I do appreciate your help.

[ghost]

@Yaron10
Looks like you haven't specified where your python include, and probably library, files are.

[chcg]

@Yaron10 See e.g. https://ci.appveyor.com/project/bruderstein/pythonscript/build/1.0.9.20/job/ja7nfkfk85wo550u/artifacts. So each PR will be build by appveyor.

Compilation issue seems to be related to the missing update of the git submodule for google test, see e.g. https://git-scm.com/book/de/v1/Git-Tools-Submodule

[Yaron10]

@ClaudiaFrank,

looks like this PR Console GIL fixes #51 from Dave solves your freezing.

The issue is indeed solved. 👍
Thank you.

@chcg.
Thanks for the info.

[chcg]

@Yaron10 Shouldn't the command be:

                <Item id="44022" name="עטיפת מילים"/>

from https://github.com/notepad-plus-plus/notepad-plus-plus/blob/master/PowerEditor/installer/nativeLang/hebrew.xml#L139 ?

[Yaron10]

@chcg,

Yes, the string is עטיפת מילים.
I use my own translation and forgot to look it up in the official Hebrew.xml.
I'm sorry about that.

Thanks again for your work. Appreciated.

[chcg]

@Yaron10 You may want to test https://ci.appveyor.com/project/bruderstein/pythonscript/build/1.0.9.33, which contains the changes for unicode support for script filenames.
I think later I will create a release 1.1 out of this.

[Yaron10]

@chcg,

👍
Great work. Highly appreciated.

@ClaudiaFrank,

Thanks again for your contribution.
It's great and highly appreciated too. :)

---

#34 is fixed too, isn't it?

---

Some minor comments:

1. Wouldn't Run Last Script be better than Run Previous Script?

2. Configuration and About in the menu should have an ellipsis (i.e. Configuration...).

3. Configuration Dialog: the Menu items' ListBox is slightly higher than Toolbar icons'. Intentionally?

Best regards.

[chcg]

• ad 1. Don't think there is a diff between last or previous.
• ad 2. I think for the about dialog the ... is unusual. Configuration makes sense to adapt to the n++ behaviour. See cec4d36
• Fixed 3. with 5969bb8

[ghost]

I don't have any opinion on Last vs. Previous - for me, both explain the same.

I understand ellipses, like this, as an info that says that the window has, let's say, multiple views.
Like tabs and ...
PS Configuration shouldn't use the ellipsis as, contrary to Npp, it is a single view with settings.
I wouldn't say that machine scripts and user scripts count as two different views.
About window has neither in Npp nor in PS additional views - no ellipsis.

[Yaron10]

Fixed 3. with 5969bb8.

👍
Very nice. Thank you for the quick fix.

---

Don't think there is a diff between last or previous.
...
I don't have any opinion on Last vs. Previous - for me, both explain the same.

It's certainly not important but I think that Last is more commonly used in this context (e.g. Last Closed Tab).
As you understand.

Ellipses...

Well... I thought the rule was that any command/button opening a new window should have an ellipses.
The Registry Workshop developer is quite a perfectionist. An ellipses is added to both Settings and About in that app.

But reading this article you seem to be right: no ellipses for Settings and About.

This doesn't mean you should use an ellipsis whenever an action displays another window—only when additional information is required to perform the action. Consequently, any command button whose implicit verb is to "show another window" doesn't take an ellipsis, such as with the commands About, Advanced, Help (or any other command linking to a Help topic), Options, Properties, or Settings.

---

Allow me another minor comment:
I've just noticed the Configuration Dialog title is: Python Script Shortcut Configuration.
It contains other settings as well; so wouldn't Python Script Configuration be better? Or even better - Python Script Settings?

[Yaron10]

And Set Icon should certainly be Set Icon.... :)

[ghost]

Well... I thought the rule was that any command/button opening a new window should have an ellipses.

OK, I have to admit I have no idea about GUI design rules but it is nice to see that MS has the same opinion.
I just ignore for the moment that Microsofts argument is totally different to mine ;-)

[Yaron10]

but it is nice to see that MS has the same opinion.

Great minds think alike.

I just ignore for the moment that Microsofts argument is totally different to mine

I've ignored that too. :)

[Yaron10]

such as with the commands About, Advanced, Help (or any other command linking to a Help topic), Options, Properties, or Settings.

Well, MS VS uses Options... and Properties.... :)
And this seems to be the convention in most good apps.

[ghost]

Maybe someone should tell the VS development team how to use ellipsis and point to their article :-D

Actually, I think that article explains very well when it should be use and as more as I think about it I agree
to it. A button which should execute an action but needs additional infos to execute it should use ellipsis.

Makes sense, doesn't it? Showing Properties window is the action the button should do, therefore no ellipsis - I like it.

But at the end - I don't care at all as I'm using npp without menu, tabbar ... most of the time.

[Yaron10]

Makes sense, doesn't it?

Yes, it does.
OTOH, I'm not sure the convention should be completely ignored. It's somewhat like a "proper" language vs. a common language.

So we'll raise a toast to whatever @chcg decides to do. :)

[chcg]

@Yaron10 See Version 1.1, if further issue arise or something from here is missing please create new ones

[Yaron10]

Hello @chcg and @ClaudiaFrank,

👍
Great.
Thank you. I appreciate your time and work.

Should notepad.runMenuCommand("תצוגה", "עטיפת מילים") be working now? - I still get an error.
It's actually not important as you can use notepad.menuCommand.

[chcg]

@Yaron10 In this case it was a misunderstanding from my side. Thought just the wrong name
גלילת שורות
instead of
עטיפת מילים
caused the problem. So I will have another look at that.

Are you using version 1.1? From my tests it looks ok from console and script I think.

Or is your expectation that also
notepad.runMenuCommand("View", "Word wrap")
should work in Hebrew mode?

[chcg]

From within a script the encoding info is needed:

# -*- coding: utf-8 -*-
notepad.runMenuCommand("תצוגה", "עטיפת מילים")

[Yaron10]

Are you using version 1.1?

Yes, I am.

Or is your expectation that also
notepad.runMenuCommand("View", "Word wrap")
should work in Hebrew mode?

No. :)

---

# -*- coding: utf-8 -*-

👍
That works like a charm.

Thank you very much.