Multiple handlers running at once see unexpected data

[vjackson725]

Hi all,

I’m having a problem with handlers. I have a button that makes a change to a GtkEntry. There is a handler on “changed” for the GtkEntry.

        ...
        <child>
          <object class="GtkButton" id="button">
            <signal name="clicked" handler="button_clicked" swapped="yes"/>
            <property name="label" context="button">Button</property>
          </object>
        </child>
        <child>
          <object class="GtkEntry" id="entry">
            <signal name="changed" handler="check_text" swapped="yes"/>
            <property name="editable">false</property>
          </object>
        </child>
        ...

The text in the entry is initialised to “text”, and the handlers are implemented as follows

  ...
  #[template_callback]
  fn button_clicked(&self, _button : gtk::Button) {
    println!("button_clicked/start: {:?}", self.entry.text());

    self.entry.set_text("text v2");

    println!("button_clicked/end: {:?}", self.entry.text());
  }

  #[template_callback]
  fn check_text(&self, _obj : glib::Object) {
    if !self.constructed.load(atomic::Ordering::SeqCst) { return; }

    println!("check_text/start: {:?}", self.entry.text());

    let text = self.entry.text();
    if text.as_str().is_empty() {
      panic!("editable text was empty, but shouldn't be");
    }

    println!("check_text/end: {:?}", self.entry.text());
  }
  ...

I anticipated that this would change the text from “text” to “text v2”. However, when I run it, I get the following behaviour

button_clicked/start: "text"
check_text/start: ""
thread 'main' panicked at src/example_widget.rs:88:7:
editable text was empty, but shouldn't be

The check_text handler is called because of the set_text in the button_clicked handler. However, it seems to be setting the text (at least initially) to the empty string, which is very unexpected!

I’m using the rust bindings, though I assume this would happen in the C too, but I haven’t checked. This is a pattern I found while re-implementing the constraint-editor demo in Rust. The situation happens in constraint-editor.ui, between the source_attr drop-down and the multiplier entry, and the source_attr_changed and update_preview handlers. I think there is no issue there because it uses g_ascii_strtod to parse the string, which returns 0.0 on an empty string.

Find the full code here:

gtk_misc/handler_problem at main · vjackson725/gtk_misc

My questions:

1. What should I do to avoid the handler seeing the empty string?
2. Why is there an empty string in the entry in the first place?