Have a little patience. You already asked that question yesterday here. This is not paid support that is guaranteed to get a reply in 5 minutes or your money back; this is a Community of fellow users of Notepad++, and as such, any who read here regularly and answer questions do so solely on their free time, and they might not always have time to answer a specific question – especially one that might take more knowledge of a specific sub-tool of Notepad++.

Furthermore, this topic, “Little Dialog-wrapper for PythonScript” is focused on the Dialog Wrapper library for the PythonScript plugin; it briefly mentioned a script that was using that wrapper to help with the user interface, but the translation is not the focus of this discussion.

Your original question was in the right place. This question was not. I will try to give a brief answer in the other topic.

Is there some magic that needs to go in the startup.py to make PS3 see the user-lib directory for a portable installation?

This is now fixed in the 3.0.18 release.

Cheers.

And my specific fix:

Not needed anymore - 3.0.18 is released which fixes this bug.

Cheers.

Afraid it’s not that easy for me.

@mpheath points out it is indeed “that easy” if you know what you are doing and thank you @mpheath for showing me what to do:
https://github.com/bruderstein/PythonScript/issues/322#issuecomment-2041020162

And my specific fix:
https://github.com/bruderstein/PythonScript/issues/322#issuecomment-2045932479

Cheers.

It is a workaround until a fixed version is released.

Afraid it’s not that easy for me. I’ve added all my missing directories to make it “on par” with the previous version, but I still get a ImportError that I do not get in the previous version:

ImportError: DLL load failed while importing win32gui: The specified module could not be found.

Rest assured, the module is installed correctly. I can import it from my system Python and from PythonScript 3.0.17 commit right before the commit that breaks the path that I note in my issue. I’ve tried adding the specific directories to both sys.path and os.environ["PATH"] as described in https://github.com/mhammond/pywin32/issues/1730 and other Google results.

Cheers.

This is what I have been using in startup.py .

# Fix for sys.path bug in 3.0.17
if notepad.getPluginVersion() in ('3.0.17.0',):
    sys.path.append(notepad.getPluginConfigDir() + r'\PythonScript\lib')

It is a workaround until a fixed version is released.

I have stayed on 3.0.16 because of this and until this gets fixed.

Okay, switching to 8.6.4 portable with 3.0.16, I can get it to work using the user-lib instead of machine-lib. Thanks.

update: moved remainder of this post to the other Topic, since it’s translate.py specific, and this Dialog-wrapper Topic is already pretty full…

PythonScript 3.0.17

That’s “most likely” the problem. See here:

https://github.com/bruderstein/PythonScript/issues/322

I have stayed on 3.0.16 because of this and until this gets fixed.

Cheers.

After reading this post, I wanted to try out @Michael-Vincent’s translation script.

So I went to my portable that has PythonScript 3.0.17 installed, and tried to install based on the README instructions and tried to run the first example there. I get

Python 3.12.1 (tags/v3.12.1:2305ca5, Dec  7 2023, 22:03:25) [MSC v.1937 64 bit (AMD64)]
Initialisation took 406ms
Ready.
Traceback (most recent call last):
  File "C:\usr\local\apps\npp\npp862.ps3\plugins\Config\PythonScript\scripts\windlg_ex1.py", line 1, in <module>
    from WinDialog import Dialog, Button, create_dialog_from_rc
ModuleNotFoundError: No module named 'WinDialog'

In following the instructions, I put the WinDialog folder in the user directory ...plugins\Config\PythonScript\lib, as instructed. I can verify it’s there:

> cd plugins
> dir
 Directory of C:\usr\local\apps\npp\npp862.ps3\plugins

02/08/2024  01:28 PM    <DIR>          .
02/08/2024  01:28 PM    <DIR>          ..
02/08/2024  01:29 PM    <DIR>          ColumnTools
03/29/2024  09:36 AM    <DIR>          Config
01/14/2024  03:33 AM    <DIR>          doc
02/08/2024  01:09 PM    <DIR>          mimeTools
02/08/2024  01:09 PM    <DIR>          NppConverter
02/08/2024  01:09 PM    <DIR>          NppExport
02/08/2024  01:12 PM    <DIR>          PythonScript

> dir Config
 Directory of C:\usr\local\apps\npp\npp862.ps3\plugins\Config

03/29/2024  09:36 AM    <DIR>          .
03/29/2024  09:36 AM    <DIR>          ..
03/29/2024  10:27 AM               179 ColumnTools.ini
02/08/2024  01:12 PM               646 converter.ini
02/08/2024  01:07 PM           208,728 nppPluginList.dll
03/29/2024  10:23 AM    <DIR>          PythonScript

> dir Config\PythonScript
 Directory of C:\usr\local\apps\npp\npp862.ps3\plugins\Config\PythonScript

03/29/2024  10:23 AM    <DIR>          .
03/29/2024  10:23 AM    <DIR>          ..
03/29/2024  10:08 AM    <DIR>          lib
03/29/2024  10:25 AM    <DIR>          scripts

