both look good there - but #2 is preferable I think - and more foolproof too
#2 it is... I'll roll with that. Though how it is in the screenshot probably won't be the final final
I'm still confused by the above:
I admit it is confusing, but all I was saying is that if task #4 has been initialized, but not started, then the value that remains stored in the Reset variable is the beginning time of the previously active task, so that explains the behavior. Bug? Yes, that should count as a bug. But I'm left wondering what should
be happening. Should hitting Reset at the point after a new task is initialized set the start time to Zero? Or the end time of the previous task? (Actually, I have an idea; more about that farther down...).
So, a group of tasks can ultimately be treated as one task,
I have no ideas about difficulties of implementation. What do you think?
Task grouping sounds like a great idea, but I am at a loss as to how to implement it. For now, anyways...
Maybe this is not yet implemented:
tasks are not saved on closing.
Whoops! Time to implement auto-save, or a reasonable facsimile. Should it ask the user to confirm on exit? Or simply save the session with a possibility to recall on the next start-up? Or a set-able option to automatically load the previous task list on start-up? So many possibilities...
OK, so with most of the internal logic pretty set, here's what I'm thinking for the next iteration of user interaction:
- Make a toggle for "Start at Zero" or "Continue from Previous".
- Reset should always reset to the beginning time of the current task, whether that is zero or something else depends on the New Task behavior.
- Make "Continue from Previous" the default 'New Task' action, but "Reset" will set the clock back to zero. Much simpler code that way...
- I don't like the idea of the end time updating in the list
, I mean, it's not even there until you stop the timer, so I think "graying out" the end time and total when re-starting a current task is a great idea; takes your mind off the list and back on the timer, and also lets you know at a glance that this is a task that has been continued. Which leads to...
- Going back to an old task to continue the time spent on it is a good idea as well. I know how it can be done, so that'll be in the next iteration.
- Grouping tasks isn't as easy, maybe even impossible without a custom component. The StringGrid component has a lot of methods and properties to it, and is quite complex. Trying to wrangle sub-lists into it would be problematic at best.
- Saving sessions should be a given by now, you're right; not saving the session is kind of unsettling. But how to implement? I'm thinking either offer the user to save the current session on exit, or simply auto-save and have an option to auto-load on next start-up. That will be easy to do. Hmmm... maybe even differentiate between saving a session
and saving a final file
; kind of like: if saving a session, then auto-load the session on the next start-up, but if saving a final file, the next start-up is blank. You can always manually load a saved file from the File menu and continue as well.
So that's what I got, I'm going to dive back in and get something ship-shape for you to test, hopefully not too far in the future. I'll keep the thread posted with any breakthroughs...