Little Dialog-wrapper for PythonScript

Ekopalypse

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.

Ekopalypse

@Michael-Vincent

There was a typo that prevented the dialog from being created.
I should have tested it before, sorry. Is fixed now.

Michael Vincent

@Ekopalypse

Great! I have my small example:

from WinDialog import Button, Dialog, CheckBoxButton, Label, TextBox
from WinDialog.controls.button import BM, BST
from WinDialog.win_helper import SendMessage

user_input = ''
REGEX      = True
IGNORECASE = True

class FilerLinesEditDlg(Dialog):
    def __init__(self):
        super().__init__(            title='Filter Lines Editing', size=(250, 75), center = True)
        self.label  = Label(         title='Filter for:'         , position=(10, 12),  size=(30, 11) )
        self.edit   = TextBox(                                     position=(45, 10),  size=(195, 14) )
        self.case   = CheckBoxButton(title='Case Sensitive'      , position=(45, 30),  size=(80, 14)  )
        self.regex  = CheckBoxButton(title='Regular Expression'  , position=(145, 30), size=(80, 14)  )
        self.ok     = Button(        title='OK'                  , position=(130, 55), size=(50, 11)  )
        self.cancel = Button(        title='Cancel'              , position=(187, 55), size=(50, 11)  )

        self.ok.on_click     = self.on_ok
        self.cancel.on_click = self.on_cancel
        self.case.on_click   = self.on_case
        self.regex.on_click  = self.on_regex
        self.show()

    def initialize(self):
        global IGNORECASE
        global REGEX
        SendMessage(self.case.hwnd, BM.SETCHECK, IGNORECASE, 0)
        SendMessage(self.regex.hwnd, BM.SETCHECK, REGEX, 0)

    def on_ok(self):
        global user_input
        user_input = self.edit.get_text()
        self.terminate()

    def on_cancel(self):
        global user_input
        user_input = None
        self.terminate()

    def on_case(self):
        global IGNORECASE
        check = SendMessage(self.case.hwnd, BM.GETCHECK, 0, 0)
        if check & BST.CHECKED:
            IGNORECASE = True
        else:
            IGNORECASE = False

    def on_regex(self):
        global REGEX
        check = SendMessage(self.regex.hwnd, BM.GETCHECK, 0, 0)
        if check & BST.CHECKED:
            REGEX = True
        else:
            REGEX = False


FilerLinesEditDlg()

print(f"User:  {user_input}")
print(f"Case:  {IGNORECASE}")
print(f"Regex: {REGEX}")

It seems to run correctly and prints status to the PythonScript console. I plan to integrate this into a larger script.

I’m not sure I did the checkbox stuff correctly. It works, but I had to import some extra classes and the SendMessage function from your helper library. Did I do this right?

Cheers.

Ekopalypse

@Michael-Vincent

You can do it this way, but I personally would put the globals as attributes in the class to avoid globals in the first place.
For the GETCHECK, because the checkbox is a “boolean” value, I would do something like: …

...
    def on_case(self):
        self.IGNORECASE = not self.IGNORECASE
...
dlg = FilerLinesEditDlg()

print(f"User:  {dlg.user_input}")
print(f"Case:  {dlg.IGNORECASE}")
print(f"Regex: {dlg.REGEX}")

As for the SETCHECK, the SendMessage function is currently required.
The next version, uploaded this weekend, will have a checkbox button method setCheckState (that’s the same kind of naming PS does … so it seems to make the most sense, right?). And now that I think about it, getCheckState makes sense too because of the 3-state checkboxes. Also, the next version will be able to handle IDOK and IDCANCEL, which means you can close a dialog with ESC and trigger the execution of the edit with ENTER.

Michael Vincent

@Ekopalypse said in Little Dialog-wrapper for PythonScript:

will have a checkbox button method setCheckState (that’s the same kind of naming PS does … so it seems to make the most sense, right?). And now that I think about it, getCheckState makes sense too because of the 3-state checkboxes. Also, the next version will be able to handle IDOK and IDCANCEL, which means you can close a dialog with ESC and trigger the execution of the edit with ENTER.

This just keeps getting better!

I updated the globals to a return class that I pass in and then examine on output. The issue is I want this as a prompt in a larger already existing PythonScript and class so the “globals” are just globals in this example - in my project, they are attributes of the existing class that the dialog will need to know to set on startup and then return in case of modifications in the dialog. The globals were just a “cheat” way to illustrate a “complete self-contained example” to post here. But point taken - I am avoiding globals in the finished product.

