PythonScript 1.0.7

  • Dave Brotherstone

    PythonScript 1.0.7 is out

    • Fix for replacing with extended Unicode characters with editor.rereplace() (thanks to David Instone-Brewer for reporting)
    • Several freeze issues corrected (thanks to skrell and Juergen Busch for reporting)

    Best bet is the MSI, especially if you've got no previous version, or still got 0.x. From 1.0.6 you can just update the PythonScript.dll if you like:


  • CFrank

    CFrank - 2014-08-08

    Hi Dave,

    wonder if you can gimme an advice how I can solve an issue with
    the python script dll and my local python installation
    (Python 2.7.8 (default, Jun 30 2014, 16:03:49) [MSC v.1500 32 bit (Intel)]).
    Compared to your version it uses an older compiler.

    What I did is
    - installed python 27 locally
    - copied the resulting python dll to the npp directory (as suggested)
    - enabled the checkbox "prefer installed python libraries ..."

    So far so good - worked great for a few weeks until I installed a new module called pyreadline.

    If I do the following on the "real" python console I don't have any problems

    >>> import pyreadline
    >>> pyreadline
    <module 'pyreadline' from 'D:\...\pyreadline\__init__.pyc'>
    >>> from pyreadline import unicode_helper as _unicode_helper
    >>> _unicode_helper
    <module 'pyreadline.unicode_helper' from 'D:\...\pyreadline\unicode_helper.pyc'>

    Note, I shortened the path to make it fit in one line

    If I try to do this within your python console I get two different errors.

    On every first try (means after npp has been started newly) I get a runtime error.
    Window pops up and tells me

     Program: D:\...\noteapd++.exe
     An application has made an attempt lo load the C runtime library incorrectly.
     Please contact the application's support team for more information

    The traceback from your console retuns this

    >>> import pyreadline
    Traceback (most recent call last):
      File "<console>", line 1, in <module>
      File "D:\...\pyreadline\", line 11, in <module>
        from . import unicode_helper, logger, clipboard, lineeditor, modes, console
      File "D:\...\pyreadline\console\", line 15, in <module>
        from .console import *
      File "D:\...\pyreadline\console\", line 610, in <module>
        msvcrt = cdll.LoadLibrary(ctypes.util.find_msvcrt())
      File "D:\...\ctypes\", line 443, in LoadLibrary
        return self._dlltype(name)
      File "D:\...\ctypes\", line 365, in __init__
        self._handle = _dlopen(self._name, mode)
    WindowsError: [Error 1114] A dynamic link library (DLL) initialization routine failed

    Every subsequent attempt results in

    >>> import pyreadline
    Traceback (most recent call last):
      File "<console>", line 1, in <module>
      File "D:\...\pyreadline\", line 11, in <module>
        from . import unicode_helper, logger, clipboard, lineeditor, modes, console
      File "D:\...\pyreadline\console\", line 15, in <module>
        from .console import *
      File "D:\...\pyreadline\console\", line 21, in <module>
        import pyreadline.unicode_helper as unicode_helper
    AttributeError: 'module' object has no attribute 'unicode_helper'

    I suspected a problem with the python moduels delivered by you and the
    ones installed locally, therefore I deleted the lib directory under
    D:...\Notepad++\plugins\PythonScript but the problem is still the same.

    Do you have any hint on this?

    Thank you

    • Dave Brotherstone

      My guess is that the module uses the runtime in such a way that it expects
      not to be mixed with a DLL that has been statically linked (ie
      PythonScript.DLL and notepad++.exe). Using both forms in one application is
      not advised, due to some (in my opinion) odd practices in the runtime
      itself. For instance, if you create a FILE* in a statically linked library,
      and pass it to a dynamically linked library, it won't work. It's a bit like
      running a red light when you mix the two, you're probably not going to
      crash, but under certain circumstances it could be deadly.

      In the case of python27.dll, it's not normally an issue, but there are
      obviously cases where things might not work. I wouldn't expect it to be
      the difference in compiler, at least not from the messages you're getting.

      It looks like the console is getting a reference to the runtime directly
      via ctypes. My guess would be that that is where the incompatibility lies.
      I'd like to try using a dynamically linked PythonScript.DLL to see if
      that's enough. I am, however, without proper PC access until towards the
      end of August, so I won't be able to try it out myself until then.

      Feel free to ping me if you've not heard anything by the end of the month!
      Sorry I can't do anything sooner.


  • CFrank

    CFrank - 2014-08-10

    Hi Dave,

    thx, for the answer. I will download the source and see if a dynamically linked
    Python script dll will solve the issue. Will keep you updated.
    Because I'm not a C programmer it might be that it will take until the end of august
    to get an answer ;-)

    Thank you


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks