I’m not sure whether you’re way overthinking this, or I’ve way underestimated the possibilities

I don’t know… You posed a fairly reasonable desire, and I put some reality onto some potential problems with getting to where you wanted to go.

Better to expose the “real world” of it, if it is known, before trying to solve the problem…, which we are now NOT going to do. :-)

here’s one scenario

I’m not sure whether you’re way overthinking this, or I’ve way underestimated the possibilities - probably both.

• user is seeing the first tab (leftmost) in that docked panel

Yeah, I hadn’t considered the possibility that other tabs might be present.

it depends upon how much work one would want to put into it.

Honestly, not that much in my case. This now looks like a big can of worms that I don’t want to open.

detect whether the PythonScript console is currently being displayed?

I requested such a capability HERE; thus far it appears the developers haven’t thought of it as a valuable enough feature to implement.

so that when I’m done, I can put things back the way they were before

I’m struggling a little with what this might mean, or at least the value in it.

If you are going to put something in the console window, then make sure it is shown to the user, what good is not showing it (e.g. “putting it back” if not-shown before) when the script has finished?

Maybe the circumstance is some Tk interactive UI, where, as the user interacts with it, the console might be shown with updated data at certain points, then when the Tk UI is exited, the desire is to no longer show the console (“put things back”).

And in the end, it may not be reasonable to put things entirely back. If, say, the PS console has never before been opened; here’s one scenario:

• PS console, when opened, will join a group of existing tabs in a docked panel (hasn’t been opened yet, though, in this scenario)
• user is seeing the first tab (leftmost) in that docked panel
• user commands that the PS console should open
• PS console opens as the fourth (and rightmost) tab in the docked panel
• user command that the PS console should close
• N++ restores the third (now rightmost) tab in the docked panel
• user wonders what happened as things aren’t quite “put back” (now looking at third tab contents instead of first tab)

In summary, it is all possible to achieve, but it depends upon how much work one would want to put into it. I could give some pointers on what I’d presume are the steps, but, as an in-depth treatment for this doesn’t interest me personally, I’m not going to code the whole thing up.

Are you saying that infamous help site is version shaming you?

Well, yeah, in at least one case where I tagged the post as python-2.7 instead of plain python - but worse than that, the question was closed by a bot that referred me right back to the answer that I was failing to understand.

PythonScript 2.0.0 using Python 2.7.18 is the most recent non-beta release of the plugin.

I’m aware of that - it just seems that the maintainer must be needing some help if it’s taking ~3 years to move everything to Python 3. (Unfortunately, as I explained about my Internet identity, I can’t offer much help in that regard, and there apparently aren’t many people who can.)

my first web search brought me to this

Yes, I’ve been bouncing around the pages linked from that page for several days now, but I’m no closer to adapting those examples to my situation. I’m sure part of the problem is that I’ve been coding since long before “object oriented” was a thing, and I still can’t wrap my Neolithic brain around “classes” and such - but another part is that those examples all seem to want to bring the exception (in my case, it’s not an error message) to the console, and I’m specifically looking to avoid spewing all that red text in the user’s face.

PythonScript […] should be able to properly throw an exception

Agreed. The Python docs say that Tkinter handles exceptions very differently than regular Python, but there’s no explanation of how a Python coder needs to adapt their code to the differences. (Maybe if I keep running into these walls a bit harder, I’ll start to enjoy it more. 😵‍💫)

so I don’t know what milestone it wants to hit before transitioning out of beta

I assume this one

Missing features:
    support for files with encodings that are not unicode

@PeterJones said in Using the PythonScript plugin to automate N++:

The overflowing stack of code writers don’t have such a restriction that I know of.

I guess I’m not looking for this knowledge in the right places, then.

Are you saying that infamous help site is version shaming you? Wow, they are less helpful than I remembered… but I’ve never tried asking a Python question there.

You complained to us about an old version of PythonScript in Plugins Admin, but the screenshot highlights that you’re actually wondering about the old version of the Python interpreter that’s part of PythonScript Plugin.

Okay, but putting that particular credit front and center made me question whether I’m really using Python 2 or 3 when running my “scripts”. (I know that I shouldn’t be calling them that, but I’m trying to go with the flow.)

That particular credit does quite explicitly tell you it’s Python 2. I am not sure how there could be any confusion about that point. What I was correcting is the implication that the PythonScript plugin using Python 2 somehow means that the plugin is old. It’s not. PythonScript 2.0.0 using Python 2.7.18 is the most recent non-beta release of the plugin.

