Why does MS Access GUI ignore some combobox properties being set through VBA?

What version of Access is the newer version?

If you set the color manually in design mode on the form.  Open the form, What does is then show as the color code in the immediate window?

Both versions of MDB files run under the same Access 2003 and are located in the same folder with different file names.

?Syscmd(acSysCmdAccessVer)
11.0

Select allOpen in new window

See also the attached image.
Although I investigated properties in form's design view, I did whatever I could to prevent from any changes anywhere except for VBA code.
env.jpg

Ah ... older versions of the database not older version of Access.

I make sure there is not an issue with the VBA code not getting recomplied properly, I would recommend decompling the VBA code for the database and recompiling.

Is your database split? Do you you compile the database into an mde? Do you have the same issue with the mde?

.

This may help:

Decompile Your Microsoft Access Database to Improve Performance, Fix Corruption, and Avoid Strange VBA Errors

The database has 4 categories of (~250) tables:
1) ~20 local tables;
2) -3) 200+ linked to two SQL Server databases;
4) the rest are linked to an MDB file.

This application does not ever use MDE rendition to work with.
 This
c:\1>"C:\Program Files\Microsoft Office\OFFICE11\msaccess.exe" /decompile "\\fdefs1...
did not help

I like to be sure the VBA has not got corrupted. If this was the issue,  it is very difficult to track it down. Now we know the VBA is OK.

Next we need to see if it may be a corrupted form.  I like to export the form to a text file. delete the form. compact. import the form back into the database.  See: Backing up and Restoring Objects

If that does not fix the issue the next thing I would do it create a blank new database and import in all the objects.

<<This application does not ever use MDE rendition to work with.>>
I deploy front ends as a MDE/ACCDE for many reason. One of the main reasons is that it insures the VBA code stays properly compiled and prevents VBA code corruption.

Thanks, TheHiTechCoach.
I need some time.

>>...and import all objects.
Sounds (fairly) good for the 6 kinds, but what about relationships, I/O specs, anything else that does not come to my mind right away and that is not queries, tables,.., macros.?

I'll conduct additional investigation of other similar forms / controls.

The follwing code does work:

Private Sub setMdtBorderColor()
    Const SUNKEN = 2, FLAT = 0
    Const TRANSPARENT = 0, SOLID = 1
    With frm(SOURCE_DATA_TABLE_NAME)
        If TableExists(.value) Or Trim(Nz(.value)) = vbNullString Then
            .SpecialEffect = SUNKEN
            .BorderStyle = TRANSPARENT
            .BorderColor = vbBlack
            .ControlTipText = "Verified trend data table name"
            
        Else
            .SpecialEffect = FLAT
            .BorderStyle = SOLID
            .BorderColor = vbRed
            .ControlTipText = "Expert has not found this table in the database"
        End If
    End With
End Sub

Select allOpen in new window

<<It happens because sometimes settings for the BorderStyle, BorderColor, and BorderWidth properties are ignored by design.>>
That does not explain why it was once working but now it is not working.

You originally said:
<<... ,It displays it in the older version, but I cannot figure out why it does not in the newer one.  >>
I took that as meaning it once was working but has stopped.

In almost every data entry form I change the  BorderStyle, BorderColor, and BorderWidth properties for controls.    I have never had it ignored are runtime.  

In your case it may be corruption or other VBA code that is blocking it.

>>...It displays it in the older version, but I cannot figure out why...
Meticulous collation of properties was sufficient to find out why. It is verifiable, whilst this
"...corruption or other VBA code that is blocking it"
does not look like it is.
Thanks again.

<<The only my excuse is that I consider a MDB file as “on-demand” instance of the application that by itself resides in Visual Source Safe (VSS) database, whose.”Data and Misc Objects” thing has been doing its job very well for years.>>

I have used VSS for many applications. I still deploy the front end as an MDE without any issues.  It is not different that using VSS with other programming languages. The source code (with Acess it is an .mdb) is tracked with VSS. When ready to deploy you compile the application into an MDE with Access or a .exe with other languages.

Good luck with your project.

Dear TheHiTechCoach,
I thank you for your interest and collateral information. I did not know how easy it was to handle relations and (!) toolbars with “Import Objects” dialog box. The only my excuse is that I consider a MDB file as “on-demand” instance of the application that by itself resides in Visual Source Safe (VSS) database, whose.”Data and Misc Objects” thing has been doing its job very well for years.  However this is definitely a (lyrical) digression.