Anonymous ID: be34ff Feb. 6, 2020, 12:24 p.m. No.8051609   🗄️.is 🔗kun   >>2304

>>8038621

There's an updated version of QCV up on mega.nz.

Tried to fix the issue acc. to what changes I see in the HTML source. Not knowing what CM did and as mentioned before, it could depend on how the source HTMLs were downloaded.

I didn't yet give it exhaustive testing, so would appreciate if you'd let me know in case your problem still occurs.

Have put an extra file "old_for_testing.html" in the zip for those who'd like to test the update function.

o7

Anonymous ID: be34ff Feb. 6, 2020, 2:11 p.m. No.8052745   🗄️.is 🔗kun   >>2818

>>8052304

It's been more than 30 breads with the changed parameter syntax, then 8048881.html & 8050345.html had it like it was before …. Kek!

So I really have no idea if it's an error or some change to be made permanently.

Happens with me (firefox) when saving html only. When saving "complete page" it seems to be ok.

 

Adding ".htm" to the extensions looked for is done here already – it's so easy an enhancement, until I upload a new version you can do it in your sources:

In file "qclockdialogs.cpp" line 1283 & line 2151, you will find "(*.html)".

Changes those two instances to

"(.html .htm)" – i.e. add a simple space after ".html" and add ".htm" inside the brackets, save and re-compile and that's it.

o7

Anonymous ID: be34ff Feb. 12, 2020, 6:24 a.m. No.8112471   🗄️.is 🔗kun   >>2967

>>8112037

>I saw where you tried to remedy that in the code, calling out both cases (double-quotes or not) several times

Thanks. Hope it's fixed now.

Seems to be a peculiarity in QRegExp that "[0-9]*" means 0 or all matches, so it was triggered even when the quotes are there.

Changed it to "[0-9]+" which means 1 or all matches.

HTML format as of late is back to normal, btw. So the quotes are back with all parameters, which caused the seg-fault also for me.

Anonymous ID: be34ff Feb. 12, 2020, 1:41 p.m. No.8116718   🗄️.is 🔗kun   >>6962 >>6996 >>6409

>>8112967

Yw, haven't done much though. Regexes indeed are a bit weird sometimes though, but in the end it was only 'cause I didn't check it thoroughly before using it in the program.

I certainly wouldn't wanna work without them …

 

>>8113765

Here's an example what it would look like acc. to what you suggested before (pic1).

Let me know which one you'd like better.

 

What do other clockfags think about it, btw?

If there are no objections I'd change the scripts for both blanks accordingly and in the future post them with the years marked in any of the suggested ways.