johnlute said:
Hi, Dirk! You're the man who never sleeps!
I should be asleep, but since I'm awake ...
Ultimately, I'm making a selection in:
cbTargetFillFacIDs > AfterUpdate to make cbTargetFillLineIDs visible
or invisible > AfterUpdate that populates lstDensity > AfterUpdate
event that makes cbDensity visible or invisible. It's rather busy!
Ooookay.
Here's the control source for lstDensity:
SELECT qryPROTargetFillWeightsCalculated.Density,
qryPROTargetFillWeightsCalculated.FGID,
qryPROTargetFillWeightsCalculated.numLocationAddressID,
qryPROTargetFillWeightsCalculated.LineID FROM
qryPROTargetFillWeightsCalculated GROUP BY
qryPROTargetFillWeightsCalculated.Density,
qryPROTargetFillWeightsCalculated.FGID,
qryPROTargetFillWeightsCalculated.numLocationAddressID,
qryPROTargetFillWeightsCalculated.LineID HAVING
(((qryPROTargetFillWeightsCalculated.Density) Is Not Null) AND
((qryPROTargetFillWeightsCalculated.FGID)=[Forms]!
[frmQueryFGProcessingFacIDsLineIDs]![cbNavigateProfiles]) AND
((qryPROTargetFillWeightsCalculated.numLocationAddressID)=[Forms]!
[frmQueryFGProcessingFacIDsLineIDs]![cbTargetFillFacIDs]) AND
((qryPROTargetFillWeightsCalculated.LineID)=[Forms]!
[frmQueryFGProcessingFacIDsLineIDs]![cbTargetFillLineIDs]));
I'm curious. In the version of your application that I have previously
looked at, cbDensity has the above rowsource. Is that still the case? If
soIf so, why do you have a list box and a combo box with the same rowsource?
In above query, are you using the GROUP BY clause to remove duplicates?
Otherwise, I don't see any point to using GROUP BY. But your query would be
more efficient if you used a WHERE clause instead of HAVING:
SELECT
Density,
FGID,
numLocationAddressID,
LineID
FROM qryPROTargetFillWeightsCalculated
WHERE (Density Is Not Null)
AND
(FGID=[Forms]![frmQueryFGProcessingFacIDsLineIDs]![cbNavigateProfiles])
AND
(numLocationAddressID=[Forms]![frmQueryFGProcessingFacIDsLineIDs]![cbTargetFillFacIDs])
AND
(LineID=[Forms]![frmQueryFGProcessingFacIDsLineIDs]![cbTargetFillLineIDs])
GROUP BY
Density,
FGID,
numLocationAddressID,
LineID;
Private Sub Form_Current()
[cbTargetFillFacIDs].Requery
[cbTargetFillLineIDs].Requery
[cbDensity].Requery
[cbSTDEV].Requery
[cbThermoformFacIDs].Requery
[cbProfilesAssocsFacIDs].Requery
[cbProCodeFacIDs].Requery
[lstProCodeFacID].Requery
[lstTargetFillFacID].Requery
[lstDensity].Requery
[lstSTDEV].Requery
[lstThermPars].Requery
[cbTargetFillFacIDs] = Null
[cbTargetFillLineIDs] = Null
[cbThermoformFacIDs] = Null
[cbProfilesAssocsFacIDs] = Null
[cbProCodeFacIDs] = Null
[cbDensity] = Null
[cbSTDEV] = Null
[cbThermoformFacIDs] = Null
[cbThermoformLineIDs] = Null
[cbProfilesAssocsFacIDs] = Null
[cbProfilesAssocsFacIDsLineIDs] = Null [...]
End Sub
I'm not sure exactly what's going on, but the one thing I notice immediately
is that you are requerying a bunch of combo boxes, then requerying the list
boxes, and then setting those same combo boxes to Null. Among the combo
boxes being processed this way are the combo boxes, cbTargetFillFacIDs and
cbTargetFillLineIDs, that your list box's RowSource is using as criteria.
Therefore, when you requery the list box, those combo boxes will still have
the values they had before you requeried them -- even if those values are
not in their lists any more. They haven't been set to Null yet. Is that
your intention? I would have expected that you would mean those combos to
be Null, and then requery the list box based on that. If that's so, you'd
need to move assignment of Null to each combo box to a point in the code
before you requery anything that is based on that combo box.
I can also imagine that your AfterUpdate code for these combo boxes may need
to cascade down, so that when one control's value is changed, every control
that depends on that combo also gets requeried, and then every control that
depends on *those* controls gets requeried, and so on.
However, I may just be misunderstanding what you're trying to do.
