Hi.
If there are several callbacks to a widget, do we have a guaranteed order of
callback calls?
For example, if we have three callbacks, callback1, callback2 and callbak3.
They are added in the given order. Are they also called in the order they
were added (always)?
I have looked in the docs and I haven’t seen any mention of callback order.
Is it there?
Thanks
Augie
Augie Henriques <augiehenriques@hotmail.com> wrote:
Hi.
If there are several callbacks to a widget, do we have a guaranteed order of
callback calls?
No. I asked that internally a while ago, and was told that there
is Really Truly Never going to be a guarantee about that. If you
need to synchronize things, you’d have to have a single callback
from which you call out to other functions.
Historically, the order in which they’ve been added to the widget
has been the order in which they’re called, but it would be a
Very Bad Idea to write code which depends on this continuing.
Norbert Black
QSSL Training Services
Hi Norbert.
Thanks for the reply first of all.
“Norbert Black” <nblack@qnx.com> wrote in message
news:95sj96$fnq$1@nntp.qnx.com…
Augie Henriques <> augiehenriques@hotmail.com> > wrote:
Hi.If there are several callbacks to a widget, do we have a guaranteed
order of
callback calls?No. I asked that internally a while ago, and was told that there
is Really Truly Never going to be a guarantee about that. If you
need to synchronize things, you’d have to have a single callback
from which you call out to other functions.
I would be glad to take your suggestion. But for some reason the behavior
of the code is not the same. It seems that Photon gets in between callback
calls and does something, what? Is it possible to make the same call from
inside my callback, in between function calls?
For example, if I want
… Callback(…) {
Callback1();
// need to sync photon ?
Callback2();
// need to sync photon ?
Callback3();
}
instead of having three separate callbacks.
Historically, the order in which they’ve been added to the widget
has been the order in which they’re called, but it would be a
Very Bad Idea to write code which depends on this continuing.
Agreed. Give me a solution?
Norbert Black
QSSL Training Services
Thanks
Augie
Augie Henriques <augiehenriques@hotmail.com> wrote:
“Norbert Black” <> nblack@qnx.com> > wrote in message
news:95sj96$fnq$> 1@nntp.qnx.com> …
Augie Henriques <> augiehenriques@hotmail.com> > wrote:
If there are several callbacks to a widget, do we have a guaranteed
order of callback calls?No. I asked that internally a while ago, and was told that there
is Really Truly Never going to be a guarantee about that. If you
need to synchronize things, you’d have to have a single callback
from which you call out to other functions.I would be glad to take your suggestion. But for some reason the behavior
of the code is not the same. It seems that Photon gets in between callback
calls and does something, what?
Each time you return to the event processing loop (which is what
happens when you do a “return( Pt_CONTINUE )”, there is a fair
amount that could be happening in between the individual
callbacks. Prime candidates would include freeing memory of any
widgets you called PtDestroyWidget() upon in the individual
callback and flushing the graphics buffers.
Knowing what you are doing in each callback (and what the
change in behaviour is), you’re in a better position to judge
what sort of thing you might try to duplicate behaviours. See
below, though.
Is it possible to make the same call from
inside my callback, in between function calls?For example, if I want
… Callback(…) {
Callback1();
// need to sync photon ?
Callback2();
// need to sync photon ?
Callback3();
}instead of having three separate callbacks.
In a 1.1x application, you could try PtSyncPhoton(). Look
carefully at the warnings section of the docs, though. 2.x
deprecates this function, as well. PtFlush() is available in
both, and might do what you need, depending on what change in
behaviour you’re seeing.
Good luck!
Norbert Black
QSSL Training Services
“Norbert Black” <nblack@qnx.com> wrote in message
news:95upku$or4$1@nntp.qnx.com…
Augie Henriques <> augiehenriques@hotmail.com> > wrote:
“Norbert Black” <> nblack@qnx.com> > wrote in message
news:95sj96$fnq$> 1@nntp.qnx.com> …
Augie Henriques <> augiehenriques@hotmail.com> > wrote:
If there are several callbacks to a widget, do we have a guaranteed
order of callback calls?No. I asked that internally a while ago, and was told that there
is Really Truly Never going to be a guarantee about that. If you
need to synchronize things, you’d have to have a single callback
from which you call out to other functions.I would be glad to take your suggestion. But for some reason the
behavior
of the code is not the same. It seems that Photon gets in between
callback
calls and does something, what?Each time you return to the event processing loop (which is what
happens when you do a “return( Pt_CONTINUE )”, there is a fair
amount that could be happening in between the individual
callbacks. Prime candidates would include freeing memory of any
widgets you called PtDestroyWidget() upon in the individual
callback and flushing the graphics buffers.Knowing what you are doing in each callback (and what the
change in behaviour is), you’re in a better position to judge
what sort of thing you might try to duplicate behaviours. See
below, though.Is it possible to make the same call from
inside my callback, in between function calls?For example, if I want
… Callback(…) {
Callback1();
// need to sync photon ?
Callback2();
// need to sync photon ?
Callback3();
}instead of having three separate callbacks.
In a 1.1x application, you could try PtSyncPhoton(). Look
carefully at the warnings section of the docs, though. 2.x
deprecates this function, as well. PtFlush() is available in
both, and might do what you need, depending on what change in
behaviour you’re seeing.
I didn’t try PtSyncPhoton, but I did try PtFlush() and again the behavior is
not the same as having the separate callbacks. Using PtFlush() in my case
is the same as not using it at all.
Whatever is getting done in between callbacks, I would like to be able to do
in the above example.
During the resize, …
I change the size for the PtWindow widget. The minimum size is enforced and
the size and position are kept for saving/restoring the application
workspace. (This is normally done in the Window Manager function under the
Ph_WM_RESIZE case). I also cause a damage to the PtRaw widget inside the
PtWindow.
Then, …
Several other widgets (PtLabel and PtText) are positioned around inside the
PtWindow. The number of these widgets determines the size and position for
the PtRaw widget. The PtRaw widget is in a PtGroup widget which is anchored
to the PtWindow on all sides.
Once this takes place,
I need to display some other PtLabel and PtText widgets with certain data
values on one of the sides of the resized PtRaw/PtGroup widget.
Finally,
Need to get the size for the PtRaw/PtGroup widgets and allocate/copy/free
buffers for this window display.
Once all of this is done, the damage to the PtRaw widget should cause the
data inside the PtRaw widget to get displayed.
At the moment, by putting these in separate callbacks to the PtGroup widget
resize callback, I can get Photon to update the size/position/data for all
the widgets. Once I place this inside one callback, then nothing works
anymore, because in certain instances is still using the old sizes instead
of the new sizes.
I hope this explains what I need to do. What sort of function call do I
need to make to have Photon update the widget size/position/data?
Thanks
Augie
Good luck!
Norbert Black
QSSL Training Services
Augie Henriques <augiehenriques@hotmail.com> wrote:
[more details]
Hi Augie
No time for a detailed answer (or really to read carefully –
deadline crunch time), but if you’re having trouble with sizes,
try using the PtWidgetExtent() and PtWidgetExtentFamily() calls
to force the widgets to redo their geometry negotiation before
you try to find out what size/position things are in. It sounds
like you might be getting “stale” information that would be
recalculated when the library got a chance to get back at your
app.
Sorry, that’s really vague, but that’s all the water there is in
the well tonight. 
Norbert Black
QSSL Training Services