Avoid "married" in civil status for member aged 18 and below

Good day,

I'm not sure if this issue it already posted here.

I'm using XLSForm, how will i avoid the user to select "married" in civil
status choices for member's aged 18 years old and below.

Thank you..

Your question is not very specific but sounds simple. How about you set a
constraint saying that if ${Qage} < 18 select(.) != "married"

··· Le lundi 16 février 2015 09:15:37 UTC+7, neil jerson a écrit : > > Good day, > > I'm not sure if this issue it already posted here. > > I'm using XLSForm, how will i avoid the user to select "married" in civil > status choices for member's aged 18 years old and below. > > > Thank you.. >

Thank you so much..

I more question..

We are collecting basic data of the household members. Wherein we would
like to restrict the user to choose one Household Head and Spouse in the
"Relationship to the Head" question.

Is there any suggestion to address this concern?

Thank you very much..

In general, to solve this problem, you must make an assumption about the
maximum number of cohabitants.

When people have constraints like this, we often recommend they "unroll"
their repeat group. If you think about copying the questions in your repeat
group into the main form, giving each copy unique field names, then you can
easily figure out how to constrain relationship8 so that it does not claim
any of the restricted relationship categories that relationships 1-7 may
have already claimed.

Mitch

··· On Mon, Feb 16, 2015 at 5:03 PM, neil jerson wrote:

Thank you so much..

I more question..

We are collecting basic data of the household members. Wherein we would
like to restrict the user to choose one Household Head and Spouse in the
"Relationship to the Head" question.

Is there any suggestion to address this concern?

Thank you very much..

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

Hello Neil,

please how did you eventually solve this issue (restricting the first
response in the repeat group to Head of household)? Have the same issue
holding a form am designing.

Your thoughts will be highly appreciated. Thank you.

··· On Tuesday, February 17, 2015 at 2:03:22 AM UTC+1, neil jerson wrote: > > Thank you so much.. > > > I more question.. > > > We are collecting basic data of the household members. Wherein we would > like to restrict the user to choose one Household Head and Spouse in the > "Relationship to the Head" question. > > > Is there any suggestion to address this concern? > > Thank you very much.. >

Thank you so much Mitch for the clarification.

In this question: I'm using repeat for questioning the household members
data. Wherein i asked first the user to enter the total number of
household members before asking the basic data of the members which include
it's relationship to the household head.

I have try to solve this yesterday, where i assumed that member 1 is for
the household head and member 2 is for the household spouse. Using
constraint:

For member 1 - household head only
For member 2 - household spouse and other relationship except for
household head
For member 3 and N - Other relationship except for Household head and
spouse.

It works fine. But i'm wondering if it is still possible to remove/hide
some choices, like:

For member 1 - Relationship to the Head is always Household Head, if
possible not to asked this question.
For member 2 - Remove/Hide the Household Head in the choices list
For member 3 and N - Remove/Hide the Household Head and Spouse in the
choices list.

Only if this is possible... That would be great...

Thank you so much for the quick response.

··· On Tuesday, February 17, 2015 at 10:14:35 AM UTC-8, Mitch Sundt wrote: > > In general, to solve this problem, you must make an assumption about the > maximum number of cohabitants. > > When people have constraints like this, we often recommend they "unroll" > their repeat group. If you think about copying the questions in your repeat > group into the main form, giving each copy unique field names, then you can > easily figure out how to constrain relationship8 so that it does not claim > any of the restricted relationship categories that relationships 1-7 may > have already claimed. > > Mitch > > > On Mon, Feb 16, 2015 at 5:03 PM, neil jerson <bara...@gmail.com > wrote: > >> Thank you so much.. >> >> >> I more question.. >> >> >> We are collecting basic data of the household members. Wherein we would >> like to restrict the user to choose one Household Head and Spouse in the >> "Relationship to the Head" question. >> >> >> Is there any suggestion to address this concern? >> >> Thank you very much.. >> >> -- >> -- >> Post: opend...@googlegroups.com >> Unsubscribe: opendatakit...@googlegroups.com >> Options: http://groups.google.com/group/opendatakit?hl=en >> >> --- >> You received this message because you are subscribed to the Google Groups >> "ODK Community" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to opendatakit...@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Mitch Sundt > Software Engineer > University of Washington > mitche...@gmail.com >