But that doesn’t stop you from installing it manually.

I’m sure all the script kiddies that come here looking for you to write their regexps for them won’t bother to do that when you say “that’s too complex for a regexp - try this instead”. I’d rather design for the tools that others are most likely to actually have.

I understand that sentiment. I do hope that PythonScript 3 which uses Python 3 moves out of beta soon. The only reason I haven’t updated to it is for the reason you stated – it’s harder to convince a random user to install the beta version of the plugin, so when I develop a script here, I want to do it for the plugin that’s easiest for them to install. As @michael-vincent said, the “beta” version has been pretty stable for quite a while now, so I don’t know what milestone it wants to hit before transitioning out of beta.

@Alan-Kilborn said in Using the PythonScript plugin to automate N++:

It’s probably because instead of asking a pointed question, you just dump out a lot of code like you did above.

Okay, since you couldn’t find the pointed question, here it is: How do I get an exception raised in the context of Tkinter to be passed up to the calling routine the way it would be if Tkinter wasn’t involved? (My test code included samples of both situations, because I felt it was necessary to show both - but admittedly, that did make the code longer. Also, I now know not to expect an answer to this here, so I’ll keep looking elsewhere.)

I know nothing about Tkinter, so I cannot help you with those specifics. However, my first web search for “python 2.7 tkinter exception not being caught by my script” brought me to this as the first hit, and it seems to be describing the exact circumstance you are having. You might want to study those answers.

Further, though you are tired of hearing it, “how do I get an exception in Tkinter to pass all the way to my calling program in Python 2.7?” is a Notepad++-agnostic question, and off-topic here, even if the Pythonistas refuse to help you with it at other sites. If that’s the way they treat fellow python users, I’m glad Python isn’t my language-of-choice-or-requirement for the bulk of my programming life.

Gosh, even I didn’t want to look at that Tkinter junk–ugh. Sorry, I just don’t personally feel that Tkinter is good enough for, well, any use whatsoever.

And I don’t think abusing the text box capabilities of Python as a means to present options to the user is good enough for, well, any use whatsoever - so I guess we’re even there.

Notepad++ with the PythonScript Plugin was not intended as a super-fancy GUI-based-solution. PythonScript was meant to simply automate tasks. But presuming Tkinter is a standard GUI suite for Python which has been around since before Python 2.7, it should be able to properly throw an exception

[TBR] Yeah, but every time I try asking somewhere else they say “Old Python versions are off topic here”.

The overflowing stack of code writers don’t have such a restriction that I know of.

I guess I’m not looking for this knowledge in the right places, then.

You complained to us about an old version of PythonScript in Plugins Admin, but the screenshot highlights that you’re actually wondering about the old version of the Python interpreter that’s part of PythonScript Plugin.

Okay, but putting that particular credit front and center made me question whether I’m really using Python 2 or 3 when running my “scripts”. (I know that I shouldn’t be calling them that, but I’m trying to go with the flow.)

But that doesn’t stop you from installing it manually.

I’m sure all the script kiddies that come here looking for you to write their regexps for them won’t bother to do that when you say “that’s too complex for a regexp - try this instead”. I’d rather design for the tools that others are most likely to actually have.

@Alan-Kilborn said in Using the PythonScript plugin to automate N++:

It’s probably because instead of asking a pointed question, you just dump out a lot of code like you did above.

Okay, since you couldn’t find the pointed question, here it is: How do I get an exception raised in the context of Tkinter to be passed up to the calling routine the way it would be if Tkinter wasn’t involved? (My test code included samples of both situations, because I felt it was necessary to show both - but admittedly, that did make the code longer. Also, I now know not to expect an answer to this here, so I’ll keep looking elsewhere.)

Gosh, even I didn’t want to look at that Tkinter junk–ugh. Sorry, I just don’t personally feel that Tkinter is good enough for, well, any use whatsoever.

And I don’t think abusing the text box capabilities of Python as a means to present options to the user is good enough for, well, any use whatsoever - so I guess we’re even there.

When designing a program, I always start with the UI, and let that dictate the internal design decisions - because a useful program with an ugly or confusing UI simply won’t get used. The users that I used to design for would’ve rather had programs with rough edges - as long as they were hidden behind a pretty interface.

But that doesn’t stop you from installing it manually.

@TBugReporter
I’ve been running the beta 3.x versions with manual install each time a new beta is released since I started with PythonScript pre-2020 and have had no issues.

