displayTime freeze

[Sparda]

I really hope someone out there can help me with this one.
I'm running Mac OS X and I've been trying to figure out a way around this problem for a little while now with no luck.

I have a very very simple stack to display a field with the current time with seconds ticking away.

Card Script:
on openCard
displayTime
end openCard

on displayTime
put the long time into field "time"
send displayTime to me in 1 second
end displayTime

This script works great for my purposes but I wanted to make sure everything still worked fine even if the user changed the current time
manually in the date & time control panel of "System Preferences".

Well, basically the time freezes in the field and no more attempts to refresh the field are made unless the time is set back to the original time
or if the stack is closed then reopened.

Is anyone out there able to recreate this and maybe even offer some suggestions on how to circumvent this problem?

Would be greatly appreciated

Regards.

[malte]

This is a problem with the way message are send I assume. If you send in one second, the absolute time ends up in the pendingmessages. Not sure how to work around that...

[Sparda]

Thanks for the quick response on that one malte.

Anyone else wanna take a crack at this one??

[bn]

Hi Sparda,

you will notice that your timer only stops if the user sets the time back, not forward. Since the send in time uses the long seconds which start at the eon of the time (look up under seconds in the dictionary) and the long seconds are changed by setting the time, your handler waits until the long seconds come around. You can see this if you only set the time back say 15 seconds and wait. After 15 seconds your handler will show the time again. If the user sets the time forward your handler triggers right away since your message is 'overdue'. If you dont want your user to wait for this (he may have set the date back one year...) you can work around this. If the user changes the time your stack is in the background (suspended) and if you add a resumeStack handler you can adjust to this.

Code: Select all

on opencard
   if displayTime is not in the pendingMessages then -- dont pile up displayTime on opencard
      send displayTime to me in 1 second
   end if
end opencard

on displayTime
   put the long time into field "fTime"
   if displayTime is not in the pendingMessages then -- dont pile up displayTime on opencard
      send displayTime to me in 1 second
   end if
end displayTime

on resumeStack
   if displayTime is in the pendingMessages then
      put the long time into field "fTime"
      repeat for each line aMessage in the pendingMessages
         if item 3 of aMessage is "displayTime" then cancel item 1 of aMessage
      end repeat
      if displayTime is not in the pendingMessages then -- probably not necessary here
         send displayTime to me in 1 second
      end if
   end if
end resumeStack

please note that I named the field "fTime" not "time". It seems that at times if you use reserved names in the naming of objects you can confuse Rev, even if you make it a literal with the quotes. Also it is probably a good idea to always encapsulate the firing of your send comand by making shure that there is no pendingMessage that you would add to. "if "myMessage" is not in the pendingMessages then send "myMessage"" You get the idea.
I really love the send in time option in Rev but some caveats apply. I never thought of the fact that changing the time, by the user or the system setting the time automatically has an effect on it. But thinking about it it becomes obvious.
regards
Bernd

[Sparda]

Hi bn,

Thank you so much for your response. The "resumeStack" command was one of the things I was looking for and is very helpful.

This definitely helps with what I'm trying to do but it would be really awesome if there was no suspension of the stack or script at all if the time is set backwards.
Unfortunately I aim my stack to be running in the background.

Your script really helps because the time resumes perfectly when the stack comes back to the front but I noticed that it still freezes and will not update when the stack is not the frontmost window.

Do you think there is a way to allow the script to automatically update even in the background if the user sets the time backwards?

I tried messing around with the "on suspendStack" command but I just can't seem to get it.
I'm pretty sure there is an easy solution but my lack of knowledge using transcript or any other script for that matter is proving frustrating.

I really hope this is possible and once again appreciate any help that is given.

Regards.

[ibe]

One idea that might help is looking at appleEvent. Look it up in the Revolution Dictionary. I don't know, but would imagine that the operating system would send an event informing interested applications that the time has changed.

Regards,

Ismo

[Sparda]

Hi ibe,

Thats a great idea, I will definitely look into that.

Looks like I have some reading to do! lol

Thanks again for the help and if anyone else has any suggestions please feel free to post.

[bn]

Sparda,
could you give an example what you are trying to do? Is it that you just want to be shure that you take care of the remote possibility of a user changing the system time? How often will that happen? Or is it something with setting the time that happens more frequently?
regards
Bernd

[Sparda]

bn,

Well, at its most basic level you could say what I'm aiming for is exactly the same as an alarm clock.

If the field "fTime" matches another field containing a preset time then it will do something eg. beep.

While I was testing my script I had gone in and altered the current time in System Prefs and found this freezing problem.

The final application will be invisible and running in the background and do things based on what time it is.
The app will have no user input and only run as a timer so "on resumeStack" might not be a complete solution.
So far everything else works great but I thought it would be a shame if by accident or any other reason the app basically stops working because
someone manually changes there system time backwards.

I guess it's not a major problem because like you say "how often could that happen?" right?

It would be nice not having to list it as being a known bug if you know what I'm saying. XD

Thanks & regards.

[bn]

