I need to have a “load.txt” button, which loads a text file’s content into textarea1.
However, If there is already text from another file in textarea1, and the user clicks on the “load.txt” button - I need to somehow check if textarea1’s content has changed since it was loaded in (in other words, check if textarea1 is dirty).
If the textarea1 has changed - prompt the user to save it to the same location it came from, before loading the new file’s content into textarea1.
Does anyone have any sample code, or could you point me to a source of information to achieve this.
At least I know my brain is starting to work out solutions by itself.
The other reason I asked is that if I do it this way - there is no little dotty thing in the close buttons circle (indicating the file is dirty)
Anyone know how to make little dotty things???
Not sure about what you are talking about here. But if you want to signalize that dirty condition visualy, you could, for example, put a small oval object nearby using FillColor green and when dirty change it to red? Things like that?
I was thinking about signalizing inside the layout. It’s the window property. “self” must be used only when responding to a Window event in this case. I hope you know how to use it. If you don’t know, better try theWindowName.contentsChanged instead.
It may not matter in this case, but I think this technique could lead to false “dirties.” What happens, for example, if the user changes the text, and then changes it back to what it was originally? The TextIsDirty property would renin TRUE, wouldn’t it?
To avoid that, you’ll need to cache the original text in a property, and do a comparison of the current vs. original text (probably case-sensitively) in the textChange() event.
[quote=110593:@Peter Truskier]It may not matter in this case, but I think this technique could lead to false “dirties.” What happens, for example, if the user changes the text, and then changes it back to what it was originally? The TextIsDirty property would renin TRUE, wouldn’t it?
To avoid that, you’ll need to cache the original text in a property, and do a comparison of the current vs. original text (probably case-sensitively) in the textChange() event.[/quote]
Most word processors around consider text dirty whenever the user has modified it, even if he has later nullified his modifications.
True though that may be, I find that behavior pretty frustrating and not very user-friendly. I’ve always endeavored to make that not be the case in my projects. I prefer a “dirty” flag to mean that the document is actually different
I understand. This maybe a bit complex, though, as you need to compare all characteristics of the text to make sure it is identical to the initial state. Style, case, etc. String manipulation can be heavy. This could be too time consuming for a large document, which may explain the generally quicker approach of “any change is dirty”.
I used to fear that, too. I’ve found, though, that strComp is very fast on a reasonably modern machine. I’ve used this technique to assess dirtiness using the the toString function of relatively large XML documents (representing object states) and have never seen any noticeable effect on performance.
Except that in a word processor, most operations must be carried out between keyboard punches. That leaves something like 50 hundreds of a second on average when somebody types fast. So having a real time indicator is not that easy. Any drag on display or responsiveness will be noticed by the user. It can even get as bad as missed punches like the famous cut/copy/paste issue in the Windows Xojo IDE.
Of course one could check whenever the user pauses, or do it at intervals, and set the indicator accordingly. And as dirtiness has eventually to be asserted upon save, it leaves more time to decide to simply save, or present the user with a dialog.
There is something called “processing cost” and “degree of certainty”. You have a trade-off here.
If you are talking about few bytes and can just compare saved copies, ok, but if you are talking of Kbytes of data you will losing precious memory and CPU with the processing cost going sky-high for such simple task of informing the user “Don’t forget to save”.
You know that user “touched” the information and chances are it is not on the same state it were since last “checkpoint” (saved that info?). So, you can easily mark it as “touched” (dirty using Rich’s words :)) and guarantee that user knows that he/her need to “save” that info to guarantee the new state (probably).
For your requirements, we need a high cost processing to determine if the current info was modified and by any means reverted to the initial state. It demands computing a “hash” from the data in its initial state and recomputing it after each modification and see if those hashes are the same. There is even a chance of false positive (a false non-touched while it was really touched) depending on how simple is the hash calculation and the size and the nature of the data.
The low cost, guaranteed, and safe way is mark it as “touched” at any touch and say that to the user.
Text editor “UltraEdit” shows a * at the end of the file name in the file’s edit window title bar if the file has been changed since the last save. However if that same change is reversed with “undo” then the * is removed by UltraEdit as the file now has the same contents as at the time of last save. Say a character is added to the file and then deleted with back space then this file is still indicated as changed with the * in the file name, even though in this case as well the file contents are same as the last save. If these two changes are now reversed with “undo” then the file is marked as unchanged. So it seems that “UltraEdit” may be tracking the file changes with “change and undo” instead of the entire contents of the file.
In my experience, the cost is not that high, even with many KB of data. I’ve not applied this in the case Michel describes of nearly constant keyboard entry. In that case, I’d probably use a timer that gets reset on every keystroke so that the chaco only gets made when the user pauses.
I’m not in fundamental disagreement with what you say, Rick. I’m just saying that for this sort of thing, our machines are a lot faster than we sometimes fear…
It’s the window property. “self” must be used only when responding to a Window event in this case. I hope you know how to use it. If you don’t know, better try theWindowName.contentsChanged instead. 
