***Assuming that you are using a single form NOT continuous forms ***
there's two elements
one is how you show or hide certain form (or report) controls
the other is when do you invoke that action.
controls in Access speak are objects which have certain methods, or properties. you can for instance hide a cotnrol (using the .visible property), or locked using the .enabled property
from what you are saying you probably need to use the .visible property and set to true if it shoudl be visible, and false if it shouldn't
So write a function which received a parameter, and based on that parameter take whatever actions you want.. lets say your controls are called mycontrol1..10, mydiabetescontrol1..10 (for your diabetes specific controls), myBPcontrol01..10 for (wait for it Bloood pressure specific controls)
the controls which aren't specifc will not be touched (mycontrol01..mycontrol10)
why use an if / elseif construct?
public sub SetControlVisibilityByHealthType(HealthType as String)
if UCASE(HealthType) = "DIABETES" then
mydiabetescontrol01.visible = true
mydiabetescontrol02.visible = true
mydiabetescontrol10.visible = true
'now for the blood pressure specific controls
mybpcontrol01.visible = false
mybpcontrol02.visible = false
mybpcontrol10.visible = false
elseif UCASE(HealthType) = "BLOOD PRESSURE" then
'then repeat the code block above but reverse the true / false bit
you have 3 states that a row coudl be (iuts a diabetes row, its a blood pressure row or its neither / not determined yet
well you could use a select case (and arguably is better for more than one choice)
as a general rule when coding ANYTHING cover the expected bases. dont' assume exprerssly code for specific states. yes its more work, but I'd argue makes your code more maintainable (and maintainable not just for you. say the comedians, sorry users, decide a third condition should be handled by the same system (say stroke) then becuase you have explciit diabetes cawe, blood pressure case its realtively easy for a new developer to add nbew conditions.
..actually you'd be better off defining an enumeration so instead of passing the parameter as text you'd pass it as an enumeration (think if an enumneration as a limited list of possible values. although its arguable here that an enumeration is required its good practice especailly if you write code which could be used by others. the real advanatage of the enumeration as opposed to passing as a string =value is that you cannot get an invaliud value (say a user passed 'blood press' instead of 'blood pressure'.. it protects you aaginst typos and not in list errors it can also help make code easier to understand
so that sets the visibility based on the the specified parameter. now you need to decide when the controls visibility shoudl be triggered. well that would be when
the value of the control that 'decide' this is a diabetes or blood pressure control changes
when the current displayed row changes
so haviing written your function you need to call that function form various events that fire in background when you use a form.
...when a single from's data row changes the oncurrent event fires. so that woudl be how you'd show or hide historic data by calling the function from there
the thorny question is when the data in the current row changes (that may happen on an edit of an exisiting row or adding a new row.
so set the visibility based on the onchange event or the relevant control.
as to what the relavant control is, who knows, thats down to your design., it could be a combo, a list box, a text box, whatever. (you'd be better off using a combo or list box, and even better off using a combo box that has the values of the enumerated list as hidden columns
but the 'right' way to do this I'd argue is to have two subforms that hang off a single 'visit' form form. the user selects what ype of condition it is, and then dispalys the relavnt subf form
....or used a tabbed dialog to the user can see any diabetes obs, or any bp, or any....
I'd rather be riding on the Tiger 800 or the Norton