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

[vbaInet]

Implemented, other than switching to using vbNullString as that is more typing that two double quotes. Thanks!

Not all short code is optimised. vbNullString is recommended.

See here:

?strptr(vbnullstring)
0

?strptr("")
3943780

Yes they are equivalent but one points to a 0 memory address.

 

[mdlueck]

You certainly know some of the quirks with VBA. I shall "" --> vbNullString.

 

[mdlueck]

My mind has been reeling with how complicated VBA makes NULL handling.

Which I have come full circle I now realize. When I first banged into the sharp edge of dealing with NULL's in unbound TextBox controls, I was poised to develop a bit of shared code. As a solution I was introduces to using Nz() instead which has worked ever since. (Until this week.)

I just cooked up a bit of shared code so that reading TextBox controls will again be a 1 LOC task.

'Generic API to safely read a Form Text Box / field control
Function uiutils_ReadFormTextBox(ByRef CtrlPointer As Object, ByVal varDefaultValue As Variant) As Variant
  On Error GoTo Err_uiutils_ReadFormTextBox

  'First test for an Unbound Control ...
  If (CtrlPointer.ControlSource = vbNullString) Then
    'Test for an Empty control on an unbound Form
    If Len(Nz(CtrlPointer.Value, vbNullString)) = 0 Then
'      Debug.Print CtrlPointer.Name & " Empty Unbound Control"
      'Empty confirmed, return the specified Default Value
      uiutils_ReadFormTextBox = varDefaultValue
    Else
'      Debug.Print CtrlPointer.Name & " Popualated Unbound Control, CtrlPointer.Value=>" & CtrlPointer.Value & "<"
      'Simply return the Value of the control
      uiutils_ReadFormTextBox = CtrlPointer.Value
    End If
  'Bound Control...
  Else
    'Test for the Form having an Empty Recordset
    If (CtrlPointer.Parent.Recordset.RecordCount = 0) Then
'      Debug.Print CtrlPointer.Name & " Empty Bound Control"
      'Form appears to be empty, so return the DefaultValue rather risk
      'a VBA crash reading a bound control
      uiutils_ReadFormTextBox = varDefaultValue
    Else
'      Debug.Print CtrlPointer.Name & " Popualated Bound Control, CtrlPointer.Value=>" & CtrlPointer.Value & "<"
      'Form appears to have data, so go ahead and attempt to read the control
      uiutils_ReadFormTextBox = CtrlPointer.Value
    End If
  End If

Exit_uiutils_ReadFormTextBox:
  Exit Function

Err_uiutils_ReadFormTextBox:
  Call errorhandler_MsgBox("Module: modshared_uiutils, Function: uiutils_ReadFormTextBox()")
  uiutils_ReadFormTextBox = varDefaultValue
  Resume Exit_uiutils_ReadFormTextBox

End Function

Sample usage:

  Me.rev = uiutils_ReadFormTextBox(MePointer.fldrev, vbNullString)
  Me.ver = uiutils_ReadFormTextBox(MePointer.fldver, -1)

 

[vbaInet]

You are really over complicating matters. I told you about the Allow Zero Length String property, if you set that to No you won't be needing to do all this unecessary checks.

 

[mdlueck]

You are really over complicating matters.

And I say VBA is the one over complicating...

even this still has "Type Mismatch" as the IsNull sometimes is not found true, such as when the control started as empty, I type a character in the field and then backspace it out. Going from empty to value or value to empty works, just not from empty to having a value and right away removing that value. Very frustrating business.

I say VBA has too may NULL options.

So it would appear that the control would have two different NULL / Blank states. Either way it is result of backspacing all of the characters from the control. The difference being did the control start out empty or not.

I told you about the Allow Zero Length String property, if you set that to No you won't be needing to do all this unnecessary checks.

Since VBA and controls have such variety of ways of behavior WITHOUT adding adjusting properties from their default state, I would rather develop code which is safe for the default property values than rely on having properties adjusted to a certain custom state.

Yes I know, I could develop a bit of code to whip through all of the forms \ controls and make sure the property is set to the needed state easy enough... I am just plain sick of tinkering at this point.

 

