"Sven Baars (@sbaars)" <wine(a)gitlab.winehq.org> wrote:
On Fri Dec 2 14:47:58 2022 +0000, **** wrote:
Dmitry Timoshkov replied on the mailing list: ``` "Sven Baars (@sbaars)" <wine(a)gitlab.winehq.org> wrote:
On Fri Dec 2 14:16:59 2022 +0000, **** wrote:
Dmitry Timoshkov replied on the mailing list: \`\`\` Sven Baars <wine(a)gitlab.winehq.org> wrote:
- if (CompareFileTime(&begin_ft, &trigger_ft) <= 0 && CompareFileTime(&trigger_ft, &end_ft) < 0) + if (CompareFileTime(&trigger_ft, ¤t_ft) >= 0) { if (!have_best_time || CompareFileTime(&trigger_ft, &best_ft) < 0) { Removing the trigger end time check doesn't look right. -- Dmitry. \`\`\` Hi Dmitry,
Thanks for the reply. I don't see how begin_ft and end_ft are relevant for this trigger. It happens exactly once, at the "Start" time and "Begin" day.
Having an "End" day before the "Begin" day is invalid for all triggers. I could add a patch that checks for that. Obviosuly the trigger shouldn't fire outside of begin/end time, so changing the trigger time bounds check doesn't look right. At best, that should be a separate patch with a bunch of tests. -- Dmitry.
I submitted a v2 that addresses your concern.
Looking at it again I don't understand the bounds check change. beging_ft already accounts for current_ft earlier in the code. Can you leave it as it is now? -- Dmitry.