Is there a way to override auto logout
idbruce
Posts: 6,197
I just spent an hour writing another article only to lose it due to log out. What is the point of logging in if we are going to be logged out.
Comments
For longer works, I will regularly use a text editor, rather than type into a browser window.
Finally, on longer posts, it's not a bad idea to go ahead and commit the post, returning to edit, keeping your input risk to a minimum.
Bummer to lose stuff you typed in. Hate it personally. Sorry it happened.
No, have not tried that. I actually know better, I was just so rapped up in the article that I forgot to copy before submitting.
Just venting a little frustration. Thanks for understanding. It was my stupidity.
EDIT: I just wonder how many more wonderful articles there would be available to the forum if people had not lost what they had written.
Yea, I can foresee auto reload being a problem. Forgetting to occassionally save my work on the computer has caused me a lot of grief. Actually losing a post is not as bad as spending several hours on a mechanical drawing and then having the house power disrupted. Either way, losing work and wasting work is never a good thing.
Bruce
Not much to be done on the "didn't save it" issue, other than work on habits.
Having worked in CAD file managed environments for years, I find it intolerable to just keep working on ONE file, or delaying a save because a chain of files might require an update. So, when I don't have that environment now, I will regularly update the chain. Has saved me tons of time, and I can return to earlier states, just like a managed environment.
This always plays out positive. What isn't obvious is the time gain, until it happens. Once it does, one doesn't go back.
SImply number your files, and if they have dependencies, work from the bottom up, saving with a new number. The key on this is a trigger. Some people use time, such as every thirty minutes, or top of the hour, day, etc...
Never did like time, because the time happens when I'm in the middle of something and a save doesn't preserve a state that makes any sense at all, because I'm in the middle of something. Hate it.
So my trigger is some significant accomplishment. That might be wording a particularly difficult passage, or if working in CAD, realizing some troublesome geometry, or establishing some assembly state that matters. If it's code for the Propeller, I hit F10, and it did something notable. SAVE AS on the files you are going to change, and continue, preserving that for reference / recovery later.
The key here is that it built, or is written, or drawn, whatever and I'm really happy about it. Save the current file RIGHT THEN, then if you are going to continue, SAVE AS with a new number locking in what you did, updating your tree of files, if there are multiple files, otherwise just numbering the current file. THEN proceed to expand on your greatness! You can always go back to what WAS great, and that is what saves the time in the end. Get used to creating a file to change instead of changing a file that you will eventually save. That's the key right there. It will become habit.
The other element is dicipline. Once a numbered file is saved, and you note that state as one to preserve, use the SAVE AS, update your chain of files, or single file to capture your next state, never letting go of the accomplished one, never, ever changing that numbered file again. Seems excessive, but it's not, and it's easy habit once done a few times.
Disks are cheap compared to human time and mental effort / energy / ego. A crushing loss kills a project, or renders it work instead of fun. Don't do that. It's just not fun! (and if it's not fun, then it's trouble, IMHO)
A short example:
Say we've got a program that has the main program (main.spin), using a TV driver (TV.spin) and the SD driver. (SD.spin)
Put the project together, thus:
main.spin
--tv.spin
--sd.spin
That's the baseline effort. Maybe main isn't easy to write without testing right, so we've got test.spin.
test.spin
--tv.spin
--sd.spin
Something in test, requires a tweak or small addition to tv.spin.
01_test.spin
01_tv.spin
sd.spin
Now the test case is good, but tv.spin breaks sd.spin.
02_test.spin
02_tv.spin
01_sd.spin
Test completes, time to author main!
01_main.spin
02_tv.spin
01.sd.spin
Work progresses on main...
05_main.spin
02_tv.spin
01.sd.spin
After a time, it becomes obvious that some extra method is required in the SD card code.
06_main.spin
02_tv.spin
02_sd.spin
And finally main sees the finished work!
07_main.spin
02_tv.spin
02_sd.spin
At each stage, changes in the child file cause an increment to that file. If that file has a parent, increment that one also, using "save as" all the way up the tree of files.
If you do this, it will become habit after just a few cycles. Doesn't take long. Now, the advantage!!
Having done this, you have all the states! So, it is discovered that another project could benefit from an earlier version of main, and the TV driver, coupled with the serial driver!
Recover prior state of main:
06_main.spin -->01_new_main.spin
01_new_main.spin
--02_tv.spin
--serial.spin (from OBEX)
Save all to new folder, and now you've kicked off the new project, or author it in the same folder, keeping everything in sync, perhaps the two projects should share code. Either is possible.
The key is you've got your code / authoring states intact over time. This will generate a fair number of files. Every so often, compile an archive, or create your zip file of the folder, or the current chain of files to clean things up.
07_main.spin
02_tv.spin
02_sd.spin
>07_main.spin.zip
Sometime later, the original project needs a small field update.
Either return to the folder, or unzip your release archive, and the very first move, before doing anything is simply "save as" creating a storage slot for the new state, and carry on, no worries.
Ever wish you could just run the version you had yesterday to compare to what you've got now? If you save this way, you will be able to do that quick 'n easy, even having both open and usable / uploadable to the propeller if you are coding at the same time! Can't live without this now.
Need to prove authorship? No problem. Simply present your state of work over time, and you've answered this cold. No worries.
Need to update that version in the field? Compare to the current one in development? No worries. Open both, deal as needed, always creating a new state for each impacted file. (save as, and update the tree BEFORE CHANGE)
Want to know what you've changed and what is straight from a reference source, such as the OBEX? If it's got a number on it, you've touched it. If you want to return your changes to the OBEX, you've got them, and you've got WHY you did them too, assuming you commented your code; otherwise, you can just go and look, because it's there to look at.
That's the key right there. Save as before change, then change. You can always roll back the change by deleting the new file, and you can track your development state across multiple files, preserving nearly every option.
Just one big "undo" or "didn't lose work" event will pay for a coupla hundred save as cycles. That's been my experience anyway.
(or get a managed environment, which is another discussion and some investment --on larger projects, there is software for this, I recommend acquiring it and learning how to use it, but for most things Propeller, the method I just described works very well.)
Doing this, plus a UPS will change your life on these gaffes. Trust me. I was there, dragged forward grudgingly! Now I would never, ever work in the old way. Too risky.
YMMV
WOW that is quite the write up. Caught me a bit off guard with time constraints. I will have to come back later today and try to digest the full message. But one thing that we currently have in common with our saving:
LOL Yes all significant accomplishments MUST be saved.
Bruce