A2007 Some Combo Boxes changing back color on their own as they loose focus, WHY? (1 Viewer)

[mdlueck]

Access 2007 as really done it this time...

On one form I have five Combo Box controls. I have been working most of the afternoon on UI formatting. Now 2 to 3 of the 5 controls SOMETIMES change their background color from white (as it should be) to the grey that is the form's background color.

Of the controls that do this, at least one SOMETIMES decides to stay white for some list values and only do the grey change color for some values.

Other controls consistently shift to grey when they loose focus.

Thus far, I was only able to find one page mentioning this on the Internet:
"2007 Access Combo Box changes Background color after tab through f"
http://www.pcreview.co.uk/forums/20...round-color-after-tab-through-f-t3830649.html

I do not see the Alternate Color property on my A2007 Combo Box controls. I do see the property for the "Detail" portion of the Form the Control is placed on.

I have already tried my Decompile / Compact / Compile process, and that did not correct the misbehavior.

Suggestions as to what else could be triggering this Combo Box background color nonsense?

 

[mdlueck]

When this form first opens, all 5 Combo Box's have white background.

Tabbing through the controls, arriving on each control it stays white - always.

If I do not change values - merely tab through, then the first three Combo Boxes I tab through go grey when I tab off of them. The other two remain white as they are suppose to.

If I change values, then SOMETIMES I can get the second Combo Box to sometimes remain white. The other two never stick white once they have gone grey. That usually is triggered by me backspacing the current value and re-entering the character back to the way it was. (Yes yes, I have not locked down the Combo Boxes yet to enforce selection from the list.)

Oh oh!!! I just shifted back to Access from Firefox and all three troublesome fields were white background!! I tabbed off of one of them, and it once again changed to grey. ggggrrrr.....

Yup, confirmed, if I switch focus to Firefox, coming back all of the Combo Boxes have white background as they should.

Any suggestions based on these addl details?

 

[mdlueck]

With no suggestions appearing, I decided to recreate the three misbehaving Combo Box controls. (Yes yes, I remember the static cap on the number of controls able to be created on a form. I just chewed up three control slots... gggrrrr....)

Of the three I replaced, the second one of the three persists with the shaded background problem. The first and third are working as expected for the moment.

Also, now the fourth Combo Box control is doing the "loose focus / grey background" nonsense.

Where could the behavior be coming from, only on this one form?

And thinking about that last line... This thread probably belongs in the Forms group rather than the VBA group. Moderator, please consider moving this thread.

 

[mdlueck]

Interesting finding just now.

I rolled back to the last backup just before I tried rebuilding the misbehaving Combo Box controls.

Since various fields are required, I have validation code to turn the required field's background red if an inappropriate value is found.

So I blanked out required fields, attempted to commit, validation code turned the required fields red. Then I selected a value from the picklist on one control and moved off of the control to see what would happen.

The grey color showed up, with red visible around the border. Please see the attached screenshot.

So, with Combo Box controls, is there a second background color perhaps for the value in the pick list and not the control itself, and that is what is going grey for unknown reason?

Also I have tried checking the value of the BackColor property in the Immediate window. I never see it change no matter is it white / grey, and a correct control that never goes grey has always the same value.

Debug.Print Forms("qualityedit").fldpqptypeid.BackColor
 16777215 

Debug.Print Forms("qualityedit").fldfatypeid.BackColor
 16777215 

Debug.Print Forms("qualityedit").fldcomplbyid.BackColor
 16777215 

Debug.Print Forms("qualityedit").fldgpid.BackColor
 16777215

Thus further suggesting that a second background is coming into play.

Is there a second BackGround within a Combo Box control?

 

[vbaInet]

Do you ever "fiddle" with the BackStyle properyty of the combo boxes in code or otherwise?

Is this combo box in a tab control?

 

[mdlueck]

Do you ever "fiddle" with the BackStyle property of the combo boxes in code or otherwise?

Ei. Just BackColor. (Inquisitive look on my face... check out "BackStyle" in the morning...)

Is this combo box in a tab control?

Ei, just single a single / simple form allowing to Edit a selected record. Prior form is a multiple records list, and this is the Edit form to edit the selected record.

 

[vbaInet]

So try it out without changing any Appearance properties to see if it makes a difference.

 

[mdlueck]

Do you ever "fiddle" with the BackStyle properyty of the combo boxes in code or otherwise?

All Combo Boxes have that BackStyle set to Normal. I have never adjusted that property. Those do not change either when the "greys" happen. (The last/fourth control is a control which does not have the "greys" problem.)

Debug.Print Forms("qualityedit").fldpqptypeid.BackStyle
 1 
Debug.Print Forms("qualityedit").fldfatypeid.BackStyle
 1 
Debug.Print Forms("qualityedit").fldcomplbyid.BackStyle
 1 
Debug.Print Forms("qualityedit").fldgpid.BackStyle
 1

So try it out without changing any Appearance properties to see if it makes a difference.

I can bring this form up, tab through the fields, and three of them turn grey as I tab off the control. The validation rules do not run until the Commit button is pushed. That is what adjusts the BackColor property, selecting between White and Red.

 

[vbaInet]

