Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#3 Bug comparing signals...

closed
nobody
None
5
2004-11-13
2004-10-18
Anonymous
No

The use of signal::result_signal() in combination with
signal::operator==() does not give the expected result.

The easiest way to reproduce the incorrect behavior is
to wait for the signal
"wait_for::key_pressed(VK_RETURN)" and then compare the
signal returned by wait() to
"wait_for::key_pressed(VK_RETURN)". The two will not
compare as equal even when the return key is pressed.

The method signal::result_signal() copies the internals
of the signal and then sets the various fields to the
values passed in (these come from the windows message
itself) including the lparam, which in the case of a
WM_KEYDOWN message will be some number based on the
repeat count of the keypress etc. signal::operator==()
compares the various fields of the two signals. The
predefined signal (key_pressed(VK_RETURN)) will have
m_lparam == 0 since this is a msg_w_param signal type,
and the signal returned by signal::result_signal() has
some other value for m_lparam, so the two do not
compare as equal.

The bug here is either the fact that
signal::result_signal() is altering unused fields (i.e.
changing the m_lparam member for a msg_w_param signal)
or that signal::operator==() is comparing unused
fields, or both.

my email is: squiremyrkle@fastmail.fm if you have any
questions.

Discussion

  • John Torjo
    John Torjo
    2004-10-18

    Logged In: YES
    user_id=1031729

    Thanks - I will cerainly look into it.

    I added result_signal() recently - in order to cope with
    another bug :)

    That is, you might be waiting for:
    wait_for::any_button_pushed.

    Afterwards, you'd want to know which button got pushed.

    Best,
    John

     
  • John Torjo
    John Torjo
    2004-11-13

    • status: open --> closed
     
  • John Torjo
    John Torjo
    2004-11-13

    Logged In: YES
    user_id=1031729

    Yup, thanks. Solved in v1.6+.