Whenever the time changes, WinBatch Studio thinks open files were changed outside of Studio and asks if they should be reloaded.
Thanks,
Paul
I assume by "time changes", you are referring to the recent DST change. Otherwise, I'd be obliged to point out that the time is always changing. Time marches on. TIme & tides wait for no man. Etc, etc.
Anyway, yes, this is common behavior in (some/most) editors. I've seen it in vi. It makes sense when you think about it.
Now if the theoretical physicists and cosmologists could only come up with the math to explain why time only goes in one direction...
I think it is because we tend to screw things up bad enough the first time around...would really be a mess if we had a chance to do it more than once ;)
Jim
I dunno, it eventually worked out for Bill Murray.
Quote from: td on March 10, 2014, 06:54:06 AM
Now if the theoretical physicists and cosmologists could only come up with the math to explain why time only goes in one direction...
It is quite possibly an artifact caused by the expanding nature of the universe, with the unidirectional nature of time being tied to the outward expansion. If gravity wins out in the end, counters expansion and causes a gravitational collapse of the universe, perhaps time will run backwards...
Of course, that whole dark energy business could really throw a wrench into a gravitational victory.
Quote from: ChuckC on March 10, 2014, 08:36:22 AM
It is quite possibly an artifact caused by the expanding nature of the universe, with the unidirectional nature of time being tied to the outward expansion. If gravity wins out in the end, counters expansion and causes a gravitational collapse of the universe, perhaps time will run backwards...
Now that *is* interesting. I wonder if, on the back half when things are collapsing, creatures would experience free will much as we do now, except that the laws of thermodynamics would run the other way.
Quote from: td on March 10, 2014, 10:27:29 AM
Of course, that whole dark energy business could really throw a wrench into a gravitational victory.
Yeah, if dark energy actually accelerates the expansion and defeats gravity in the process, then it begs the question as to whether or not time would remain constant or if it would accelerate as well.
It's these kinds of theoretical rabbit holes that seem to break some people who entertain thoughts of becoming a theoretical astrophysicist...
If you are talking Einstein Spacetime (time dilation), then Time does NOT seem to be constant and can be altered by gravity or speed (so long as you are observing or calculating it for somone else - :) relativity).
If you are entertaining the newer and more wacky branches of physics then perhaps time may not exist at all except as a way for us to make sense of, and to reference, all that just IS ..... a bit like numbers, or the concept of infinity.
Might as well misquote Bismarck [again] - Time is like sausages, you really shouldn't see how it's made
I am happy to see that this thread took off in a direction inspired by my first response.
Well done, guys!
So I guess the conclusion is Studio's request to reload files is pretty insignificant when it comes to the bigger questions of time...
Quote from: PaulSamuelson on March 11, 2014, 07:01:42 AM
So I guess the conclusion is Studio's request to reload files is pretty insignificant when it comes to the bigger questions of time...
I suppose it's all matter of scale and perspective...
As for the actual issue that you posted about, it probably depends on whether or not the file's time stamp is being stored in memory and compared with the time stamp value on disk as a local time or as a UTC time. If it were done as a UTC time and simply displayed as a local time with adjustments made for the local time zone and DST offset, then you wouldn't see this behavior. However, if the time stamp values that are obtained from disk initially and then again later on for comparison have the "local time" adjustments made to them, then a transition between standard time to daylight savings time will result in apparently different times if the current locality observes DST.
I suppose it would be helpful if Tony or Deana could confirm that this is what WinBatch Studio is actually doing.
I would guess that it is difficult to definitively determine whether the change was because of the Time Change or not. Assumptions could be made but we all know how that often goes. The actual time stamp on the file changes so that triggers the reload question just like it would for any other timestamp change. Also, not sure trying to code into one's program the ability to determine when Daylight Savings is going to occur is very feasible.
Jim
Quote from: ChuckC on March 11, 2014, 08:48:46 AM
Quote from: PaulSamuelson on March 11, 2014, 07:01:42 AM
So I guess the conclusion is Studio's request to reload files is pretty insignificant when it comes to the bigger questions of time...
I suppose it's all matter of scale and perspective...
As for the actual issue that you posted about, it probably depends on whether or not the file's time stamp is being stored in memory and compared with the time stamp value on disk as a local time or as a UTC time. If it were done as a UTC time and simply displayed as a local time with adjustments made for the local time zone and DST offset, then you wouldn't see this behavior. However, if the time stamp values that are obtained from disk initially and then again later on for comparison have the "local time" adjustments made to them, then a transition between standard time to daylight savings time will result in apparently different times if the current locality observes DST.
I suppose it would be helpful if Tony or Deana could confirm that this is what WinBatch Studio is actually doing.
WinBatch Studio is an MFC application so it relies on that library's CFileStatus C++ class to determine if a file's modification date has changed. Basically, if MSFT's class says a file's modify time has changed, WinBatch Studio will act accordingly. One obvious solution is to not leave WinBatch Studio running on the two relevant nights of the year or if you are a night-owl, save your work and then close and reopen WinBatch Studio immediately after the clock strikes two on the afore mentioned nights.
Or just accept that it happens and say "Yes" to all the prompts.
I did just now (today) get hit with this with GVIM - luckily, it has a "Load All" option that quickly reloads all affected buffers.
Good point. I don't ever leave a workstation or notebook (let alone WinBatch Studio) running over night so I have never dealt with the problem. It is not too difficult to imagine getting a bit irritated after about the 20th click/key press or so. Not all of us can count patiences as a virtue.
Write a WB script to click away all those promptsââ,¬Â¦
I'm surprised that you never leave your machines on over night. I do it all the timeââ,¬Â¦
Quote from: snowsnowsnow on March 11, 2014, 08:00:47 PM
Write a WB script to click away all those promptsââ,¬Â¦
You still have to wait for each one to appear and be dismissed. Because the dialog gets displayed during idle processing that has a convoluted algorithm for determining when idle events like a the box display will occure, it could get very frustrating trying to use the editor while having a script dismiss the boxes.
Quote
I'm surprised that you never leave your machines on over night. I do it all the timeââ,¬Â¦
No reason to and several reasons not to.