Force Access to Reapply Format Conditions

[dch3]

Is there a wait to force Access to reapply/repaint (whatever the term is)
Format Conditions? I've got a detail subform where the Format Conditions do
not immediately apply when the conditions change.

 

[Dirk Goldgar]

Is there a wait to force Access to reapply/repaint (whatever the term is)
Format Conditions? I've got a detail subform where the Format Conditions
do
not immediately apply when the conditions change.

Does Me.Repaint help?

 

[dch3]

1) I'll try Me.Repaint but I think it didn't work when I ran into this way
back when

2) The controls are on a subform

3) One of the (3) conditions looks at the value in a field and applies the
formating based on that value - specifically if a value is present. Let say
for example that you're fulfilling an order - once the order is fulfulled and
packed, you shouldn't be able to change the order. So if the status is
'Filled' and I change it back to 'Pending', the conditional formating which
enables the fields should enable them. It doesn't. I've got an unbound combo
box in the subform's header which if I change the value, then the conditional
formating kicks in and the fields are enabled. That's the easiest way to
describe the scenario.

 

[dch3]

I endedup using Me.Refresh. I suspect that code that handles the format
conditions fires when the data is manipulated. I end up with a flicker that
I'm not happy with, but at least I've stopped pulling out my hair. DoCmd.Echo
False/True didn't remove the flicker btw.

 

[Dirk Goldgar]

I endedup using Me.Refresh. I suspect that code that handles the format
conditions fires when the data is manipulated. I end up with a flicker
that
I'm not happy with, but at least I've stopped pulling out my hair.
DoCmd.Echo
False/True didn't remove the flicker btw.

I've been thinking about this, but haven't had time to try to reproduce it.
Conditional formatting is handled by an internal timing loop that
continually checks to see if the format conditions are true, and applies the
formatting accordingly. Are you sure that the problem wasn't one of having
an uncommitted value in the control? For example, having changed the value
in a combo box but not yet having moved to another control on the subform?

 

[dch3]

Nope. Been updating the comboBox invovled and moving to a new record. I'm
wondering if its the complexity of the FC's or the complexity tied with the
number (3). Part of the situation is that *ALL* of the fields may be
disabled, if they aren't disabled, there are two specific fields that may or
may not be disabled. By disabled - I'm referring to the color scheme of the
field.

I might try doing a calcualted field (yeah I know their bad) that results in
wether or the record should be 'LOCKED' or 'UNLOCKED' to see how that effects
it which would deal with the *ALL* part of it.

The other two fields, are conditionally enabled/disabled by using the
..Column(x) property of the comboBox. (Which might just be part of the problem)

 

[Dirk Goldgar]

Nope. Been updating the comboBox invovled and moving to a new record. I'm
wondering if its the complexity of the FC's or the complexity tied with
the
number (3). Part of the situation is that *ALL* of the fields may be
disabled, if they aren't disabled, there are two specific fields that may
or
may not be disabled. By disabled - I'm referring to the color scheme of
the
field.

I might try doing a calcualted field (yeah I know their bad) that results
in
wether or the record should be 'LOCKED' or 'UNLOCKED' to see how that
effects
it which would deal with the *ALL* part of it.

The other two fields, are conditionally enabled/disabled by using the
.Column(x) property of the comboBox. (Which might just be part of the
problem)

Without looking at it directly, I can't think of anything else to suggest.
If you can pare it down to a simple, reproducible scenario, you can either
identify and report it as a bug or at least determine what specific factors
cause the problem. Do you want me to look at it? I don't think I'm likely
to see anything you haven't.

 

[dch3]

I'll see if I can put together a .mdb that I can email over the weekend.
Can't send you all of my tips and tricks.

 

[dch3]

Two of the format conditions referenced columns in a combo box in the detail
as in
[Forms]![frmManifest]![subfrmManifestDetail].form!cboPartDescription.Column(4) = True.

