Do as I say, not do as I do comes to mind :p

I used to always use Standard Colors until Microsoft got rid of the full palette. Really wish they would bring it back.

Alex LOL! Hi Alex, that made me laugh out loud.

Kevin Really? I have Access 365, I'm watching these and typing on my Mac so I'll have to turn on the PC and check that, appreciate the heads up.

I was waiting for someone to point that out. I didn't want to be the one....LOL

LOL. Alex pretty much nailed it: "Do as I say, not as I do." :)

There actually is a reason for it, though. When I'm developing something for myself or building something for production, I generally prefer to use specific colors, and when I'm coding them I almost always use hex colors converted to RGB. The same goes for fonts, sizes, and other formatting. If I designed it to look a certain way, I want it to stay that way. HexToRGB

That's always been my biggest issue with theme colors and fonts. Themes can change, and Microsoft has certainly changed defaults over the years. We've gone through things like Tahoma, Calibri, Aptos, etc. I don't want something I built years ago suddenly looking different because Microsoft decided the new default should be something else.

But Microsoft also changed the color palette, and getting to the exact colors I want now takes more clicking than it used to. When I'm recording a training video, I'm usually trying to keep things moving. I'm not going to stop the lesson and click three levels deep just to select an exact color when the particular shade isn't important to what I'm teaching. So I'll grab a convenient theme color and move on.

So yes, you caught me. :) For training videos, it's mostly for brevity. For my own production databases, I'm much more particular about specifying the actual colors and formatting I want.

And I'm glad to hear you're going through the courses a second time, Paul. It's amazing how much more you pick up on another pass once you've already got the foundation. Thanks for the kind words!

I know when it comes to themes, I tend to fall in as the black sheep of the ALZ student body. I have gotten comfortable working with them. For example, the specific situation of Microsoft changing the color or fonts of the default theme is easily mitigated by following a best practice Richard discusses in most of his videos: Back up your d---, err, theme, color set, or font.

For example, if you like the current default theme, just go into the theme section, go to the color set and edit and then save a copy of the default theme colors as whatever (i.e. ALZ Colors), do the same for fonts (ALZ fonts) and then save as a new theme. If Microsoft modifies the default, it won't effect your database at all because you're using your own custom theme. And that way, you get a full expanded palette to work with.

And you can set up to 3 default themes per Access application: 1 Overall, 1 for Forms, and 1 for Reports. On top of that, you can set a separate custom theme for each individual form or report.

Anyway, I'm not trying to beat a dead horse, just saying that as with anything in developing, proper planning and backups can reduce or even eliminate many of the issues.

Kevin You're right! I just checked, there's a ton of Theme colors but a very limited amount of Standard colors. But a couple more clicks will bring up a different palette, however, I did like the old interface better.

You are kind of expected to write code to set your own colors for your UI, since Access is a developer's tool.  Themes are a better fit for Word and Excel because they are mostly end-users' tools.  But in Access, "end-users" are actually the developers, whose creations are for the real end-users, who won't actually get to use the themes (because they use the developer's creation, not Access per se).  So Access themes are kind of pointless to me, and I always use VBA code to set colors for all my forms, which gives me much better control.  

For instance, the procedure below cycles through all the controls on a form and set their colors accordingly.  When a control is a subform, the procedure runs again, but recursively, to set the colors inside the subform.  Nested subforms that are multiple levels deep should also work because the sub is recursive.  This code may not work for all circumstances, as run-time errors may occur when certain color properties aren't available (such as when a subform is a datasheet, which doesn't have certain properties that a form has):

Sub SetFormColors(MyForm As Form)
     ' 10/1/26 Created for 599cd.com

     Dim c As Control

     ' Cycle through all controls on form and set their colors
     For Each c In MyForm.Controls

          ' Check control type and set colors accordingly
          Select Case c.ControlType

               Case acLabel:
                    c.ForeColor = RGB( ... )
                    c.BackColor = RGB( ... )

               Case acTextBox, acComboBox, acListBox, acImage:
                    c.ForeColor = RGB( ... )
                    c.BackColor = RGB( ... )
                    c.BorderStyle = 1

               Case acCommandButton:
                    c.ForeColor = RGB( ... )
                    c.BackColor = RGB( ... )
                    c.HoverColor = RGB( ... )
                    c.HoverForeColor = RGB( ... )
                    c.BorderStyle = 1

               Case acSubform:
                    SetFormColors c.Form  ' Procedure runs again recursively to set subform's colors
                
          End Select
    Next