Caveat I use UTF-8 for all my files (made this my default Notepad++ setting) and use just US-English character codes.

Cheers.

every time I try asking somewhere else they say “Old Python versions are off topic here”.

It’s probably because instead of asking a pointed question, you just dump out a lot of code like you did above. Probably nobody wants to debug your code for you, so they come up with an excuse. Gosh, even I didn’t want to look at that Tkinter junk–ugh. Sorry, I just don’t personally feel that Tkinter is good enough for, well, any use whatsoever.

Exception handling in Python isn’t really specific to “older” Pythons. It seems that if you’re asking a general question about it in another forum, no one is going to say to you something about the age of your Python. But…you have to ask a reasonable question, and maybe you’re not to that stage yet.

why is the “Plugins Admin” version of PythonScript so old?

PythonScript 2.0 is NOT “old”. It may use a Python interpreter that is deemed “old”, but it does so for a reasonable reason. Python 2 and Python 3 differ in one huge way: How they treat strings. Python 2 doesn’t support unicode very well. Python 3 does. Because Notepad++ supports non-unicode encodings and always has, Python 2 is a great choice via PythonScript 2.0. If one isn’t going to use non-unicode encodings, then PythonScript 3.0 is probably the better choice. If the PythonScript developers figure out how to handle non-unicode encodings well in a Python 3 environment (that doesn’t like them), then PythonScript 2 could be phased out in favor of PythonScript 3.

I imagine it makes it more difficult to assist users when they’re likely not using the same version that you are.

Occasionally this is true. The “recommended” version is PS 2.0 and that’s what I use, but sometimes the scripts I share have some deficiency relating to unicode. One that comes to mind is a script that would open a filename in a text file, and that filename happened to include unicode characters. It was only a slight script adjustment, but I seem to recall the poster that complained about it went kind of nuts. Ah, well.

Yeah, but every time I try asking somewhere else they say “Old Python versions are off topic here”.

The overflowing stack of code writers don’t have such a restriction that I know of.

You complained to us about an old version of PythonScript in Plugins Admin, but the screenshot highlights that you’re actually wondering about the old version of the Python interpreter that’s part of PythonScript Plugin.

PythonScript is currently developing a Python 3 version of PythonScript Plugin, which is available for download in the PythonScript repository… But since it’s a huge project, it’s still considered alpha/beta and thus not in Plugins Admin yet. But that doesn’t stop you from installing it manually.

General Python exception handling questions are off-topic for this forum.

Yeah, but every time I try asking somewhere else they say “Old Python versions are off topic here”.

Maybe you could be more specific in this question, like exactly what you see and why you think it is old?

I’m still having trouble with exception handling

General Python exception handling questions are off-topic for this forum.

why is the “Plugins Admin” version of PythonScript so old?

If I look at it, it shows the current version. Maybe you could be more specific in this question, like exactly what you see and why you think it is old?

# -*- coding: utf-8 -*-
from Npp import MESSAGEBOXFLAGS

def main():

    print("Program started")
    tk_ok = False
    try:                                                    # see if we can do pretty dialogs
        import Tkinter as tk
        import qq                                           # DEBUG:  bogus name to force error triggering
        tk_ok = True
        print("Found tk")                                   # DEBUG
    except ImportError as e:                                # if not, tell user
        user_response = notepad.messageBox(
            ("Unable to import Tcl/Tk libraries.\n\n" + e.message), 
            "Missing Library",
            MESSAGEBOXFLAGS.OKCANCEL | MESSAGEBOXFLAGS.ICONWARNING)
        if user_response == MESSAGEBOXFLAGS.RESULTCANCEL:
            print("RESULTCANCEL loading Tkinter")           # DEBUG
            raise KeyboardInterrupt                         # closest exception to this condition
            while True:                                     # DEBUG:  wait for stop to happen
                print("Should have stopped!")
        elif user_response == MESSAGEBOXFLAGS.RESULTOK:
            print("RESULTOK loading Tkinter")               # DEBUG

    if tk_ok:
        my_dlg_bx = tk.Tk()

        def btn_cncl_action():
            print("Program CANCELLED")
            my_dlg_bx.destroy()
            raise KeyboardInterrupt                         # BUG:  doesn't work like above
            while True:                                     # DEBUG:  wait for stop to happen
                print("Should have stopped!")
        btn_cncl     = tk.Button     (
            my_dlg_bx,
            command     = btn_cncl_action,
            text        = "Cancel",
            width       = 10,
                                     )
        btn_cncl.pack    (padx   = 10,
                          pady   = 10,
                          side   = tk.RIGHT
                         )

        my_dlg_bx.attributes("-toolwindow", True)
        my_dlg_bx.attributes("-topmost", True)
        my_dlg_bx.resizable(width = False, height = False)
        my_dlg_bx.title("My Custom Dialog Box")
        my_dlg_bx.mainloop()
    # end "if tk_ok"

    print("Program should NOT get here if user clicks Cancel button")
    # do main program stuff here

    print("Program ended")                                  # DEBUG