The on_case recommendation works as well very nicely and certainly simplifies code - removes the need for me obtaining BM.GETCHECK as well.

It’s Memorial Day weekend in the States so I’ll be stepping away from all this for the long weekend. I do hope you take time to relax this - and any weekend for that matter. I’m in no rush for the updates, but will keep checking back the repo to see when they in fact do arrive.

UPDATE:
The updated script from above with fixes discussed. Also add the c#_ prefixes to the controls to force the TABSTOP order - seems to be alphabetical:

from Npp import editor

#----------

from WinDialog import Button, CheckBoxButton, DefaultButton, Dialog, Label, TextBox
from WinDialog.controls.button import BM
from WinDialog.win_helper import SendMessage

#----------

class Returns(object):
    def __init__(self, U=None, I=False, R=False):
        self.user_input = U
        self.IGNORECASE = I
        self.REGEX      = R

class FilerLinesEditDlg(Dialog):
    def __init__(self, ret=Returns()):
        super().__init__(               title='Filter Lines Editing', center = True,      size=(250, 75) )
        self.label     = Label(         title='Filter for:'         , position=(10, 12),  size=(30, 11)  )
        self.c2_edit   = TextBox(                                     position=(45, 10),  size=(195, 14) )
        self.c3_case   = CheckBoxButton(title='Case Sensitive'      , position=(45, 30),  size=(80, 14)  )
        self.c4_regex  = CheckBoxButton(title='Regular Expression'  , position=(145, 30), size=(80, 14)  )
        self.c1_ok     = DefaultButton( title='OK'                  , position=(130, 55), size=(50, 11)  )
        self.c5_cancel = Button(        title='Cancel'              , position=(187, 55), size=(50, 11)  )

        self.ret = ret

        self.c1_ok.on_click     = self.on_ok
        self.c5_cancel.on_click = self.on_cancel
        self.c3_case.on_click   = self.on_case
        self.c4_regex.on_click  = self.on_regex

        self.show()

    def initialize(self):
        self.c2_edit.set_text(self.ret.user_input)
        SendMessage(self.c3_case.hwnd,  BM.SETCHECK, self.ret.IGNORECASE, 0)
        SendMessage(self.c4_regex.hwnd, BM.SETCHECK, self.ret.REGEX, 0)

    def on_ok(self):
        self.ret.user_input = self.c2_edit.get_text()
        self.terminate()

    def on_cancel(self):
        self.ret.user_input = None
        self.terminate()

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

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

#-----^^^^-----

user_input = editor.getSelText()
IGNORECASE = False
REGEX      = True

#-----vvvv-----
ret        = Returns(user_input, IGNORECASE, REGEX)
FilerLinesEditDlg(ret)
user_input = ret.user_input
IGNORECASE = ret.IGNORECASE
REGEX      = ret.REGEX
#-----^^^^-----

if ret.user_input is None:
    print("EXIT")
else:
    print(f"User:  {user_input}")
    print(f"Case:  {IGNORECASE}")
    print(f"Regex: {REGEX}")

Cheers.

Ekopalypse

@Michael-Vincent

Don’t worry, the weekends are for family commitments. I’ll just publish what I’ve managed to do during the week.
As for the WS_TABSTOP, I thought that the order of creation of the controls determines the order … I’ll have to check that.

Alan Kilborn

@Michael-Vincent said in Little Dialog-wrapper for PythonScript:

Also add the c#_ prefixes to the controls to force the TABSTOP order

Confused me at first; I’m wondering what the heck C# has to do with this…

Finally I notice this is what you meant:

Ekopalypse

@Michael-Vincent

The issue is here. dir always returns a sorted list.

Replacing it with for item in self.__dict__.keys(): seems to behave as expected. The first control created that has the style ws_tabstop gets the initial focus.

Ekopalypse

First beta version released.
Sorry for breaking existing code, but from now on this should not happen.

The current state of the project is what I currently support.
If you encounter issues where the dialog box or controls do not work as described or advertised,
please report them by submitting a “git issue”. I will diligently investigate the issue and work on a solution.

However, please note that any requests for additional functionality beyond what is currently offered will be considered feature requests.
While I appreciate user feedback, I prioritize implementing features that benefit me personally and align with the overall goals of the project,
which is to be a simple wrapper over DialogBoxIndirectParam Windows API.
Thank you for your understanding."