Sparda,
I think all timers on computers will have the same problem. I think ICal or any other calender will depend on the system time to fire. So your app would not be different from any other timer and that I would not qualify as a bug of your application. You could make your user aware of the problem, but not as a specific problem of your app.

If you want to you could send messages into the past like "send PastTime to me in - 3 seconds", this would trigger right away since without changing the system time this is overdue an fires right away.
You could send multiples of the send PastTime for - 3, - 10 -20 etc seconds and when the message arrives comparing this to the seconds you saved when firing the message. Only if the actual seconds were lower then the saved seconds you would have a case of changed system clock. BUT, this is getting ugly since you dont know how much the system clock might be turned back. I you want to catch all possible cases in 10 seconds intervalls your app would probably choke. I think on a Mac the start of the eon is midnight January first 1970, that is the time you get when the battery is gone and not internet connection exists for automated synchronization. All your appointments would have to wait until 2009 or 39 years, even if you get your counter restarted before that. EDIT: this will not really work since sending a message to the past will fire immediately when sent and it is unlikely that the clock will be changed just in that moment. Oh well, a little brain bug

And since you seem to save the target date/time of for your reminder in this other field of yours, how would you adjust for that with the new time, even if you could catch the change of the system clock?
How do you want to handle time zone changes? Daylight saving time? Welcome to the wonders of time... You might wand to look at the seconds as the unversial reference for all things time/date in Rev.

I would just do it as you intended and forget about the possibility of changing the system clock.

You might be interested in a thread over at the mailing list: http://n4.nabble.com/SEND-IN-TIMe-td343141.html#a343141
that discussed occasional failures of the send in time feature for one user, while others were not seeing this problem.
regards
Bernd

[Sparda]

bn,
Yeah, I think you are right and I'm probably just worrying over nothing.

Basically I was hoping to have a second "interface" app which will allow the time for the alarm to be set and then compared with the time in the invisible "timer" app but as my experience is quite limited I haven't got that far yet and I'm not even sure if it's possible. Was looking at maybe using "send to program" somehow but I haven't spent a lot of time researching that yet. I'm mainly having to learn as I go.
Ideally I would love to have some kind of "Menu Bar" access which is also running from startup which could be a shortcut for the main "interface" which will be in the Applications folder. Finally the invisible "timer" will be in the startup items folder.

Fortunately I don't have to worry about the date because its designed to trigger depending on what day of the week it is and not the actual date.

Sorry for any confusion and I appreciate all the help so far. I have to get back to work now but I will try and play around with it tonight and see what I can come up with.

I will let you know how I get on.

[Sparda]

Well, good news!

It looks like you were right bn in the fact that other programs seem to also suffer from the issue of "time freeze" if the app itself is not running when the time is changed.

It also looks like I have figured out a way to create a "System Menu" for quick access to the main interface and even do other actions.
I had to teach myself shell scripting for that though which was a little frustrating lol.

And finally it seems I have also managed to get "send to program" working by sending data between two standalone apps using request appleEvents.

So far everything is looking good! Now all I need to do is get some sleep.

Thanks again for all the help.

[bn]

Sparda,
that sounds like quite a feat. Glad it works for you.
Have a nice rest...
regards
Bernd

[Sparda]

Well, thought I would give an update regardless of my last post stating everything was good

Turns out this "time freeze" issue has kinda bugged me more than I thought.
Sure, I have ambled along with my project for the last few weeks I'm happy to say all is going well... but this still remains a problem I know there is (possibly) an (easy) solution to.

I have done a lot of research into this but so far have not come close to an actual solution.

I even tried to find a way to intercept the AppleEvent sent by the system when the date/time was changed but turns out there isn't one (from what I could see anyway).
The problem I seem to be facing is the "wait" and "send" commands handled by Rev.

It seems to screw up if the time is set backwards via the system during handling.
I tried to deal with the problem by controlling pendingMessages but with no luck.

I'm sure the solution is right in my face but can't quite grasp it! From what I understand this also seems to be a problem with VB Script in Windows?

I'm open to any suggestions to resolve this problem as I believe it should be quite simple. I quote bn by saying (Welcome to the wonders of time!)

I hate to use another application as an example for reference but "Awaken" for mac is able to update the "time" regardless of what is set in the "Date & Time" control panel.

Anyone know what could be going on in the background here?

Thanks in advance

[malte]

I think I have a partial solution for you, even though I find it rather nasty

What you could do is to use the idle message, to compare if the seconds are less than they were when you started the app, or on the last idle cycle. This will require your app to have focus though. So it is not the ideal solution, but maybe a starter.

Example:

Code: Select all

local sStoredTime

on openStack
  put the seconds into sStoredTime
  pass openStack
end openStack

on idle
  if the seconds<sStoredTime then
  -- example code here, adapt as needed
    repeat for each line theLine in the pendingMessages
      cancel item 1 of theLine
    end repeat
    refireAllTimers -- you need to write the action here
    put the seconds into sStoredTime
  else
    put the seconds into sStoredTime
  end if
end idle

on refireAllTimers
  answer "You cheated and set the clock back!"
  -- start your timers again here
end refireAllTimers

Hope that helps,

Malte