Hi Chinedu,

The simplest thing to do is to ask the questions for the head of
household outside the repeat. Then the repeat will be about rest of
the household.

You could also ask in the repeat if this person is a head of household
and decide based on that answer. And you can default to no if you
trust your data collectors to do the right thing.

You could also use position(..) to get the number of the repeat and
decide based on that, but that tends to be fragile because the numbers
change when you delete instances of the repeat.

Yaw

··· -- Need ODK consultants? Nafundi provides form design, server setup, in-field training, and software development for ODK. Go to https://nafundi.com to get started.

On Wed, Aug 10, 2016 at 5:24 PM, Chinedu Arinze chinedar@gmail.com wrote:

Hello Neil,

please how did you eventually solve this issue (restricting the first
response in the repeat group to Head of household)? Have the same issue
holding a form am designing.

Your thoughts will be highly appreciated. Thank you.

On Tuesday, February 17, 2015 at 2:03:22 AM UTC+1, neil jerson wrote:

Thank you so much..

I more question..

We are collecting basic data of the household members. Wherein we would
like to restrict the user to choose one Household Head and Spouse in the
"Relationship to the Head" question.

Is there any suggestion to address this concern?

Thank you very much..

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Perhaps.

Repeat groups and referencing different iterations within them is pushing
the capabilities of the JavaRosa library. While the form definitions are
based upon the XForms spec, and that supports full XPath expressions to
reference fields and field values, the implementation in JavaRosa is not as
full-featured and is somewhat buggy w.r.t. the specification.

You generally cannot both suppress the display of the question (via the
relevant condition) and give that question a value
. If the question is
not relevant, then it will have no value when finalized. So you could
possibly suppress the answer for the first member of household, but it
would be blank in the collected dataset.

Another approach is to supply a default value for this answer that is the
value for the 'head of household' choice. Then, at least, on the first (and
all subsequent) member data screens, it would be pre-populated with
'head-of-household' so you would just need to advance past that question
without changing the selection. And all other members would need to change
it to something else.

As for the constraint formula to ensure that head-of-household is only used
for the first member, you could perhaps write something like:

