My eye falls into that Window entry in the LR.
Till now, I use a boolean (ChangedBool or so) and act accordingly.
Why will I use the WIndow.ContentsChanged Event ?
It should become clear when you read about the ContentsChanged property:
So you can use this property together with the event to handle display or behavior changes for a user document window.
In your example it will have a very similar outcome except ContentsChanged will alter the macos Close button to show that the window/content is “dirty” and is probably used to show that the contents might need to be saved before closing the window as part of the recommended macos design but I’m not up to speed on macos ui design so I’d not be able to say for sure.
There isn’t really a standard like this in windows.
@Ulrich:
I do not saw that line in the docs. Strange.
The line does not exists here: http://documentation.xojo.com/api/deprecated/window.html#window-contentschanged_event
Both:
Thanks.
AFAI understand, the developer must change by itself (decides) a property to activate this Event.
Fires when the value of the ContentsChanged property has changed. Changing the value of the ContentsChanged property triggers this event.I don’t know when or if something is or becomes a standard but what i see since Windows 3.0 and MS Word 2, is that the title of the window ends with ‘*’. if there are unsaved changes. For me that’s standard enough but it’s not a law for Windows users.
On mac you have a visual feedback (very little, a lot of users never notice it)
But you can use it to update your UI and give the user any info about the “modified” status of the document (whatever it means in your app)
Usually I use this event to enable/disable a “save” button and I don’t need to reference the button on the “changing” item but only change the ContentsChanged property (on a Window or container)
Very useful and simple.
Thats funny, Antonio, your first paragraph read below:
I never noticed that. In fact, if someone asked me about a user feedback (this document have changed) on Windows, I would say: I do not know !
But, yes, the mac OS dirty flag is visible (for me). But because of a project of mine who use it (or not), I rely on the Not saved data warning I issu in that project to save or discard changes
even in the Xojo IDE (the one I have a license for or the current version). 
I agree but as I don’t see it across all apps (e.g. Notepad) I assumed it wasn’t standardised and wasn’t worth mentioning as it doesn’t “magically” appear when using ContentsChanged 
For me that’s a bug in Xojo, because if you change anything in a program, Xojo itself dirty’s it’s own window by adding that ‘*’ to the title. But probably that’s just me.
I assume Julian meant that it’s up to the app developer to add the ‘*’. So Xojo does it. But that’s not enough of a Windows standard that all Windows devs do it in other apps.
macOS users will complain if developers don’t follow standards that emerged soon after the Mac was introduced in 1984. Such as using -Q for exiting the program or showing the window as dirty by marking the window-close button.
Tim, i understood his answer as: the ContentsChanged event doesn’t fire in Xojo programs for Windows, that would be inconsistent to the way it’s handled on a Mac.
I know that Windows programs and developers are not so disciplined and forced to behave acording standards, especially the ones who are mostly meant to please users and not so much serve the efficiency of the program.
I understood it to mean that the event fires across both platforms, but then it’s up to the developer to do something with it. macOS devs will tend to mark the window-close button, but only some Windows devs will put the ‘*’ after the window name, perhaps because the notion of doing that is a recent one. BICBW.
Only if the developper change a variable contents. Else, the Event is not fired.
The LR states that and I checked.