> dir Config\PythonScript\lib\WinDialog
 Directory of C:\usr\local\apps\npp\npp862.ps3\plugins\Config\PythonScript\lib\WinDialog

03/29/2024  10:08 AM    <DIR>          .
03/29/2024  10:08 AM    <DIR>          ..
03/29/2024  10:08 AM    <DIR>          controls
03/29/2024  10:08 AM             2,748 readme.md
03/29/2024  10:08 AM    <DIR>          resource_parser
03/29/2024  10:08 AM         2,145,865 test_dynamic_dialog2.gif
03/29/2024  10:08 AM    <DIR>          win_helper
03/29/2024  10:08 AM            22,893 __init__.py
03/29/2024  10:08 AM    <DIR>          __tests__

If I move WinDialog from the user directory to the machine directory (C:\usr\local\apps\npp\npp862.ps3\plugins\PythonScript\lib), then the script can see WinDialog and it loads and runs fine.

Is there some magic that needs to go in the startup.py to make PS3 see the user-lib directory for a portable installation?

Debug Info

Notepad++ v8.6.2   (64-bit)
Build time : Jan 14 2024 - 02:16:00
Path : C:\usr\local\apps\npp\npp862.ps3\notepad++.exe
Command Line : 
Admin mode : OFF
Local Conf mode : ON
Cloud Config : OFF
OS Name : Windows 10 Enterprise (64-bit)
OS Version : 22H2
OS Build : 19045.4170
Current ANSI codepage : 1252
Plugins : 
    ColumnTools (1.4.5.1)
    mimeTools (3)
    NppConverter (4.5)
    NppExport (0.4)
    PythonScript (3.0.17)

z = notepad.prompt(‘prompt text:’, ‘title bar of window’, ‘’)

Works perfectly. Much appreciated.

I need to pass integer argument to the Python script I run… Does it make sense to use this wrapper or is it … overkill because there is an easier way…?

It sounds like it would be overkill, but only you can judge that.

About the simplest way to achieve what you are asking for is:

z = notepad.prompt('prompt text:', 'title bar of window', '')
if z is not None:
    z = int(z)
    print(z)

which will give you a (no frills) window to enter your integer into:

Good afternoon,

I would appreciate if you could give me a word of advice.

I wonder if solution of this thread can help me to solve the following task: I need to pass integer argument to the Python script I run in N++ with PythonScript. Does it make sense to use this wrapper or is it an overkill because there is an easier way to do this?

In __control_template.py, at the bottom, add two member functions to the Control class:

def enable(self, e : bool) -> bool: return True if WinDLL('user32').EnableWindow(self.hwnd, e) else False

def isEnabled(self) -> bool: return True if WinDLL('user32').IsWindowEnabled(self.hwnd) else False

And of course, near the top of the file:

from ctypes import WinDLL

I assume this was the use-case for you wanting to capture the ESC / X events

My points about “modeless” and “easier saving of settings” were totally separate.

I wasn’t really saying that the dialog should truly be “modeless”, because if it were, users would attempt to run other scripts after refocusing the editing window (leaving the dialog open), and PythonScript, presumably for good reasons, disallows running a second script while a first is running.

So my thinking was the dialog script could end when focus is lost, to be restored when next invoked. (Ah, okay, I see the relationship of “saving the settings” – but truly, this was an earlier, separate point).

I might recommend seeing if you can get on-changed events for the individual settings controls, and have them save their settings

Sure. Again, my earlier point was that this is “drudge work”. I have to have a “click” event on every control, even one that normally doesn’t need one, just for saving its state?? How about just a single function that gets called, whenever the dialog is about to close, by any means, that allows me to do “cleanup”, be it saving settings or something else?

But until I switch over to PS3 …

I decided to make the switch recently, although I still have to sort out some things that don’t work in scripts I had totally working under PS2.

In general, I think it is time to move forward on this. PS3 may never come out of “alpha”, because what keeps it there (lack of old encoding support) doesn’t seem to get worked on.

It seems reasonable that the PS developers make v. 3.x the one that Plugins Admin installs, but keep 2.x around for those that use scripting with dated encodings. Or heck, even make BOTH PS3 and PS2 installable via Plugins Admin.

My very first script using this wrapper is HERE !!

And in chat, he asked me to give it a test drive.

From the user perspective, I was able to follow the instructions on @Ekopalypse’s GitHub page to get the WinDialog directory installed in my instance, and @Alan-Kilborn’s instructions to run his wrapper. So “yay” for sufficient “installation” instructions on both. :-)

About the only annoying thing is that the dialog is modal, i.e., one can’t switch between it and the Notepad++ editor window. This is annoying because one can do this with Notepad++'s Find window, and thus one gets used to this behavior.

