Hi,
"I think we're in agreement here. The idea of "IupPostMessage",
inspired from Windows PostMessage solves this problem elegantly. The
implementation specific ways to pull this off on each platform are
hidden from the user perspective."
Great.
"From my "Idea 2" proposal, what I'm suggesting is the IUP API should
be able to take *any* Ihandle*.
// All I want to do is change my button's ACTIVE state.
IupPostMessage(my_iup_button, 42, audio_data);"
Use IUP style and tools.
IupSetAttributeHandle(my_iup_button, "the_dialog", the_dialog);
Now you have a native handler (windows handler) inside your
button widget and easy use PostMessage to solve GUI update without
add any cost and more unnecessary functions calls
"This is more natural in how people may want to use it. I want to
change the button. From an objective standpoint, if I just want to
change the button, it makes no sense to think about a dialog.
So I think it is less reasonable to demand that I do:
// All I want to do is change my button's ACTIVE state. Why am
I passing a dialog?
IupPostMessage(some_dialog, 42, audio_data);
And then in the callback, figure out how to get my_iup_button."
Again, IUP have a style for this.
"I don't think this is a legitimate or fair argument. Unless you can
demonstrate in a real world context where this one call will have a
measurable performance impact, the cost of this one instruction is a
rounding error. (There's quite a bit of other stuff you would want to
focus on first in the IUP codebase if you were worried about this
minutia of performance.) Remember, we're talking about Windows where
they've optimized the heck out of this low-level stuff and everybody
is on powerful CPUs with branch-prediction and tons of cache. We're
not talking about 6502's here."
IUP have a lot slow algorithms: array dynamic implementation is very
inefficient,
hash string too. Add more inefficiencies do not help.
Kiss please. Less is more.
"I think we agree again."
Good to know.
"I merely argue that PostThreadMessage is a better, more general, and
more correct solution than PostMessage. If PostMessage can be made to
work and address the shortcomings I believe it has, then I would
happily give it my blessing.
Ultimately, this is an implementation issue. It's only constraint is
what we want the public API to be able to handle. Nobody in the end is
going to know the difference if we do it right."
Again, Raymond Chen, explain: "The correct solution was illustrated last time."
https://blogs.msdn.microsoft.com/oldnewthing/20050427-10/?p=35763
PostTheardMessage is the complicated and wrong way to solve this.
"Again, I think that is a very unfair accusation to level against me.
I have presented a working prototype, a specification of the feature,
and a general implementation plan."
I'm sorry, but technical arguments is welcome, bogus arguments not.
"As part of the Windows specific implementation, I include explanation
of why I think PostThreadMessage is better than PostMessage: because
it allows us to construct a general API that takes any widget,
allowing the user focus on any widget instead of a just a dialog.
If I misunderstand how PostMessage works, and it can be used for
arbitrary controls (e.g. the button and not just dialogs), then I will
happily cede to that point. That is the thing I hope somebody will
address, but so far, nobody has corrected that specific point."
Again, using IUP style and tools.
Add reference to your controls and you have all necessary to make the work.
Best regards,
Ranier Vilela
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
