Quote:
Originally Posted by KevinH
This is just a wag on my parts... but multiple threads are used to validate that a split is safe. Typically we need to collect/sync/reap all such threads before returning from the routine that spawns them.
Could extra threads being created to validate a book with many existing chapters somehow be related?
How many files/sections/chapters were in your book when it exhibited this behaviour? One big one being split? Or many already existing?
|
Both yesterday and today (it was the same book) there were already many existing files, one of which was being split. I had manually renamed most of them to make navigation easier for myself since I hadn't yet generated the toc and when the extra splits occurred I thought that all my manually-entered names had been replaced because suddenly I had 20 Section000N.xhtml instead of descriptive filenames, otherwise I might not have noticed it so quickly.
Quote:
Originally Posted by KevinH
I just spent time eyeballing this code and blockingMap is used with QtConcurrent so nothing will be returned until all threads except the main one are reaped/collected.
So the extra sections problem does not appear to be threading caused/related at all to me. So this brings us back to sticking keys I think or key related Qt bugs.
Kevin
|
Could a mouse create a "sticking key" situation ? From time to time my right mouse button seems unresponsive and for example I have to try more than once to rename / delete / whatever a file via the book browser but I am perfectly willing to accept that it's my mouse's fault, I was assuming that anyway for that behaviour because I'm about 85% sure I've noticed it outside of Sigil. Not sure how it would work for the extra splits because that is the left button (which doesn't seem sticky to me, that I've noticed), but if it is technically possible maybe that's the trouble, if no-one else has this problem.