Topics last modified problem in Link List

[Olivier Beltrami]

Hello,

I wanted to display a list of the topics last updated in the past 30 days in my help file and used the options of the first image below, expecting to get the list as shown in H&M10, as can be seen in the second image below (a list of about 30 topics).

But, instead of getting a list of 30 topics, I get a list of almost 600 topics (with 555 spurious entries dated today), as can be seen at https://www.qppstudio.net/webhelp_xv4/g ... helptopics. For reference, these 555 spurious entries all seem to date back to the first half of 2020, and might be some of the less-recently updated topics.

Any idea what I am doing wrong ? My project uses some custom builds; should I have checked the List topics from current module only option ?

Very best regards,

Olivier

[Olivier Beltrami]

I just tested it with H&M9 and the problem is the same.

[Tim Green]

Hi Olivier,

I can't reproduce this exactly but I am getting some strange results. We're looking into it and I'll get back to you as soon as I have more information.

[Olivier Beltrami]

Hi Tim,

Thnak you very much for your prompt response.

In the meantime, I did some digging and it looks like the spurious topics are all really old and, the ones I looked at do not seem to have the entries modified and lasteditedby at the top of the XML. I tested saving one of these old topics and compared the XML before and you can see the difference in the screenshot below.

Looking back at my forum threads, I now see that I changed the format in which I saved my H&M project from HMXZ to HMXP in March/April 2020, which might explain why I have all these April 2020 files without any mention of the modified date (presumably, if the field modified is not present, then today's date is used?). A bug in the conversion from HMXZ to HMXP ?

Does this help ?

Very best regards,

Olivier

[Olivier Beltrami]

Hello again,
I patched all the XML project files that were missing the modified field with a grep and then retouched their timestamps back to the original one, and it now all works as expected (https://www.qppstudio.net/webhelp_xv4/g ... helptopics).
Very best regards,
Olivier

[Tim Green]

Hi Olivier,

Thanks for the additional information. We're currently performing an in-depth analysis of possible issues with this. We'll post more information here as it becomes available.

[Alexander Halser]

Hi Olivier,
If a topic file does not include an explicit modified date, then H&M automatically assumes the file time stamp as the last edition. We had implemented the internal date stamp because some version control systems modify the time stamps and apply the current date, making the file date unreliable. But if there is no modified field in the XML, H&M defaults to the file date.

[Olivier Beltrami]

Hi Tim, Hi Alexander,
Thnak you very much for your feedback.

If a topic file does not include an explicit modified date, then H&M automatically assumes the file time stamp as the last edition

I kind of came up to that conclusion early on, but got a bit confused along the way because it seemed to me that what you describe above was true for the Link List control, but that the Recently modified topics page of the H&M UI behaved differently (it seemed to keep some secret record of what topics had been modified, independently of either the file timestamp or the modified XML field).
But that's because I create 2 copies of the entire project folder at runtime, one for webhelp and one for eWriter, and then I perform a lot of tweaks to the XML files in these 2 disposable copies, leading to timestamp changes that did not appear in the Recently modified topics page of H&M, which was looking at the original non-tweaked set of XML files.
This is a project of almost 3000 topics that I have been maintaining since 2001 in H&M (and before that in Robohelp and before that in Doc-to-Help). So there are a lot of layers of tweaks that have accumulated
Very best regards,
Olivier

[Alexander Halser]

The rule is simple and it's embedded deep into the XML database functions: always use file date as timestamp, but if internal modified field is available, use this date instead.

[Olivier Beltrami]

The rule is simple

Yes, it was just my mind that was confused.