if( position(..) = 1, selected(.,'head-of-household'), not(
selected(.,'head-of-household'))

The JavaRosa library can, however, behave unexpectedly when using the ../
syntax to reference elements (in this case, I am trying to reference the
parent of this field, and am assuming that is the repeat group, and then I
am asking JavaRosa to give us the ordinal number of this instance of the
repeat group (i.e., we are testing whether it is the 1st repeat group (the
head-of-household)).

Whenever you try to write constraints like this for repeat groups, it is
important that you test your formulas when there are 0, 1, and 2 or more
instances of the repeat group. Often, there will be problems with the
formulas when filling in the 2nd instance.

This is one reason why 'unrolling' the repeat group is recommended.

··· On Tue, Feb 17, 2015 at 6:27 PM, neil jerson wrote:

Thank you so much Mitch for the clarification.

In this question: I'm using repeat for questioning the household members
data. Wherein i asked first the user to enter the total number of
household members before asking the basic data of the members which include
it's relationship to the household head.

I have try to solve this yesterday, where i assumed that member 1 is for
the household head and member 2 is for the household spouse. Using
constraint:

For member 1 - household head only
For member 2 - household spouse and other relationship except for
household head
For member 3 and N - Other relationship except for Household head and
spouse.

It works fine. But i'm wondering if it is still possible to remove/hide
some choices, like:

For member 1 - Relationship to the Head is always Household Head, if
possible not to asked this question.
For member 2 - Remove/Hide the Household Head in the choices list
For member 3 and N - Remove/Hide the Household Head and Spouse in the
choices list.

Only if this is possible... That would be great...

Thank you so much for the quick response.

On Tuesday, February 17, 2015 at 10:14:35 AM UTC-8, Mitch Sundt wrote:

In general, to solve this problem, you must make an assumption about the
maximum number of cohabitants.

When people have constraints like this, we often recommend they "unroll"
their repeat group. If you think about copying the questions in your repeat
group into the main form, giving each copy unique field names, then you can
easily figure out how to constrain relationship8 so that it does not claim
any of the restricted relationship categories that relationships 1-7 may
have already claimed.

Mitch

On Mon, Feb 16, 2015 at 5:03 PM, neil jerson bara...@gmail.com wrote:

Thank you so much..

I more question..

We are collecting basic data of the household members. Wherein we would
like to restrict the user to choose one Household Head and Spouse in the
"Relationship to the Head" question.

Is there any suggestion to address this concern?

Thank you very much..

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to the Google
Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

Thanks a lot Yaw,

will run it outside the repeat now and see how it turns up.

Best Regards,
Chinedu Arinze.

··· On 11 August 2016 at 13:12, Yaw Anokwa wrote:

Hi Chinedu,

The simplest thing to do is to ask the questions for the head of
household outside the repeat. Then the repeat will be about rest of
the household.

You could also ask in the repeat if this person is a head of household
and decide based on that answer. And you can default to no if you
trust your data collectors to do the right thing.

You could also use position(..) to get the number of the repeat and
decide based on that, but that tends to be fragile because the numbers
change when you delete instances of the repeat.

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Wed, Aug 10, 2016 at 5:24 PM, Chinedu Arinze chinedar@gmail.com wrote:

Hello Neil,

please how did you eventually solve this issue (restricting the first
response in the repeat group to Head of household)? Have the same issue
holding a form am designing.

Your thoughts will be highly appreciated. Thank you.

On Tuesday, February 17, 2015 at 2:03:22 AM UTC+1, neil jerson wrote:

Thank you so much..

I more question..

We are collecting basic data of the household members. Wherein we would
like to restrict the user to choose one Household Head and Spouse in the
"Relationship to the Head" question.

Is there any suggestion to address this concern?

Thank you very much..

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to a topic in the
Google Groups "ODK Community" group.
To unsubscribe from this topic, visit https://groups.google.com/d/
topic/opendatakit/TizC3Sm3VE4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Thank you so much Mitch.

I've tried to look for any reference on how to unroll the repeat group.

Can i ask some reference on how i will unroll the repeat group to met this
condition.

Thank you..

··· On Wednesday, February 18, 2015 at 9:35:55 AM UTC-8, Mitch Sundt wrote: > > Perhaps. > > Repeat groups and referencing different iterations within them is pushing > the capabilities of the JavaRosa library. While the form definitions are > based upon the XForms spec, and that supports full XPath expressions to > reference fields and field values, the implementation in JavaRosa is not as > full-featured and is somewhat buggy w.r.t. the specification. > > *You generally cannot both suppress the display of the question (via the > relevant condition) and give that question a value*. If the question is > not relevant, then it will have no value when finalized. So you could > possibly suppress the answer for the first member of household, but it > would be blank in the collected dataset. > > *Another approach* is to supply a default value for this answer that is > the value for the 'head of household' choice. Then, at least, on the first > (and all subsequent) member data screens, it would be pre-populated with > 'head-of-household' so you would just need to advance past that question > without changing the selection. And all other members would need to change > it to something else. > > As for the constraint formula to ensure that head-of-household is only > used for the first member, you could perhaps write something like: > > if( position(..) = 1, selected(.,'head-of-household'), not( > selected(.,'head-of-household')) > > The JavaRosa library can, however, behave unexpectedly when using the ../ > syntax to reference elements (in this case, I am trying to reference the > parent of this field, and am assuming that is the repeat group, and then I > am asking JavaRosa to give us the ordinal number of this instance of the > repeat group (i.e., we are testing whether it is the 1st repeat group (the > head-of-household)). > > Whenever you try to write constraints like this for repeat groups, it is > important that you test your formulas when there are 0, 1, and 2 or more > instances of the repeat group. Often, there will be problems with the > formulas when filling in the 2nd instance. > > This is one reason why 'unrolling' the repeat group is recommended. > > > On Tue, Feb 17, 2015 at 6:27 PM, neil jerson <bara...@gmail.com > wrote: > >> Thank you so much Mitch for the clarification. >> >> >> In this question: I'm using repeat for questioning the household members >> data. Wherein i asked first the user to enter the total number of >> household members before asking the basic data of the members which include >> it's relationship to the household head. >> >> I have try to solve this yesterday, where i assumed that member 1 is for >> the household head and member 2 is for the household spouse. Using >> constraint: >> >> For member 1 - household head only >> For member 2 - household spouse and other relationship except for >> household head >> For member 3 and N - Other relationship except for Household head and >> spouse. >> >> >> It works fine. But i'm wondering if it is still possible to remove/hide >> some choices, like: >> >> For member 1 - Relationship to the Head is always Household Head, if >> possible not to asked this question. >> For member 2 - Remove/Hide the Household Head in the choices list >> For member 3 and N - Remove/Hide the Household Head and Spouse in the >> choices list. >> >> Only if this is possible... That would be great... >> >> >> >> Thank you so much for the quick response. >> >> >> >> On Tuesday, February 17, 2015 at 10:14:35 AM UTC-8, Mitch Sundt wrote: >>> >>> In general, to solve this problem, you must make an assumption about the >>> maximum number of cohabitants. >>> >>> When people have constraints like this, we often recommend they "unroll" >>> their repeat group. If you think about copying the questions in your repeat >>> group into the main form, giving each copy unique field names, then you can >>> easily figure out how to constrain relationship8 so that it does not claim >>> any of the restricted relationship categories that relationships 1-7 may >>> have already claimed. >>> >>> Mitch >>> >>> >>> On Mon, Feb 16, 2015 at 5:03 PM, neil jerson wrote: >>> >>>> Thank you so much.. >>>> >>>> >>>> I more question.. >>>> >>>> >>>> We are collecting basic data of the household members. Wherein we >>>> would like to restrict the user to choose one Household Head and Spouse in >>>> the "Relationship to the Head" question. >>>> >>>> >>>> Is there any suggestion to address this concern? >>>> >>>> Thank you very much.. >>>> >>>> -- >>>> -- >>>> Post: opend...@googlegroups.com >>>> Unsubscribe: opendatakit...@googlegroups.com >>>> Options: http://groups.google.com/group/opendatakit?hl=en >>>> >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "ODK Community" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to opendatakit...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> >>> -- >>> Mitch Sundt >>> Software Engineer >>> University of Washington >>> mitche...@gmail.com >>> >> -- >> -- >> Post: opend...@googlegroups.com >> Unsubscribe: opendatakit...@googlegroups.com >> Options: http://groups.google.com/group/opendatakit?hl=en >> >> --- >> You received this message because you are subscribed to the Google Groups >> "ODK Community" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to opendatakit...@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Mitch Sundt > Software Engineer > University of Washington > mitche...@gmail.com >

By 'unrolling', I mean copying the entire repeat group, then pasting it
multiple times into your spreadsheet, renaming all the fields, and removing
the repeat group entirely.

Very tedious.

··· On Wed, Feb 18, 2015 at 4:45 PM, neil jerson wrote:

Thank you so much Mitch.

I've tried to look for any reference on how to unroll the repeat group.

Can i ask some reference on how i will unroll the repeat group to met this
condition.

Thank you..

On Wednesday, February 18, 2015 at 9:35:55 AM UTC-8, Mitch Sundt wrote:

Perhaps.

Repeat groups and referencing different iterations within them is pushing
the capabilities of the JavaRosa library. While the form definitions are
based upon the XForms spec, and that supports full XPath expressions to
reference fields and field values, the implementation in JavaRosa is not as
full-featured and is somewhat buggy w.r.t. the specification.

You generally cannot both suppress the display of the question (via the
relevant condition) and give that question a value
. If the question is
not relevant, then it will have no value when finalized. So you could
possibly suppress the answer for the first member of household, but it
would be blank in the collected dataset.

Another approach is to supply a default value for this answer that is
the value for the 'head of household' choice. Then, at least, on the first
(and all subsequent) member data screens, it would be pre-populated with
'head-of-household' so you would just need to advance past that question
without changing the selection. And all other members would need to change
it to something else.

As for the constraint formula to ensure that head-of-household is only
used for the first member, you could perhaps write something like:

if( position(..) = 1, selected(.,'head-of-household'), not(
selected(.,'head-of-household'))

The JavaRosa library can, however, behave unexpectedly when using the ../
syntax to reference elements (in this case, I am trying to reference the
parent of this field, and am assuming that is the repeat group, and then I
am asking JavaRosa to give us the ordinal number of this instance of the
repeat group (i.e., we are testing whether it is the 1st repeat group (the
head-of-household)).

Whenever you try to write constraints like this for repeat groups, it is
important that you test your formulas when there are 0, 1, and 2 or more
instances of the repeat group. Often, there will be problems with the
formulas when filling in the 2nd instance.

This is one reason why 'unrolling' the repeat group is recommended.

On Tue, Feb 17, 2015 at 6:27 PM, neil jerson bara...@gmail.com wrote:

Thank you so much Mitch for the clarification.

In this question: I'm using repeat for questioning the household
members data. Wherein i asked first the user to enter the total number of
household members before asking the basic data of the members which include
it's relationship to the household head.

I have try to solve this yesterday, where i assumed that member 1 is for
the household head and member 2 is for the household spouse. Using
constraint:

For member 1 - household head only
For member 2 - household spouse and other relationship except for
household head
For member 3 and N - Other relationship except for Household head and
spouse.

It works fine. But i'm wondering if it is still possible to remove/hide
some choices, like:

For member 1 - Relationship to the Head is always Household Head, if
possible not to asked this question.
For member 2 - Remove/Hide the Household Head in the choices list
For member 3 and N - Remove/Hide the Household Head and Spouse in the
choices list.

Only if this is possible... That would be great...

Thank you so much for the quick response.

On Tuesday, February 17, 2015 at 10:14:35 AM UTC-8, Mitch Sundt wrote:

In general, to solve this problem, you must make an assumption about
the maximum number of cohabitants.

When people have constraints like this, we often recommend they
"unroll" their repeat group. If you think about copying the questions in
your repeat group into the main form, giving each copy unique field names,
then you can easily figure out how to constrain relationship8 so that it
does not claim any of the restricted relationship categories that
relationships 1-7 may have already claimed.

Mitch

On Mon, Feb 16, 2015 at 5:03 PM, neil jerson bara...@gmail.com wrote:

Thank you so much..

I more question..

We are collecting basic data of the household members. Wherein we
would like to restrict the user to choose one Household Head and Spouse in
the "Relationship to the Head" question.

Is there any suggestion to address this concern?

Thank you very much..

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to the Google
Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com

--

Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to the Google
Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

Thank you Mitch.

So that what "unroll" means..

I think i'll prefer on the first options.

Thanks again..

··· On Thursday, February 19, 2015 at 10:06:32 AM UTC-8, Mitch Sundt wrote: > > By 'unrolling', I mean copying the entire repeat group, then pasting it > multiple times into your spreadsheet, renaming all the fields, and removing > the repeat group entirely. > > Very tedious. > > On Wed, Feb 18, 2015 at 4:45 PM, neil jerson <bara...@gmail.com > wrote: > >> Thank you so much Mitch. >> >> >> I've tried to look for any reference on how to unroll the repeat group. >> >> Can i ask some reference on how i will unroll the repeat group to met >> this condition. >> >> >> Thank you.. >> >> On Wednesday, February 18, 2015 at 9:35:55 AM UTC-8, Mitch Sundt wrote: >>> >>> Perhaps. >>> >>> Repeat groups and referencing different iterations within them is >>> pushing the capabilities of the JavaRosa library. While the form >>> definitions are based upon the XForms spec, and that supports full XPath >>> expressions to reference fields and field values, the implementation in >>> JavaRosa is not as full-featured and is somewhat buggy w.r.t. the >>> specification. >>> >>> *You generally cannot both suppress the display of the question (via the >>> relevant condition) and give that question a value*. If the question >>> is not relevant, then it will have no value when finalized. So you could >>> possibly suppress the answer for the first member of household, but it >>> would be blank in the collected dataset. >>> >>> *Another approach* is to supply a default value for this answer that is >>> the value for the 'head of household' choice. Then, at least, on the first >>> (and all subsequent) member data screens, it would be pre-populated with >>> 'head-of-household' so you would just need to advance past that question >>> without changing the selection. And all other members would need to change >>> it to something else. >>> >>> As for the constraint formula to ensure that head-of-household is only >>> used for the first member, you could perhaps write something like: >>> >>> if( position(..) = 1, selected(.,'head-of-household'), not( >>> selected(.,'head-of-household')) >>> >>> The JavaRosa library can, however, behave unexpectedly when using the >>> ../ syntax to reference elements (in this case, I am trying to reference >>> the parent of this field, and am assuming that is the repeat group, and >>> then I am asking JavaRosa to give us the ordinal number of this instance of >>> the repeat group (i.e., we are testing whether it is the 1st repeat group >>> (the head-of-household)). >>> >>> Whenever you try to write constraints like this for repeat groups, it is >>> important that you test your formulas when there are 0, 1, and 2 or more >>> instances of the repeat group. Often, there will be problems with the >>> formulas when filling in the 2nd instance. >>> >>> This is one reason why 'unrolling' the repeat group is recommended. >>> >>> >>> On Tue, Feb 17, 2015 at 6:27 PM, neil jerson wrote: >>> >>>> Thank you so much Mitch for the clarification. >>>> >>>> >>>> In this question: I'm using repeat for questioning the household >>>> members data. Wherein i asked first the user to enter the total number of >>>> household members before asking the basic data of the members which include >>>> it's relationship to the household head. >>>> >>>> I have try to solve this yesterday, where i assumed that member 1 is >>>> for the household head and member 2 is for the household spouse. Using >>>> constraint: >>>> >>>> For member 1 - household head only >>>> For member 2 - household spouse and other relationship except for >>>> household head >>>> For member 3 and N - Other relationship except for Household head and >>>> spouse. >>>> >>>> >>>> It works fine. But i'm wondering if it is still possible to >>>> remove/hide some choices, like: >>>> >>>> For member 1 - Relationship to the Head is always Household Head, if >>>> possible not to asked this question. >>>> For member 2 - Remove/Hide the Household Head in the choices list >>>> For member 3 and N - Remove/Hide the Household Head and Spouse in the >>>> choices list. >>>> >>>> Only if this is possible... That would be great... >>>> >>>> >>>> >>>> Thank you so much for the quick response. >>>> >>>> >>>> >>>> On Tuesday, February 17, 2015 at 10:14:35 AM UTC-8, Mitch Sundt wrote: >>>>> >>>>> In general, to solve this problem, you must make an assumption about >>>>> the maximum number of cohabitants. >>>>> >>>>> When people have constraints like this, we often recommend they >>>>> "unroll" their repeat group. If you think about copying the questions in >>>>> your repeat group into the main form, giving each copy unique field names, >>>>> then you can easily figure out how to constrain relationship8 so that it >>>>> does not claim any of the restricted relationship categories that >>>>> relationships 1-7 may have already claimed. >>>>> >>>>> Mitch >>>>> >>>>> >>>>> On Mon, Feb 16, 2015 at 5:03 PM, neil jerson wrote: >>>>> >>>>>> Thank you so much.. >>>>>> >>>>>> >>>>>> I more question.. >>>>>> >>>>>> >>>>>> We are collecting basic data of the household members. Wherein we >>>>>> would like to restrict the user to choose one Household Head and Spouse in >>>>>> the "Relationship to the Head" question. >>>>>> >>>>>> >>>>>> Is there any suggestion to address this concern? >>>>>> >>>>>> Thank you very much.. >>>>>> >>>>>> -- >>>>>> -- >>>>>> Post: opend...@googlegroups.com >>>>>> Unsubscribe: opendatakit...@googlegroups.com >>>>>> Options: http://groups.google.com/group/opendatakit?hl=en >>>>>> >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "ODK Community" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to opendatakit...@googlegroups.com. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Mitch Sundt >>>>> Software Engineer >>>>> University of Washington >>>>> mitche...@gmail.com >>>>> >>>> -- >>>> -- >>>> Post: opend...@googlegroups.com >>>> Unsubscribe: opendatakit...@googlegroups.com >>>> Options: http://groups.google.com/group/opendatakit?hl=en >>>> >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "ODK Community" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to opendatakit...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> >>> -- >>> Mitch Sundt >>> Software Engineer >>> University of Washington >>> mitche...@gmail.com >>> >> -- >> -- >> Post: opend...@googlegroups.com >> Unsubscribe: opendatakit...@googlegroups.com >> Options: http://groups.google.com/group/opendatakit?hl=en >> >> --- >> You received this message because you are subscribed to the Google Groups >> "ODK Community" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to opendatakit...@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Mitch Sundt > Software Engineer > University of Washington > mitche...@gmail.com >