Little Dialog-wrapper for PythonScript

Michael Vincent

@Ekopalypse said in Little Dialog-wrapper for PythonScript:

a framework to get you started.

nice demo in WinDialog_tests_\test_win_dialog.py:

Cheers.

Alan Kilborn

Everyone tries to kill “cheesy UI”. :-(

( ref. example of cheesy UI: https://community.notepad-plus-plus.org/topic/24325 Apr 13, 2023, 4:00 PM )

Ekopalypse

@Alan-Kilborn said in Little Dialog-wrapper for PythonScript:

Maybe should add that to its readme.md.

Done, and the reason it works for you could be that you already have a notepad.hwnd attribute, which was recently introduced with PS 3.0.16.

Alan Kilborn

I wanted to use this in place of the “cheesy UI” in the script I linked earlier. When running that script, the first thing it prompts for is the regex and for that it needs an edit box so the user can supply it.

I hit a stopper right away as I don’t see an edit box type control in the “Little Dialog-wrapper”. @Ekopalypse, is this correct, there isn’t support for such a control?

Maybe the idea is to use notepad.prompt() for that, as it provides only an edit box, and then use your wrapper to gather other input? This is doable, but it breaks up the gathering of input into 2 stages when ideally it would all be on one input form. Granted, it IS done in 2 stages with the “cheesy UI” approach, but that whole thing is rather a hack.

Ekopalypse

@Alan-Kilborn said in Little Dialog-wrapper for PythonScript:

is this correct, there isn’t support for such a control?

That’s right, the idea was that you can use this “framework” to extend it to your needs.
For example, to create an edit control, you need to do the following steps.

create a file called e.g. NPPDIR\plugins\Config\PythonScript\lib\WinDialog\editbox.py
import the things this class needs from dialog_template.py, win_helper.py etc… (you may need to define, create some more functions here too)
create a class that inherits from Control, e.g. TextBox(Control)
create the class methods needed to interact with the control
make this available to the WinDialog object by adding it to the __all__ attribute of the __init__.py file
and import it from .editbox import TextBox.

That’s it, now you should be able to use it in a script.

Ekopalypse

This post is deleted!

Ekopalypse

And then I thought, what if … trailer … :-D

Michael Vincent

@Ekopalypse said in Little Dialog-wrapper for PythonScript:

And then I thought, what if … trailer … :-D

Oh no you didn’t …

… you did.

That’s AWESOME!

Cheers.

Ekopalypse

@Michael-Vincent

Thx, the only “issue” I see at the moment is how to name the instances of the automatically created controls.
In the example below you see names like button3 and syslistview322, which are basically the second and third parameters of the rc definitions combined.

rc = '''
1 DIALOGEX 10, 100, 250, 100
STYLE DS_SETFONT | DS_MODALFRAME | WS_POPUP | WS_CAPTION | WS_SYSMENU
CAPTION "Git Status"
LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL
FONT 19, "Ink Free"
{
   CONTROL "&OK", 3, BUTTON, BS_DEFPUSHBUTTON | WS_CHILD | WS_VISIBLE | WS_TABSTOP, 130, 78, 50, 11
   CONTROL "&Cancel", 4, BUTTON, BS_PUSHBUTTON | WS_CHILD | WS_VISIBLE | WS_TABSTOP, 187, 78, 50, 11
   CONTROL "", 1, EDIT, ES_LEFT | WS_CHILD | WS_VISIBLE | WS_BORDER | WS_TABSTOP, 3, 4, 242, 14
   CONTROL "", 2, "SysListView32", LVS_REPORT | WS_CHILD | WS_VISIBLE | WS_BORDER | WS_TABSTOP, 5, 20, 240, 48
}
'''

def on_cancel(wparam, lparam): ...

def on_commit(wparam, lparam): ...


dlg = create_dialog_from_rc(rc_code=rc)
# dlg.center = True
dlg.button3.callback = on_commit
dlg.button4.callback = on_cancel
dlg.syslistview322.intialize_needed = True
dlg.syslistview322.columns = ['Changed Files', 'Status']
dlg.syslistview322.rows = get_status()
dlg.show()

I don’t like this. I’m currently thinking about changing the CONTROL statement to something like this

   ...
   CONTROL_my_listview "", 2, "SysListView32", LVS_REPORT | WS_CHILD | WS_VISIBLE | WS_BORDER | WS_TABSTOP, 5, 20, 240, 48
   ...
dlg.my_listview.intialize_needed = True
dlg.my_listview.columns = ['Changed files', 'Status']
dlg.my_listview.rows = get_status()

which would not break the structure of the control statement, and looks nicer to me if referenced in the code.
A bit more effort to type, but I think it’s defensible.
If anyone has another idea, let me know.

PeterJones

@Ekopalypse said in Little Dialog-wrapper for PythonScript:

If anyone has another idea, let me know.

it sticks in my craw to have to manually edit the RC text. At some point, users may want to just read an external .rc file without having to edit it.

Since RC Files accept c-style comments, I might suggest a two-pronged approach

If a CONTROL line ends in a // ps.XXXX or /* ps.XXXX */ , then use the XXXX as the name
If not, then use the SysListView32_2 or similar (I would suggest an underscore separator between the two)

But that’s just my preference. Really, however you define it, I will end up accepting it as better than what we have now (especially if the EDIT control is implemented, as your trailer&example implies).

Actually, once you get it working sufficiently, I might recommend you submit a PR to see if PS3 will accept it as an additional top-level class (Notepad, Editor, Console, Dialog)

-----
edit: I have been informed I was confusing by saying it bothered me to have to edit the RC, and then suggested editing the RC. My implication, though it obviously wasn’t communicated properly, is that with a two-step process, you can edit the RC file to add a comment, to then be able to influence the naming convention for controls in Python Script. But if you don’t want to edit the RC file, you don’t have to, because if there aren’t comments matching the pattern, then it will fall back / default to using the control type and control number, which are always found in the RC file whether edited or not.

Michael Vincent

@PeterJones said in Little Dialog-wrapper for PythonScript:

it sticks in my craw to have to manually edit the RC text. At some point, users may want to just read an external .rc file without having to edit it.
Since RC Files accept c-style comments, I might suggest a two-pronged approach

If a CONTROL line ends in a // ps.XXXX or /* ps.XXXX */ , then use the XXXX as the name
If not, then use the SysListView32_2 or similar (I would suggest an underscore separator between the two)

Very much like that idea - using an .rc file as-is would be awesome! Adding a comment for better PythonScript naming is easy and won’t interfere with RC file format.

Cheers.

Ekopalypse

Using comments seems like a reasonable approach,
and I’ll use the one-line comment that needs to be
at the end so the location is known in advance.
The use of the underscore is also reasonable.
Reading rc files, especially those created by Visual Studio (VS), sounds good,
but you need to know that I don’t plan to write an rc compiler myself.
The word “simple” in the first post is not by chance, unfortunately ;-(.
The generated rc files support macros and preprocessor directives … which I’m not trying to implement,
as that might require loading additional header files to determine which value is actually set.
That is, if the rc file does not match the implemented parser logic, I leave it to the inclined user to implement it :-)
And right now my parser logic is REALLY simple :-D
As for a PS-PR, let’s see. I have something else in mind, namely that PS offers additional docked dialogs that can be created by a PS script.
That would then mean that you can really create plugin-like functionality with PS.

Alan Kilborn

@Ekopalypse said in Little Dialog-wrapper for PythonScript:

I have something else in mind, namely that PS offers additional docked dialogs that can be created by a PS script.
That would then mean that you can really create plugin-like functionality with PS.

This is intriguing but I’m curious how one aspect would work.

Currently it is “discouraged” (by PS itself) to attempt to run multiple scripts at the same time. If you had such a “docked dialog” open (I presume its controlling script would be “running”); would it still be possible to run other scripts, e.g. from the PS menu?

If the “docked dialog” were modal, then this isn’t a concern (because it wouldn’t be possible to get to the PS menu). But the current plugin approach to a panel in a docked dialog is that it is modeless…

Alan Kilborn

@Ekopalypse said in Little Dialog-wrapper for PythonScript:

Using comments seems like a reasonable approach,
and I’ll use the one-line comment that needs to be
at the end so the location is known in advance.

If one designs a dialog, then puts such comments in, THEN decides the UI needs more work…

Can the resource editing tool handle this, and KEEP the custom comments? Or would the comments be lost by such editing and need to be recreated when the revised dialog UI is ready for use again?

Ekopalypse

@Alan-Kilborn

Can the resource editing tool handle this

This depends on the tool you use, ResourceHacker doesn’t seem to be able to do this. But the idea is rather that you use the design tool until you are satisfied with the result and then copy the generated code into the Python script to reuse it.
If you need to add an additional control at a later time, then all you have to do is copy the newly generated line.

This is intriguing but …

Of course, these dialogs would not be modal and you have to be careful about the objects you create, i.e. don’t use these objects for something else or delete them, but that is already the case today as well.

Alan Kilborn

@Ekopalypse said in Little Dialog-wrapper for PythonScript:

If you need to add an additional control at a later time, then all you have to do is copy the newly generated line.

Sure, easy enough for one control, one line.
I was more thinking about how I tend to do things… on a greater than 1 line basis. :-)

but that is already the case today as well.

Today we don’t have to think about script concurrency, because PS mostly prevents it. Anyway, just thought I’d raise the question.

Ekopalypse

@Alan-Kilborn

oh no, it’s not a concurrency issue, it’s more like the callbacks we use today - event driven.
The script starts the dialog and ends. But the class that manages the dialog stays active until the dialog is closed.

Michael Vincent

@Ekopalypse said in Little Dialog-wrapper for PythonScript:

And then I thought, what if … trailer … :-D

Any alpha / beta version ready to test yet? I keep checking your repo but don’t see any new commits. I have a pretty easy use case in mind - an edit box with checkboxes for regex and case insensitive - all for a filter search lifted from @Alan-Kilborn 's work!

Integrating my supreme Notepad++ experience by standing on the shoulders of giants!

Cheers.

Ekopalypse

@Michael-Vincent

Hi, I have quite a lot on my plate privately at the moment, but I promise to upload a new version this weekend.
It’s actually going quite well and if you stick to what’s currently implemented, there shouldn’t be any difficulties. Sorry for the delays.

Ekopalypse

@Michael-Vincent

Repo has been updated, but be warned that I’m not completely satisfied yet, which means it’s not API stable. Further updates could break things that currently work.