I ended up adding the fields to the underlying recordsource and then
pointing the conditions to the new fields as in
[Forms]![frmManifest]![subfrmManifestDetail].form!ynCaptureDimensions = true.

This seems to have fixed the problem.

I'm assuming that although the column information is available, that its
stored in such a way (and that the Format Conditions code operates) in such a
way that the Format Condition does not immediately have access to the values.

Lesson - Don't reference a listbox or comboBox .Column in a format
condition's expression.

My experience with Access is such that I can't eloquently explain they why
behind it, but I understand it.

 

[Dirk Goldgar]

Two of the format conditions referenced columns in a combo box in the
detail
as in
[Forms]![frmManifest]![subfrmManifestDetail].form!cboPartDescription.Column(4)
= True.

I ended up adding the fields to the underlying recordsource and then
pointing the conditions to the new fields as in
[Forms]![frmManifest]![subfrmManifestDetail].form!ynCaptureDimensions =
true.

This seems to have fixed the problem.

I'm assuming that although the column information is available, that its
stored in such a way (and that the Format Conditions code operates) in
such a
way that the Format Condition does not immediately have access to the
values.

Lesson - Don't reference a listbox or comboBox .Column in a format
condition's expression.

Interesting, and a useful warning. I can think of one possible explanation,
which may or may not be the key. The Column property of a combo or list box
is a text property, so its value is always either Null or a string. I
notice that your original expression (if you posted it accurately) doesn't
have quotes around "True", and I'm not sure whether that literal would be
correctly compared to the text value in the combo column, which may be "Yes"
or "-1", rather than "True". If these expressions were working, but only
after refresh, then I'd have to conclude that the expression is being
evaluated successfully, but maybe there's some sort of delay caused by type
difference.

If you check the actual values in the combo's Column property, and form your
condition expression to use those string values, does the problem go away?

 

[dch3]

Now that you mention that seem to recall that I ran across the
type-conversion problem elsewhere with a comboBox which didn't involve FC's.
I'm willing to bet that that's the root cause, but I'm not in a position to
test it at the moment. When the form was initially displayed, things seemed
to work fine leading me to believe that the conversion was happening when the
records were initially displayed but not happening when the value in the box
was changing.

Two of the format conditions referenced columns in a combo box in the
detail
as in
[Forms]![frmManifest]![subfrmManifestDetail].form!cboPartDescription.Column(4)
= True.

I ended up adding the fields to the underlying recordsource and then
pointing the conditions to the new fields as in
[Forms]![frmManifest]![subfrmManifestDetail].form!ynCaptureDimensions =
true.

This seems to have fixed the problem.

I'm assuming that although the column information is available, that its
stored in such a way (and that the Format Conditions code operates) in
such a
way that the Format Condition does not immediately have access to the
values.

Lesson - Don't reference a listbox or comboBox .Column in a format
condition's expression.

Interesting, and a useful warning. I can think of one possible explanation,
which may or may not be the key. The Column property of a combo or list box
is a text property, so its value is always either Null or a string. I
notice that your original expression (if you posted it accurately) doesn't
have quotes around "True", and I'm not sure whether that literal would be
correctly compared to the text value in the combo column, which may be "Yes"
or "-1", rather than "True". If these expressions were working, but only
after refresh, then I'd have to conclude that the expression is being
evaluated successfully, but maybe there's some sort of delay caused by type
difference.

If you check the actual values in the combo's Column property, and form your
condition expression to use those string values, does the problem go away?

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)

 

[dch3]

Turns out I also had a calculated field in the record set which I had
forgoten about. Now that I've taken that out, the overall look and feel is
what it should be. I don't think that it was a mitigating factor though.
(...and I just remember I was going to email you a sample, its on the way
back burner.)

 

[Dirk Goldgar]

Turns out I also had a calculated field in the record set which I had
forgoten about. Now that I've taken that out, the overall look and feel is
what it should be. I don't think that it was a mitigating factor though.
(...and I just remember I was going to email you a sample, its on the way
back burner.)

That's okay, I have back burners of my own.