CODEWITHSUNDEEP
clojureseesaw
nansen
nansen

Reputation: 2962

Cannot access or update atom from within a seesaw listener function

I have a seesaw ui with a text editor. The editor content is backed by a record called 'Task' which is contained somewhere in an atom called 'state'. A key-released event on the editor should change the property :desc of the Task. I use the following code:

(def state
     (atom {:tasks []
            :interval nil
            :style (style :foreground :black :background nil)}))

(defn on-text-edited [ui listener-fn]
  (let [editor (select ui [:#editor])]  
    (listen editor :key-released
        (fn [evt] (listener-fn (text editor))))))

(defn update-task! [task text]
  (let [newtask (assoc task :desc text)
        tasks (replace {task newtask} (:tasks @state))]
  (swap! state
     #(assoc % :tasks tasks))))

(def text-updates (on-text-edited frame #(update-task! selected-task %)))

selected-task is an atom referencing the current content model of the editor. Whenever the user edits text the update-task! function is supposed to be called. But nothing happens. The function seems not to be called at all. When I call it from the repl it behaves as expected.

I tested if the function would get called by letting it do a simple println:

(defn update-task! [task text]
   (println (str task " " text)))

Now the function works fine when I edit text in the editor. Then I changed it to:

(defn update-task! [task text]
  (let [newtask (assoc task :desc text)
        tasks (replace {task newtask} (:tasks @state))]
     (println (str task " " text))))

now again, it would do nothing at all. So it seems that somehow the accessing of the atoms get in the way of the event handling. Is there maybe a conflict between the ui thread and the thread the atoms were defined in?

Upvotes: 1

Views: 284

Answers (1)

Dave Ray
Dave Ray

Reputation: 40005

In a case like this where it works in the simple case and stops in a more complex case, I'd guess that there's an exception occurring, probably in assoc or replace in the let bindings. Depending on your dev environment, the exception may be hidden since it happens on the UI thread.

I'd suggest try calling seesaw.dev/debug! which will popup a ui with a stack trace whenever an unhandled exception is thrown in the UI thread.

Upvotes: 5

Related Questions