Indeed. Even after having read this paragraph, and knowing that it was modal, I still tried to change my selection in the editor without closing the dialog. So yes, having a modeless option for dialogs would definitely help with the user interface.

Maybe another suggested extension is that if the dialog (is made modeless) and loses input focus, the script ends and the dialog disappears. Sure, the user would have to restart the script (via assigned keycombo) after working in the editor window, but this isn’t too bad. The restarted script would pick up right where the closed one was (with all settings intact).

Ah, I assume this was the use-case for you wanting to capture the ESC / X events <update>-- whoops, left that sentence hanging, without explaining that I meant that I thought you wanted it to be able to save settings, without having an OK button. I might recommend seeing if you can get on-changed events for the individual settings controls, and have them save their settings, whether or not OK (or, in your case, Count) is eventually pressed</update>

(And sorry, Alan, I know you were encouraging me to comment on the LittleDialogWrapper aspects as well – presumably from a developer perspective – to see if I could put it through more paces. But until I switch over to PS3 whenever it’s out of alpha, I’m not likely to incorporate LittleDialogWrapper into any of my scripts, because my PS installation is going to stay at whichever can be easily found in Plugins Admin, so that when I’m trying to help users with PS solutions, they won’t have an extra step of installing the alpha version of the plugin manually, or so I don’t have to go switch to a different instance of Notepad++ compared to my normal workflow. So all I’ve got for now is what I said in April, and my brief user-perspective comments in this post.)

I think it turned out pretty well and puts this wrapper through its paces. :-)

About the only annoying thing is that the dialog is modal, i.e., one can’t switch between it and the Notepad++ editor window. This is annoying because one can do this with Notepad++'s Find window, and thus one gets used to this behavior.

Maybe another suggested extension is that if the dialog (is made modeless) and loses input focus, the script ends and the dialog disappears. Sure, the user would have to restart the script (via assigned keycombo) after working in the editor window, but this isn’t too bad. The restarted script would pick up right where the closed one was (with all settings intact).

I meant an optional user (the programmer-user) function that gets called when the dialog is closing, by whatever means. Then there’s a chance to do things at that point, much like, but the opposite of initialize(). Maybe I will think about working on that kind of thing, along with enabling/disabling of controls.

I don’t seem to understand your use case.

If I want to know if a user either pressed ESC or clicked close_X to simply exit the dialog without anything being triggered by the dialog, then I would start the dialog with a variable has_been_cancelled=True and override it with the click event of the “normal” exit_dialog_button.

If that’s not what you’re looking for, maybe you can specify a simple scenario of what should be handled?

They get saved.

It’s not what I was truly getting at, but I understand how you’ve made it work. Thanks.

That’s why I specifically asked MV “…if user presses Esc to close the dialog, or presses the red X in the title bar of the dialog…”

They get saved. That’s why I use a return class object that’s part of the main script. So in the example I provided, I want to remember the setting for “ignore case” and “regex” so the checkboxes have an onClick event that toggles the boolean value stored in the return class.

    def on_case(self):
        self.ret.IGNORECASE = not self.ret.IGNORECASE

    def on_regex(self):
        self.ret.REGEX = not self.ret.REGEX

That happens whenever the users clicks the checkbox. So if they later just press ‘Esc’ or red ‘X’, the value has already been stored and then next time it launches, it is checked (or unchecked) appropriately in the initialize().

Cheers.

BTW, I sort of missed this at first from the github page:

help(WinDialog)

I guess I’m just not used to documentation being provided in only this way, at least not any more. It’s totally fine, though, just maybe not super obvious for a newbie (would there be any newbies wanting to experiment with LDW??).

So maybe I’ll offer this on the off-chance that a newbie is reading; this is what I did to make it easier to refer to (note: nothing rocket sciencey here…):

• go to PythonScript console window area, right-click, and choose Clear from the popup menu
• at the >>> prompt, type import WinDialog and press return
• type help(WinDialog) and press return
• right-click again and choose Select All and then press Ctrl+c
• create a new tab in Notepad++ and paste there
• save the tab for later reference

… use the control events to get the values you need.

Sure, but that’s the obvious case.

That’s why I specifically asked MV “…if user presses Esc to close the dialog, or presses the red X in the title bar of the dialog…”

As far as I can tell, and yes I’ve read some of the docs now :-), these aren’t capturable events?

You have an initial state when you start the dialog and from there I would use the control events to get the values you need. Something like

from WinDialog import Dialog, CheckBoxButton
from WinDialog.controls.button import BST

class Example(Dialog):
    def __init__(self):
        super().__init__(size=(100, 100))
        self.counter = 0
        self.btn1 = CheckBoxButton(title='Click me', position=(35, 40), size=(50, 14))
        self.btn1.onClick = self.on_click
        self.show()

    def initialize(self):
        self.btn1.setCheckState(BST.CHECKED)
        
    def on_click(self):
        self.counter += 1
        
e = example()
print(e.counter)