[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ncurses/Forms unfocus current field

From: Thomas Dickey
Subject: Re: Ncurses/Forms unfocus current field
Date: Sun, 16 Oct 2016 20:50:46 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Oct 13, 2016 at 12:27:22PM +0200, Leon Winter wrote:
> Hi Thomas,
> we are using ncurses/forms in our application and ran into the following 
> issue:
> We have a current field where we enter some data. Afterwards we retrieve the
> field buffer and do some computation. Then we would like to change some
> attributes of the field, do some more computation and based on that, move to 
> the
> next field. While changing field attributes (field_{back,fore,pad}) of the
> current field is possible, one cannot do the same for field options 
> (field_opts)
> like O_PUBLIC and such. One can argue that field options can change important
> properties of the field (like O_STATIC) which are impossible to do to a 
> current
> field. However in our use case we do not want the current field to be focussed
> anymore. We are in between two fields, where neither is focussed.
> However with the current implementation this seems to be impossible. In fact, 
> it
> seems one field is always the current field and there is no way to not have
> current field expect having no fields at all.
> As a workaround one could introduce a dummy field where one would jump to
> anytime to simulate the "in between fields" state. Another way is to enable
> forms to unfocus the current field and not focus another one.
> I opted for the latter and developed a quick and dirty patch for it (see
> attached). "set_current_field (form, 0)" is my semantic for unfocussing the
> current field while not focussing a new field at the same time.
> What would you recommend?
> - Using a dummy field as work-around
> - Polishing the patch and enabling ncurses/forms to not have a current field
> - something else

hmm - that's hard: there's no mode to say when this feature should be
valid (as opposed to being a potential error).

I'm thinking in terms of compatibility, wondering what could break(?)

Thomas E. Dickey <address@hidden>

Attachment: signature.asc
Description: Digital signature

reply via email to

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