[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
set_field_init/term() / field_init/term() calls -> wrongly implemented a
From: |
Frank van Vugt |
Subject: |
set_field_init/term() / field_init/term() calls -> wrongly implemented at the moment? |
Date: |
Sun, 11 Sep 2005 17:32:40 +0200 |
User-agent: |
KMail/1.8 |
Hi,
At the moment, set_field_init/term() and field_init/term() calls aren't
implemented correctly, at least in my opinion ;) They are exactly the same as
their form counterparts, as opposed to providing means to add hooks to fields
themselves.
Since a number of the prerequisites seem to be there already and the manual
does imply that for these functions the hooks should be on the fields instead
of the form, I came up with a patch for this. This turned out to be a bit
more invasize than initially expected in that it touches more files than
expected, but anyway ;)
Already done:
- added type_def and extern declarations to form.h
- added type_def and extern declarations to form.priv.h
- added template macro's and changed calls in frm_hook.c
- added macro to f_trace.c
- added implementations to llib-lform and llib-lformw
- changed parameters in fld_current.c Call_Hook calls
- removed Call_Hook field calls in frm_page.c
- changed frm_def.c appropriately
- changed fld_def.c appropriately
- changed frm_driver.c to remove Call_Hook's to fields on page events
- changed frm_post.c to remove Call_Hook's to fields on page events
- removed 2 lines of code from c++ wrapper involving 'old-style'
set_field_init/term
Now, the formnode struct was the one holding the pointers for field_init/term
and these were pointing to forms instead of fields. I've moved these over to
the fieldnode instead, but the last item in the fieldnode was the
NCURSES_FIELD_INTERNALS macro. I suppose the best place for the pointers
would be just before it (although the macro expands to variables, not to
functions), but Thomas, could you either confirm that you'd like to see them
here or propose a different location?
Mind you, though the patch involves an API change, it's obviously just
changing the duplicate (set_)field_init/term into what it 'supposed' to have
been. Existing code should be able to easily and transparantly change calls
from (set_)field_init/term into (set_)form_init/term if they originally meant
to do the latter anyway. Hopefully this is enough reason to include the
patch in a minor version change, instead of having to wait till a major
one ;)
What might be necessary / wanted still:
- change docs (Thomas, you probably have those in some generic form, so I
didn't patch them, be just let me know if you want me to)
- split frm_hook.c into frm_hook.c and fld_hook.c, this might make a bit more
sense
- adding additional Call_Hook's for fields to certain events, I haven't
searched for such events exhaustively
- change the mechanism with which we get the field pointer in
frm_driver.c:3411/3, though I don't expect anything 'wrong' with was is done
currently
- change the c++ wrapper appropriately (I'm not sure what it's author would
like to see regarding this patch)
The patch itself has been sent to Thomas off-list, but is available upon
request. If you want to review it, you obviously will need it ;)
Though it could be construed as 'not done', I'd like to check up on the but
regarding inconsequent handling of field_status for fields not marked
O_EDIT :
> > However, pressing <arrow_right> before entering a regular key WILL mark
> > the field as dirty (field_status() returns true), though obviously it's
> > contents won't change.
> thanks (will check/fix)
Any remarks/progress on this, Thomas? You were able to duplicate it, weren't
you? (I'm asking to rule out involvement of my 'O_STATIC implies unneccesar
special justificationy' patch)
--
Best,
Frank.