Posted by: vbr | Date: 2017-03-02 12:50 | IP: IP Logged
thanks for the further improvments of the PSPad 5 version!
I'd like to report some problems I just noticed (PSPad 5.00, build 68; win7):
Catching output of the compiled scripts (python in this case) seems to only work for the first call after starting the program.
after that it gets blocked somehow -
If I use the "compiler" within the highlighter settings - File - Compile (Ctrl + F9), the menu item gets disabled after the first call,
there is no visible error prompt, but the program itself then cannot be closed properly (only with process manager).
If I use the same "compiler" in a Favourite - tool panel with the same setting (for catching the output), an error message is displayed after the second call:
PSPad .exe - application error:
DosCommand still running
The program stays partly responsive, but it cannot be closed properly like in the previous case.
The actual "python" subproces however, seems to be closed after finishing (as shown in Process Explorer).
If the compiler or the tool-panel are configured for not catching the ouput, everything works ok.
The output itself is trivial, only a simple number is printed.
Another problem I found is (un)commenting the code.
A minor glith regards the language settings -
out of curiosity, I tried to switch between several languages of the gui, and even after switching back to Czech and saving the options, the settings pane "Hexa editor" stays in the previously selected language.
This is corrected with a restart of the program.
The last observed bug is rather exotic and probably cornercase:
It happens if PSPad 5 is running and PSPad 4 is invoked to open some file from a file manager - both versions are configured to only allow one instance of the editor.
In this case PSPad 4 closes immediately and somehow tries to pass the file, to the running PSPad 5, however, only an empty tab is opened, with a strange filename consisting of Chinese characters (the directory path, however, is correct). Apparently, there are some differences in bytes decoding between thes versions, but both use the same mechanism for determining the running program instance.
I guess, if the versions cannot "understand" each other in this case, it is reasonable to allow both versions to run, even with the "single instance" setting.
(That said, I really like the progress with this new version, e.g. the encoding handling etc.
Thanks and regards,
Posted by: pspad | Date: 2017-03-03 09:59 | IP: IP Logged
Catching output: fixed, include Command window
Settings menu/ hex edit page: fixed. There was problem with Czech localization file
Problem using old/new PSPad version together:
Case when old PSPad is associated to open file and new PSpad is running. When you open file, e.g. in explorer, windows starts new PSpad instance (old one). This instance sends message into new instance with file as parameter. Old PSPad encode file name into UTF-8, new PSPad uses unicode string in message format. This causes wrong title.
I don't think it worth to handle it.
Posted by: vbr | Date: 2017-03-03 12:22 | IP: IP Logged
Excellent, thanks for the quick fixes!
The last issue isn't worth some expensive fixes in my view too.
It might be possible to check for already running instances with different registry keys in the new version (if this is done via registry).
That way the pspad instances from different versions wouldn't "see" each other and wouldn't attempt to pass the files.
However, it is definitely not worth some hassle, if there is some more complex handling.