Can you throw up a quick sample db and upload it?

 

[mdlueck]

Aaaahhh, I figured out how I could programtically cause the "greys" to happen!

Forms("qualityedit").fldcomplbyid.BackStyle = 0

causes the "greys", and

Forms("qualityedit").fldcomplbyid.BackStyle = 1

clears it again.

This successfully completely masks the "greys" problem.

Private Sub fldpqptypeid_LostFocus()

  Me.fldpqptypeid.BackStyle = 1

End Sub

Private Sub fldfatypeid_LostFocus()

  Me.fldfatypeid.BackStyle = 1

End Sub

Private Sub fldcomplbyid_LostFocus()

  Me.fldcomplbyid.BackStyle = 1

End Sub

Shrug...

 

[vbaInet]

Well, there you go. Let the BackStyle be

 

[mdlueck]

Let the BackStyle be

Very strange still... And querying the property gave the "desired" result. Forcing it again to the desired state fixes the condition.

And yes, I build forms with the Access 2003 theme, so the form color is grey. According to the references, a value of 0 would be Transparent, aka form color bleeding through, which accurately describes the situation.

Very strange what got into Access... Duct tape to the rescue!!

 

[vbaInet]

Yep! That's what it's doing. Your problem didn't highlight a bug in Access afterall.

 

[mdlueck]

Yep! That's what it's doing.

Come again? What is the pointer "That's" pointing at?

Your problem didn't highlight a bug in Access afterall.

An inconsistency at the very least. This one form have five combo box controls. Only three of them do this nonsense.

When I tried rebuilding the controls, the first and third were fixed after recreation. The second still did the nonsense, and the fourth also started the nonsense. Thus I rolled back to the backup taken just before trying to rebuild the three combo box controls.

I am using Combo Boxes on other forms in this application and none of those are doing this kind of nonsense.

I suspect some sort of "Form corruption" which I am not able to do anything about is what is causing it.

 

[mdlueck]

What means:

http://msdn.microsoft.com/en-us/library/bb239920(v=office.12).aspx

Transparent 0 (Default for option group)

Perhaps "option group" somehow got (is getting) set.

 

[mdlueck]

Oh, never mind... "Option Group" is another control type. I do not have one of those on this form either.

 

[mdlueck]

This is not funny... today I am back working on this area of the application and I see that my duct tape fix of:

Private Sub fldpqptypeid_LostFocus()

  Me.fldpqptypeid.BackStyle = 1
Debug.Print "Me.fldpqptypeid.BackStyle = 1"

End Sub

fails to flip the control back to the correct color.

Worse, an additional control is now involved in the nonsense. I did rearrange that control which has suddenly developed the wrong behavior... moving it below a simple text field control.

Aaahhhh... turning off the Layout Group just fixed three of the four controls. One yet insists on going grey, I see the LostFocus event being fired yet the fix does not fix this one final control. Further suggestions anyone?

 

[mdlueck]

I think something must be wrong with this form. Upon lite stress testing, Nz() is unable to successfully realize that one of the fields on the form is blank / NULL. My validation code blows up trying to read the value (lack there of) from the one control.

  Me.rev = Nz(MePointer.fldrev.Value, "")
Debug.Print "MePointer.fldver.Value: >" & MePointer.fldver.Value & "<"
[B][COLOR=Blue]Debug.Print "Nz(MePointer.fldver.Value, 0): >" & Nz(MePointer.fldver.Value, 0) & "<"[/COLOR][/B]
Debug.Print "Len(MePointer.fldver.Value): >" & Len(MePointer.fldver.Value) & "<"
  [B][COLOR=Red]Me.ver = Nz(MePointer.fldver.Value, 0)[/COLOR][/B]

Immediate window output as follows:

MePointer.fldver.Value: ><
[B][COLOR=RoyalBlue]Nz(MePointer.fldver.Value, 0): ><[/COLOR][/B]
Len(MePointer.fldver.Value): >0<

Red LOC raises the following error:

Date: 20120201 Time: 16:43:33 UserID: c_mlueck
AppErrorMsg: Class: clsObjUIValidationQualityTbl, Function: Validate()
Error Source: Fandango_FE
Error Number: 13
Error Description: Type mismatch
MessageText: The data is invalid.

The blue LOC with the Nz certainly does not appear to be working properly. Works "everywhere else" in this app.

I think I am looking at needing to rebuild this form from scratch tomorrow. Any last advice before I begin rebuilding?

 

[vbaInet]

But how does a Type Mismatch error have anything to do with the Nz() function not catching Nulls? Check the type of value returned and check the data type of the field bound to the ver control.

 

[mdlueck]

But how does a Type Mismatch error have anything to do with the Nz() function not catching Nulls?

I would think that this Debug.Print output smacks at corruption, no?

[B][COLOR=RoyalBlue]Nz(MePointer.fldver.Value, 0): ><[/COLOR][/B]

In my mind I should have received >0< , no?

data type of the field bound to the ver control.

This "should" be an unbound form. I will make sure that one Ver field control is not yet bound to the table. Excellent thought. No... the control's value was Varient/String I remember, so must not be bound. The actual table column is numeric. So I believe that control is correctly unbound.