[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?

Adjusting the:

Private Sub fldcomplbyid_LostFocus()

  Me.fldcomplbyid.BackStyle = 1

End Sub

Did not work 100% of the time. One control still 50% or more of the time would flip back to grey. I tried forcing that one control back to white in other control's GotFocus event. Perhaps that got the control to say white 75% of the time, but that is having to put code on WAY TOO MANY events. aaakkk!!!

Searching for other suggestions I came across, in a thread I had seen while researching this issue:

"Combo Boxes go transparent when they loose focus"
http://www.pcreview.co.uk/forums/co...ey-loose-focus-t3910161.html#td_post_13617728

Indeed, going to the Form's Detail Section \ Alternate Back Color property and changing its value from the default "System Button Face" to "Background Form" seems to have prevented the Combo Box backgrounds from changing.

Note: I am customizing the theme off of the Access 2003 theme colors... the form background color IS grey. Yet doing that adjustment PREVENTS the Combo Box control's background from going grey when the control looses focus. And why only on this form are some Combo Boxes doing this nonsense!? Ma ei tea... (shrug) WFM. YMMV.

 

[vbaInet]

So it would appear that the control would have two different NULL / Blank states. Either way it is result of backspacing all of the characters from the control.

No and No. You're a developer and I would have expected this to be a very simple concept for you to understand. We've gone through tonnes of posts and I find myself repeating this basic concept over and over again. Even pbaldy explains it in the link I provided many posts away.

A bound control is Null (i.e. not two states, but one) when you create a new record. It starts out as Null, nothing else unless you defined a default value in the control or in the table. An unbound control starts out as Null when you open the form, and I don't mean when you open the form from Design View.

The difference being did the control start out empty or not.

Explained above but it's also based on what you've done in code and whether you open the form from design view or not. Look at your code.

Since VBA and controls have such variety of ways of behavior WITHOUT adding adjusting properties from their default state, I would rather develop code which is safe for the default property values than rely on having properties adjusted to a certain custom state.

Yes I know, I could develop a bit of code to whip through all of the forms \ controls and make sure the property is set to the needed state easy enough... I am just plain sick of tinkering at this point.

Here we go again, another complicated idea to solve the most simplest of tasks. Turn off the property and you will be assured that you will only EVER have Null as "default value" in the field. Like I mentioned before, Null is not a value it's an undefined value. The zero-length string is a value.

I know you like to code but in Access/VBA there are many tried and tested properties that you just need to set to enforce some sort of validation or verification. But you choose to write code that ends up being untraceable. The Allow Zero-Length String property is a perfect example of avoiding zero-length string in your field. It's that simple really.

 

[vbaInet]

Adjusting the:

Private Sub fldcomplbyid_LostFocus()

  Me.fldcomplbyid.BackStyle = 1

End Sub

Did not work 100% of the time. One control still 50% or more of the time would flip back to grey. I tried forcing that one control back to white in other control's GotFocus event. Perhaps that got the control to say white 75% of the time, but that is having to put code on WAY TOO MANY events. aaakkk!!!

Upload a quick sample db if you can so I can see what you're seeing.

 

[mdlueck]

A bound control is Null ...

This is an Edit Record dialog, so is NOT BOUND to a table. The Validation class loads the values in programatically from the DB class object which contains the record to be edited.

Upon the Commit button being pressed, the Validation class reads the form controls (which was sometimes blowing up) and the validation class sends the fields back to the DB class for it to issue a SQL UPDATE.

What I fail to understand is why a field control could start out with a string value, have that value backspaced to become empty... (this is case 1) and why starting out blank, typing some characters, then backspace to become empty (this is case 2) results in the field control somehow being in a "different state of empty / null".

<><><><>

About the original purpose for this thread...

Upload a quick sample db if you can so I can see what you're seeing.

This form is already enough over budget time-wise. Since I found a workaround to change the section alt color, and not require any event programming, I think I will end research on this bug. Clearly I am not the only person to see it. Very odd that this is the only form which Combo Boxes are doing such nonsense on.

 

[Frank Marckus]

Hi everyone. I think the problem here is the Z-order. Try bringing the troublesome combo boxes to the front using the Format / Bring to Front option...

 

[mdlueck]

Thank you, Frank.

Per my header comments...

Rem /* 02/06/2012 MDL        Adjust Form Detail Section \ Alternate Back Color and was  */
Rem /*                       finally able to remove code attempting to prevent Combo Box*/
Rem /*                       controls from going to grey background when loosing focus  */

So, all code on depart methods has been dropped, and I will leave well enough along.

Just to be sure, I "brought to front" all Combo Box controls on this beastly form.

Note: Specifically in my case, using the Access 2003 "grey" AutoFormat theme, adjusting the section's Alternate Background Color to "Background Form" WFM.

 

[mdlueck]

Hi everyone. I think the problem here is the Z-order. Try bringing the troublesome combo boxes to the front using the Format / Bring to Front option...

Interesting... I had a combo box on a new form suddenly develop "random grey'itus".

I brought the form into Design View, Arrange \ Bring to Front on the two Combo Box controls, and "random grey'itus" appears to have stopped. Interesting...

Nope... just went grey again upon yet further testing. Not the correct answer.

 

[Maa421s]

I was also able to correct this behavior by setting the Detail Alternate Back Color to something. Seems like a bug to me... Thank you for this post - it saved me a lot of time.

 

[gemma-the-husky]

michael

i haven't read the whole thread, and this may have been mentioned - but I suspect you have windows themed controls

(and I have just realised this is an old thread that has woken up!)


instead of using particular colours and styles, controls comply with the active windows theme. there are only a limited number of settings that do this though (eg flat ). once you go to a non-themed setting, you lose the theme effect.

try options, and switch between themed and non themed controls. it might make more sense.

see if this makes sense

http://office.microsoft.com/en-gb/a...-themes-in-controls-on-forms-HA010174334.aspx

 

[Rodgman]

To keep colors in combo boxes from intermittently changing, set the form section alternate background color to "system scrollbar"

 

[Fowz]

To keep colors in combo boxes from intermittently changing, set the form section alternate background color to "system scrollbar"

I was driven near demented trying to fix this problem. I tried every solution suggested in this thread (after struggling greatly to follow the first 3 pages...), and this was the one that finally worked.

Thank you!