End Sub

Kevin I don't disagree that there are times when everything gets hard coded, especially, for instance if you sub-class forms. However, it's important also to remember, while there are many highly skilled and experienced developers who use Access and do like having complete explicit control as in your example, one of Access's greatest assets is that it is a Rapid Application Development Environment for desktop even for novice users who aren't always going to want to script every single setting.

That's where the UI interfaces, whether Standard Colors or the Theme Palette shine. And even some experienced developers like having the point-and-click option to select the colors they want. Sure, after that, they may well transfer those over to hard coding. But the visual interface is, in my opinion, an invaluable asset. Otherwise, we might as well all be developing everything in Command Prompt, j/k.

To that end, Richard has a great Developer lesson that shows how to open the Windows Color Picker for use from VBA. And, lol - as luck would have it, I just had someone ask me to build a floating color selector that they can use that has a full palette, regardless of whether or not they choose to use Standard Colors, Theme Colors, or a mixture. So that will be a new fun little project I'll be working on, after I review Access Developer 40, lol.

Donald   Access themes have several shortcomings: always global, have limited colors, require a reboot for changes to take effect, can't be form-specific or control-specific, and tough to work with in VBA.  Those are all big deal-breakers, so it is a no-brainer for me to set up my own custom color themes.  I only use the color picker when I need to look up a color code (e.g. #787878), then I save it in my VBA code for a custom theme.  One shortcoming of the color picker is that it can't save your selected colors for future use.  In some applications, the color picker can do that (see picture below).

Kevin Actually, the Windows Color Picker Richard shows how to use in Developer 40 does has the ability to store custom colors.

Also, as I stated above, you can set a separate theme as follows:
Global Application Theme
Semi-Global Form Theme (i.e. a default theme all forms will use unless you override it)
Semi-Global Report Them (i.e. a default theme all reports will use unless you override it)
Custom Theme for each individual report
Custom Theme for each individual form

And you can change application themes without reloading a database; your thinking of the Office theme (such as dark mode, colorful, etc.) that may require a reload/reboot.

And, with the use of api calls, you can change color and font sets (the components that actually make up a theme), though I've never had the need to do that.

While application themes are limited to 12 specific colors, those colors are easily modified both in the property dialog (if you know the lingo) of forms and reports as well as with vba that is not too far off from using HSL.

But again, I wasn't trying to say that themes are better or worse, merely that having a visual color picker for many developers is often better than having to hard code everything.

Donald   Also, I prefer something that can be ported to platforms outside of Access when I need to.  My VBA procedure above can be simply copied and pasted to, say, a Visual Studio form app in VB, with minimal changes needed.  Also, my VBA procedure isn't very complicated.  I've been dealing with this since way before Access got themes, so I'm used to using code to solve this problem.  Another big issue of mine is that I prefer all the info in my themes be stored in my own database, rather than in Access theme settings hidden somewhere.

Actually, let me correct myself. It doesn't allow separate default themes for forms and reports, however, it does allow you to have a different theme (or color or font set) for each form or report and you can also change the working theme color set in use for forms or reports that don't have a specific setting.

When working with themes, and/or color sets, and/or font sets, I typically will lock the theme for each object to be safe. The only time a curve ball is introduced is when using subforms. For example, if two forms can both be used independently and you set each to a different color set and then later embed the 2nd form as a subform in the 1st, it will inherit the theme from the parent form.

But again, sorry to get off on a tangent. I don't mean everyone should switch to using themes. And there's no doubt there are many developers who have set up their own hard coded color schemes. I'm merely saying that using themes enables the color picker to have a wider selection than just the 10 standard colors.

And when using theme colors, you do get an "HSL"-esque ability to brighten or darken each of the assigned theme colors which expands the colors available visually.