Re: [AD] Button callback function (was: Grabber - options dialog box)

[ Thread Index | Date Index | More Archives ]

> > I think it wouldn't hurt to extend the DIALOG structure for new functionality.
> > AFAICS, it doesn't break anything...
> I think it's getting excessive.  The DIALOG struct has gone from
> having just a dp, to a dp and a dp2 (so the user gets dp2), but
> then people implemented built-in objects which use dp2 so dp3
> was created... which is now also being used by built-in objects.
> If a new pointer field is added, this time it *must* be reserved
> for the user without question.  Ideally the GUI system would be
> rethought, but that's a matter of opinion, and it's already been
> done in addons and better GUI systems.
> In any case, d_button_proc should not use dp3 -- it would break
> compatibility with existing user code (whether a new pointer is
> added or not).  The only 'solution' for having a callback proc
> would be adding a new pointer and using that instead, which,
> again, I don't think is a good idea.

Well obviously d_button_proc() can't decide to suddenly use either dp2 or
dp3. Doing anything of the sort is going to break existing code (my own
I agree the dialog struct hardly needs an other pointer, but I do think a
general callback function pointer for all widgets is both useful and
But I agree that adding both a callback and a new user_data field is going
to be excessive.

Mail converted by MHonArc 2.6.19+