Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timer delay does not default to 1000 milliseconds #192

Closed
shoooe opened this issue May 5, 2015 · 2 comments
Closed

Timer delay does not default to 1000 milliseconds #192

shoooe opened this issue May 5, 2015 · 2 comments

Comments

@shoooe
Copy link

shoooe commented May 5, 2015

In the seesaw.timer documentation it says:

:delay Delay, in milliseconds, between calls. Defaults to 1000.

That's unfortunately not true, as this simple snippet of code can prove:

(defn -main []
  (let [canv (canvas :background :red)
        tim (timer 
          (fn [[c b]] 
            (if b
              (config! c :background :black)
              (config! c :background :red))
            [c (not b)])
          :initial-value [canv true])]
    (show! 
      (frame 
        :title "Sample" 
        :width 500 :height 200
        :content canv
        :on-close :exit))))

This is probably due to the fact that in the timer implementation, you are calling the constructor passing 0 as first argument, which in the Timer class represents both the initial delay and the delay between calls (this is also true for Java 8's Timer).

SalvatoreTosti added a commit to SalvatoreTosti/seesaw that referenced this issue Oct 10, 2015
Timer now has delay set to 1000ms by default.
The delay does not apply to the initial delay, which is initialized to 0ms.
Initially problem initially identified in issue clj-commons#192.
SalvatoreTosti added a commit to SalvatoreTosti/seesaw that referenced this issue Oct 10, 2015
Timer now has delay set to 1000ms by default.
The default 1000ms delay does not apply to the initial delay, which is initialized to 0ms.
Problem initially identified in issue clj-commons#192.
@bradcypert
Copy link

bradcypert commented Jul 18, 2016

Can this be closed?

@daveray
Copy link
Collaborator

daveray commented Jul 18, 2016

Yep.

@daveray daveray closed this as completed Jul 18, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants