1

I was wondering how Windows applications typically keep track of dirty controls in a dialog, so that when the user clicks a button like "Apply" or "Save," the application knows which controls' values to commit.

I see that edit controls have an EM_GETMODIFY message, which will tell you whether the contents of the edit control have been modified, but I don't think that type of message is available for other controls like date-time pickers or combo boxes.

So I suspect that this would be done by monitoring change notifications sent from the controls to the parent dialog. But if that's the case, how might the change events be flagged or stored? I thought that perhaps that whenever a change occurs, the application could store the control's ID or hwnd in a std::unordered_set, and then iterate through the set when it's time to commit. Or is there another, more accepted and efficient way? Thank you for any guidance.

  • Change tracking doesn't sound like something that should be done in your UI. The UI's job is to present data to a user, and allow the user to interact with the application. – IInspectable Apr 23 '21 at 11:45
  • Users change a control, change it back to the original, change it again etc. It's usually a waste of code doing change tracking on dialogs (and a source of bugs). Just commit everything. If you really have a code-path that is very expensive (in terms of update time). Then diff the potential update against the original data before committing the change. Remember that the user has asked for the change/update and therefore will ignore a very slight delay (in the UI) while the update is performed. – Richard Critten Apr 23 '21 at 12:02
  • "*Just commit everything*" - that is what my apps do – Remy Lebeau Apr 23 '21 at 15:12
  • I mean, I like that approach because it's simpler. It just seems kind of inefficient, especially if you're dealing with a bunch of tabbed dialog pages and stuff. –  Apr 23 '21 at 15:50
  • 1
    Your data model encodes how to respond to changes of (portions of) your data. It has far more domain specific knowledge than the UI. If you need to optimize efficiency, do so at the code that models your data. Your UI needs to be optimized for responsiveness. And that's really all there is to it. – IInspectable Apr 23 '21 at 21:11
  • @user15025873 One other point to consider is the guarantee of consistency. If the changes get committed to external support (file, db etc) that can potentially be modified by another (instance of your) app then you may not even know for sure what settings are "*dirty*" at the point of commit. – dxiv Apr 26 '21 at 16:35
  • @dxiv Well how do you deal with that? –  Apr 26 '21 at 19:57
  • @user15025873 If that's a possibility then you need to deal with it like with any other potential concurrent updates to a shared resource. The exact how-to depends on the specifics of your case. – dxiv Apr 26 '21 at 20:37

0 Answers0