writeCB vs. leaveCB
Brought to you by:
dannybackx
Menu
▾
▴
#64 writeCB vs. leaveCB
In the XbaeMatrix manpage, it's repeated several times
that when drawCB is used, one should use writeCB for
storing data back. I wonder why it's better than
leaveCB? On the contrary, leaveCB provides the nice
"doit" field which allows me to validate the input and
force user to remain in the cell if the input is
invalid. (Theoretically, I could call EditCell from the
write callback, but this results in crash ;-().
Logged In: YES
user_id=101470
I guess you're supposed to use both, leaveCB to validate
and writeCB to store the data back. I see why that makes
you unhappy because you have to parse the content
twice. Here is what happens:
When you leave a cell DoCommitEdit is called. It in
turn calls the leaveCellCB. If it's ok to leave then it
calls the matrix's set_cell method. This one calls
the writeCellCBs.
The only other place where set_cell method is called
is through the public interface XbaeMatrixSetCell, which
you probably don't use anyhow. So if nobody messes
with the set_cell method of the matrix you should be
fine as far as using the leaveCB and have no writeCB.
Now let me speculate why it's done this way. This also
explain the issues we were talking about in bug #1119856
"XmNdrawCellCallback() semantics". (why XbaeMatrixGetCell
calls the drawcellCB):
I suppose that the drawcellCB buisness apeared later in
the game. The person who implemented it was pretty
smart: it's done in such a way that if you want to convert
an application that does not use a drawcellCB to one that
does, all you have to do is write the drawcellCB and the
writecellCB and you're done. You don't need to change
anything else in your app. Pretty nifty!
Tobias.
Logged In: YES
user_id=27019
> I guess you're supposed to use both, leaveCB to validate
and writeCB to store the data back.
Well, but my point is I can manage both validation and
storing with leaveCB alone. I see no need to use writeCB at
all. Am I missing some usage scenario?
Logged In: YES
user_id=101470
>> I guess you're supposed to use both, leaveCB to validate
>> and writeCB to store the data back.
> Well, but my point is I can manage both validation and
> storing with leaveCB alone. I see no need to use writeCB at
> all. Am I missing some usage scenario?
Sometime in the not so distant future I'll get hung
for this post.
As long as you're not relying on calling yourself
XbaeMatrixSetCell to write back changes to your
app and don't intend to replace XbaeMatrix by a
widget that's derived from it[*], you should get as
many leaveCB as you would have writeCB and
be fine. But why the bother? It's user interaction
you're dealing with, what's one more call to a
callback and a strtod? If I were you I'd errr on
the safe side and have both callbacks. Sometimes
you have to sacrifice a tiny amount of performance
for safety. (Reminds me of this patch to grace that
got rejected for using fdopen when it was
improving performance by a very noticable
amount :^)
Tobias.
[*] I'm no Motif expert, so I'm not sure under what
circumstance a Widget's class method can be
changed.
Logged In: YES
user_id=27019
> Sometimes you have to sacrifice a tiny amount of
performance for safety.
It's not about performance. It's about having all the
relevant logic in one place instead of splitting it (for no
apparent reason). Further, the safety lies on the same side,
since there is no guarantee that no X event enters between
the two callback calls, so in theory, you can get different
values in writeCB and leaveCB. The chance is tiny, but it
exists.
> (Reminds me of this patch to grace that got rejected for
using
> fdopen when it was improving performance by a very noticable
amount :^)
"Duel! Duel! - chirruped the girls excitedly." ;-)
Logged In: YES
user_id=27019
> As long as you're not relying on calling yourself
XbaeMatrixSetCell
We all agree that using XbaeMatrixSetCell when a writeCB is
defined is stupid. I'll further argue that it's unsafe and
unreliable - there is always a chance that an expose event
will be delivered by Xt right after the XbaeMatrixSetCell()
call, which will overwrite the value set. I'd suggest to
issue XtWarning and/or ignore XbaeMatrixSetCell at all in
such cases.