Sigil-1.9.0 Release

[TheLocalPooh]

Hi, DiapDealer,

The requested "api-ms-win-core-path-l1-1-0.dll" is NOT part of the content of your MSVCR package.

My installed MSVCR is newer than your package, so the install don't launched.

This dll is linked as import into ..\Sigil\python39.dll. As I know, Win7 don't support Python above v3.8x :-(

> Forever's a very long time, by the way.
I'm an old man, my way there is not too long...

Thanks for Sigil, thanks for your reply
TLP

[DiapDealer]

Sorry. I was unaware of the Python 3.9 limitation. We might have been able to wait a little longer, but that Python update was going to happen eventually. Just like the update to Qt6 is going to happen soon.

It seems to be an esoteric Python.org decision to not support Python3.9+ on Win7 (there's nothing technically preventing it from working). I'll see how difficult it will be to build a version of Python3.9.9 that will work on Win7, but no promises. Especially if the move to Qt6 ends Win7 support as well.

[polinom11]

Installed version 1.9.0, does not start and gives an error that the dll is missing: api-ms-win-core-path-l1-1-0.dll . Tried reinstalling Visual C++ 2015 and update KB2999226-x64, didn't help. Installed Win 7 x64

[KevinH]

Perhaps this dll based on Wine code may be useful ...

https://github.com/nalexandru/api-ms-win-core-path-HACK

He had released binaries that users can install.

And here is a set of forks for cpython to work on Win 7 (including binary releases of python 3.9.9):

https://github.com/NulAsh/cpython/releases

[DiapDealer]

Yeah, It looks like Python.org's 3.9.9 is a hard no on Windows 7. I think I recall something to that effect, but the constant three platform, Qt vs Python, vs Visual Studio, vs extra Python modules versions/compatibility dance just finally got the better of me. Sigil 1.9.0 should be configured NOT to install on Windows 7. That's on me. Sorry folks.I

I'd like to fix it if I can, but as I mentioned previously, I'm pretty sure Qt6 will just bring support for Win7 to a screeching halt again.

I might be able to set up an unofficial fork of Sigil that could perform fully-unattended, automated releases of Sigil with Python 3.8 and Qt5, but eventually, third-party plugins will probably stop supporting Qt5 too.

Support of Sigil on Win7 was always going to come to an end, but I'm terribly sorry it wasn't more graceful (with advance notice).

[DiapDealer]

Originally Posted by KevinH

Perhaps this dll based on Wine code may be useful ...

https://github.com/nalexandru/api-ms-win-core-path-HACK

He had released binaries that users can install.

And here is a set of forks for cpython to work on Win 7 (including binary releases of python 3.9.9):

https://github.com/NulAsh/cpython/releases

Looks interesting. I've got a Win7 hard drive around somewhere I can mount up and test on.

[DiapDealer]

In the meantime ... I've added appropriate warning notices to the github and Sigil website's 1.9.0 release announcements.

[jugaor]

Originally Posted by KevinH

Perhaps this dll based on Wine code may be useful ...

https://github.com/nalexandru/api-ms-win-core-path-HACK

He had released binaries that users can install.

Hi. Thank you very much for this new version!

Windows 7-x64 also here.
I confirm that by copying the file 'api-ms-win-core-path-l1-1-0.dll' (from KevinH's first link) to the program folder, Sigil 1.90 runs without problems (so far).

Download the .zip from the page; unzip it; copy the appropriate dll (in my case, x64) to the 'Sigil' folder inside 'Program Files' (it may ask for authorization); and run it normally.

I've tried some pre-installed plugins - they seem to be fine.

[jugaor]

Copying the dll to "C:\Windows\System32" also works, as expected.
(Soon I will test Python 3.9 !!!)

[polinom11]

Originally Posted by jugaor

Hi. Thank you very much for this new version!

Windows 7-x64 also here.
I confirm that by copying the file 'api-ms-win-core-path-l1-1-0.dll' (from KevinH's first link) to the program folder, Sigil 1.90 runs without problems (so far).

Download the .zip from the page; unzip it; copy the appropriate dll (in my case, x64) to the 'Sigil' folder inside 'Program Files' (it may ask for authorization); and run it normally.

I've tried some pre-installed plugins - they seem to be fine.

I tried copying the dll to the Sigil folder. Now gives this message when trying to run the program: "Точка входа в процедуру pathCchSkipRoot не найдена в библиотеке DLL api-ms-win-core-path-l1-1-0.dll"

[KevinH]

Based on translate on my iPad that means:

The entry point to the pathCchSkipRoot procedure was not found in the DLL api-ms-win-core-path-l1-1-0.dll

You might want to post an issue on their github site to see what the developer of the api-ms-win-core-path replacement says.

According to the code there, they do implement PathCchSkipRoot.

Perhaps you are not using the very latest or correct version for your system?

[Ashjuk]

Not sure if this bug applies just to me, or if anyone else has experienced this issue.

For the first time today I used version 1.9.0 and all seemed OK until I tried a search and replace. On completion of the S&R operation focus is taken away from the file I was working on and switches to the first file listed in Book Browser (cover.xhtm) in my case.

It makes no difference whether or not the file is open for editing - I tried it with cover closed and any search and replace operation opens the file and switches focus to it.

I never experienced this with 1.8, and it's bit annoying to have to keep switching back to the file I am working on.

Any ideas?

[KevinH]

Yes, this is new search behaviour as described in the release notes.

If your Find and Replace is set to any group of files (all, selected, or tabbed html for example) and you start a new search by:

a) hitting the new Restart button or
b) changing the targeted files, or
c) changing the actual find string

