On 4/18/18, Ranier VF <ranier_...@hotmail.com> wrote:
> Hi,
> I strong believe thar PostMessage solves the request: "update gui, outside
> main thread"
> Native handles, like Windows Handle, is hidden from the user perspective.
> Therefore using in Windows driver and not using in GTK, IOS and Android
> drivers, will not disturb users.
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.
> In your example, You use a button widget, but can receive and process all
> messages is the Window Handler inside "Ihandle the_dialog."
> In this way, add one field to store native handler, in user_data structure
> and use only with Windows Functions API formal proposal.
>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);
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.
> Touching Windows Event Loop will add one branch and one function call,
> in every message received by app, slowing down more and more.
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.
> Summing up:
> All drivers are free to implement in your own way, and from the users
> perspective,
> no matter how it was solved.
I think we agree again.
> Using Native Handler (windows), inside API, hidden from the user, works.
We agree again.
> PostMessage solves the problem, without add any cost and slowing event
> loop.
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.
> Attempts to confuse the discussion, with evasive allegations, as users
> doubts, they do not help!
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.
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.
Thanks,
Eric
------------------------------------------------------------------------------
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