main()

This code does as I expect - so long as the exception is in the testing for Tk. Comment out import qq, let Tk create and display “My Custom Dialog Box”, and click on its “Cancel” button, and a similar traceback appears in the console - but preceded by Exception in Tkinter callback. What can I do to get these exceptions both treated the same way? (And yes, I do realize that this sample code does nothing to actually catch the exception; I wanted to be sure it wasn’t my code that was eating it.)

And on a (probably) unrelated note, why is the “Plugins Admin” version of PythonScript so old? There are probably lots of people using it that don’t realize how outdated it is. Plus, I imagine it makes it more difficult to assist users when they’re likely not using the same version that you are.

Would you mind sharing?

Here’s NppHwnd.py:

# -*- coding: utf-8 -*-
from __future__ import print_function

from ctypes import (WinDLL, WINFUNCTYPE, create_unicode_buffer, byref)
from ctypes.wintypes import (BOOL, HWND, LPARAM, DWORD)

def find_npp_hwnd():

    user32 = WinDLL('user32')
    kernel32 = WinDLL('kernel32')

    WNDENUMPROC = WINFUNCTYPE(BOOL, HWND, LPARAM)

    our_pid = kernel32.GetCurrentProcessId()
    dw_process_id = DWORD()

    ubuff_size = 1024
    ubuffer = create_unicode_buffer(ubuff_size)

    notepad.hwnd = 0

    def foreach_window_to_find_npp(hwnd, __):
        if user32.IsWindowVisible(hwnd):  # maybe the check for being visible is not necessary?
            text_length = user32.GetWindowTextLengthW(hwnd)
            if 0 < text_length < ubuff_size:
                user32.GetWindowTextW(hwnd, ubuffer, text_length + 1)
                if u'- Notepad++' in ubuffer.value:
                    user32.GetWindowThreadProcessId(hwnd, byref(dw_process_id))
                    if dw_process_id.value == our_pid:
                        notepad.hwnd = hwnd
                        return False  # stop enumerating
        return True  # continue enumerating

    user32.EnumWindows(WNDENUMPROC(foreach_window_to_find_npp), 0)  # enumerate Desktop windows

    print('notepad.hwnd:', notepad.hwnd)

find_npp_hwnd()

Note that this script, like the original line of @Ekopalypse code ( notepad.hwnd = FindWindow(u'Notepad++', None) ), adds the hwnd member to the pre-existing notepad object.

Perhaps some explanation is in order: This script finds desktop windows with - Notepad++ in their titlebar. Since N++ always has this string of characters in its titlebar, it can be located in this manner. If there happens to be multiple instances of Notepad++ running, multiple windows will be located because they will all have the string in the titlebar – how to tell them apart? This script compares the process id of the located window to see if it is the same id as that under which the script is running; if so then we know we’ve located the desired N++ window.

this was only implemented for the console

Seems like you are right. At least the names of the files changed in the commit I mentioned above indicate that. I’ve missed that, sorry.

As far as I understand, this was only implemented for the console and is probably why the issue is still open.

the primary person maintaining PS seemed to have no clue as to why it would be valuable

PythonScript plugin v3.0.15 should contain that feature. See change log 3.0.14 to 3.0.15, commit 2c178d8 from 2022-11-21.

I have some more complicated code to find the correct N++

Would you mind sharing?

would be nice if PS would provide this, I know there is an open issue

Yes, HERE, but from the comment HERE the primary person maintaining PS seemed to have no clue as to why it would be valuable. :-(

It would be nice if PS would provide this, I know there is an open issue …

normaly yes - but 100% guaranteed - I assume no.

I asked because I have some more complicated code to find the correct N++, and I was wondering if it was necessary. I’ll keep it. :-)

normaly yes - but 100% guaranteed - I assume no.