search will then start with the first file of the group and proceed from there in proper order. Wrap is no longer meaningful for targeted groups of files.

If your search target is Current File and not a group of files, then search and Wrap will act as it did before.

So remember to set your search target appropriately.


This change prevents searches from being incomplete (files left out inadvertently), and the manual Restart button allows you to override things to force the search order to begin again from the first file of the group.

This change also allows users of Saved Searches to use Saved Search Groups to skip a replacements at will and still continue with the search group. This was one of the To-Do items put forward by users that makes Saved Search Groups much faster to use safely.

So please set your Search Target files appropriately as new searches will process them in that order (selected, tabbed, or all).

It is a change, but one that allows heavy duty lifting to be done more easily via Saved Search Groups which now can control the search target via Controls.

Hope this helps.

Originally Posted by Ashjuk

Not sure if this bug applies just to me, or if anyone else has experienced this issue.

For the first time today I used version 1.9.0 and all seemed OK until I tried a search and replace. On completion of the S&R operation focus is taken away from the file I was working on and switches to the first file listed in Book Browser (cover.xhtm) in my case.

It makes no difference whether or not the file is open for editing - I tried it with cover closed and any search and replace operation opens the file and switches focus to it.

I never experienced this with 1.8, and it's bit annoying to have to keep switching back to the file I am working on.

Any ideas?

[Ashjuk]

Thanks for the reply, Kevin.

I think I understand what you are saying.

Personally I think I prefer the old way of working where focus stayed with the file I am working on, but I am sure there are very good reasons for adopting this approach.

No doubt I will get used to it in time.

[KevinH]

It will still do that, just set your target to current file (or have it be the first selected file in BookBrowser, or the first file opened in a tab).

But if you give it a new search and tell it to target all html files (or any group of files) it will start at the beginning of the group and work its way to the end, consistently until you give it a new search to perform.

If you like working with multiple searches in one file at a time, the set your target to Current File and check wrap as needed.

The target group is now important for how searching works when a new search is started by any of the a), b), or c) methods given above.

Give it a try. It will become second nature soon enough. At least it did for me. It also makes running entire SavedSearch groups and skipping occasional replacements that you do not want but match the search, possible and easy.

Originally Posted by Ashjuk

Thanks for the reply, Kevin.

I think I understand what you are saying.

Personally I think I prefer the old way of working where focus stayed with the file I am working on, but I am sure there are very good reasons for adopting this approach.

No doubt I will get used to it in time.