DWC doesn't clear state.messageBox mode=1

pfn

M292 only gets sent for messagebox type 2 and 3 (blocking ok and ok cancel)

I don't know what side effects would occur from sending M292 for all mode1 message boxes.

It's very annoying when dwc reloads and old errors appear. Yes, the resume.g hack would work, but this is a "framework" issue that shouldn't be resolved using a workaround.

chrishamm

@pfn I am aware of this - DWC 3.4 was deliberately changed to send it only for blocking message boxes. M292 is only meant to acknowledge blocking message boxes; if it were used for regular messages as before, potential race conditions might occur that we need to avoid.

I'd be happy to "restore" the previous behaviour and actually dismiss non-blocking message boxes somehow, but we need to find a good alternative solution first. @dc42 what do you think?

dc42

@pfn M292 was designed solely for user interfaces to acknowledge blocking M292 messages. I am aware that some users were using it for other purposes, and as @chrishamm says this gave rise to race conditions.

To cancel non-blocking messages programmatically would be a new feature, requiring a different M-code.

Please clarify the conditions under which you want to clear a non-blocking message. From what you've said so far, it's something to do with "old" errors, so a mechanism to cancel current messages isn't what you need anyway.

pfn

@dc42 said in DWC doesn't clear state.messageBox mode=1:

@pfn M292 was designed intended solely for user interfaces to acknowledge blocking M292 messages. I am aware that some users were using it for other purposes, and as @chrishamm says this gave rise to race conditions.
...
Please clarify the conditions under which you want to clear a non-blocking message. From what you've said so far, it's something to do with "old" errors, so a mechanism to cancel current messages isn't what you need anyway.

There are non-blocking messages sent and stored in state.messageBox, e.g. printer paused due to filament runout (as referenced by the previous thread).

These messages are never cleared and always reappear when DWC is reloaded until it is cleared by using M292 or another message preempts it. The message remains even though it is out of context: the print job has already completed and no longer running, the user still receives the message upon loading DWC. This causes user confusion and has come up multiple times.

Either the message should be made blocking, non-blocking messages shouldn't be eligible for persistence through state.messageBox, or we need an alternative method to clear non-blocking messages that are presented in state.messageBox.