bug-ncurses
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]