issue with EV_SPIN_BUTTON

[r...@amalasoft.com]

I tried using an EV_SPIN_BUTTON, and added an agent to its change_actions, without issue.  Works just fine.

Then, rummaging through the class, I found that it also had text_change_actions, triggered on a change to the text in the accompanying text field.  Seemed like something I should use.

Adding an agent to text_change_actions was not so successful.  On deleting a character from the text field, it promptly segmentation faults.  Recompiling from scratch, making chicken-noises, and burning candles (the usual cures for seg faults) had not impact.

I know I can add to the return_actions (presumably, though I have not done so just yet), but it seems like a good idea to be able to catch even temporary changes to the text field.

Suggestions?

Thanks

R

[r...@amalasoft.com]

Forget what I said about return_actions.  That too blows up with a seg fault :(

R

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/eiffel-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/20190613102227.cf48dd763fcaf5d42559c6c92f6fc53b.a31e748d87.wbe%40email25.godaddy.com.
For more options, visit https://groups.google.com/d/optout.

[Germán Arias]

Hi,

Like this:

    spin_button.text_change_actions.extend (agent change_text)
    spin_button.return_actions.extend (agent return_action)

then:

   change_text
        do
            print("Text changed %N")
        end

    return_action
        do
            print("Return %N")
        end

Read:

https://www.eiffel.org/doc/solutions/Event_Programming_with_Agents

Germán

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/20190613103009.cf48dd763fcaf5d42559c6c92f6fc53b.34c2cbbaf9.wbe%40email25.godaddy.com.

[r...@amalasoft.com]

I'm fully aware of how to assign actions.  The issue is that doing so, I get a seg fault.

I can catch change_actions, but the text change and return actions blow up.

R

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/a0d9b31a-aca7-ab03-adea-99af6daf719c%40gmx.es.

[Germán Arias]

Mmm... strange. I'm using Eiffel Studio 19.05 on PCLinuxOS (64 bits) with Gtk 2.24.32 and Gtk 3.24.8 and all its requirements and it works.

I remember I had to install other library due to a warning when I launched estudio from a terminal. But I don't remember the name of the library.

Germán

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/20190613180634.cf48dd763fcaf5d42559c6c92f6fc53b.36aa1f5410.wbe%40email25.godaddy.com.

[r...@amalasoft.com]

Hmmm, indeed.  I'll look into that, thanks.

BTW, the seg fault is occurring with 18.1 on Windows 10 (so not a recent change to Eiffel, but might be a change to Windows).  I'll try Linux later this AM and see what happens there.

Thanks

R

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/dda26d19-a5da-2b24-d4e4-8fb037482786%40gmx.es.

[r...@amalasoft.com]

FOUND IT!

With some more experimentation, I found the problem.  It was a combination of factors, mostly of the the ID 10t variety.

The agent I had added to the text change and return actions was the same agent that I added to the change actions.  The compiler implied (by its silence) that I was doing the right thing, but I was not.  Although the routine represented by the agent was effectively a no-op, the seg fault occurred because the text change and return actions were simple notify actions (no args), and the change action included a single integer arg - and that was expected by the receiving routine.

This begs 2 questions:

1. Why did the compiler not flag the signature mismatch?

2. Why am I still allowed to use a computer?

The moral of the story is: "If you think it's an exotic or rare problem, you're wrong.  Look first at the basics."

Thanks again

[Alexander Kogtenkov]

Thank you for the update. Agent types are using TUPLE to mimic arbitrary number of arguments. And the conformance rule for tuples allows reattachments like

   empty_tuple := non_empty_tuple

because there is nothing wrong to supply some values when no values are needed. This does not work well with agents. According to the typing rules, the reattachment

   routine (empty_tuple) := routine (non_empty_tuple)

is still allowed. This is OK for closed arguments. But if open arguments are involved, and no arguments are supplied when the routine is called, this becomes a CAT-call: some arguments are expected, but none are given. This results in a run-time failure as you described. A solution would be to check for additional rules to eliminate the possibility of CAT-calls altogether. A partial solution might be using variable-parameter agent types, similar to tuple types, and different conformance rules for them, not based on tuple types. But we are not there yet.

Best regards,
Alexander Kogtenkov

r...@amalasoft.com:

[r...@amalasoft.com]

Thanks Alexander.  Clear and rational.

R

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/1560519046.935356139%40f405.i.mail.ru.