> ## Content Index
> Fetch the complete content index at: https://nolongerset.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# How to Use VBA to Set the ControlSource Property of an Access Image Control (and Other Deeply Hidden Object Properties)
- URL: https://nolongerset.com/deep-hidden-access-properties/
- Published: 2023-04-05T21:26:24.000Z
- Updated: 2026-05-08T12:50:41.000Z
- Description: Ever wonder why you can set some values in the form/report designer Property Sheet but not in VBA? You may just need this well-hidden workaround.
- Author: Mike Wolfe
- Tags: Backwards Compatibility, VBA, Advanced, #Import 2026-05-20 02:59

Microsoft adds properties to the Access object model more frequently than they update the object model itself.

I know that's a confusing sentence, so let me clarify it with an example. Back in Access 2007, Access added support for a ControlSource property to the Image control. You can see this new property on the control's Property Sheet in form/report design view:

![](https://storage.ghost.io/c/eb/d7/ebd732c1-5f03-4f07-b386-5d08557e15c9/content/images/2023/04/image-7.png)

If you try to access this property in VBA, though, it does not exist. At least, not as a standalone property of the Image control object:

![](https://storage.ghost.io/c/eb/d7/ebd732c1-5f03-4f07-b386-5d08557e15c9/content/images/2023/04/image-6.png)

You *can* access this property, but only through the Image control object's `.Properties` *collection:*

![](https://storage.ghost.io/c/eb/d7/ebd732c1-5f03-4f07-b386-5d08557e15c9/content/images/2023/04/image-9.png)

Let's revisit my opening sentence now:

> Microsoft adds properties to the Access object model more frequently than they update the object model itself.

In the example I used, Microsoft added a **ControlSource** property to the Image Control object ("*Microsoft adds properties to the Access object model*"). However, they did not directly expose a `.ControlSource` property as a standalone public member of the object (*i.e., they did not* "*update the object model itself*"). Since the `.Properties` collection of the Image Control object already existed, simply adding another item to that collection did not result in updating the object model itself.

While this may seem like a distinction without a difference, there's a very good reason for this approach: **backwards compatibility**.

## Maintaining Backwards Compatibility

Changing the public interface of the Access object model has far-reaching consequences.

If Microsoft were to add a `.ControlSource` public property to the Image Control object, it would result in a breaking change to the object's API (application programming interface). Not only would it break the API for that object, by extension it would break the API for the entire Access object model.

For .accdb's, I don't think this is a huge deal. For .accde's, though, it means that any .accde compiled by a version of Access that has the new `.ControlSource` property, the generated .accde would fail to open in all older versions of Access that do not support the `.ControlSource` property...**even if you never use the `.ControlSource` property in any of your code**.

Microsoft doesn't take such breaking changes lightly, so new properties often wind up only appearing as items in the respective object's Properties collection.

## Stringly-Typed Programming

This approach to adding functionality via literal strings is pejoratively known as "[stringly-typed programming](https://www.hanselman.com/blog/stringly-typed-vs-strongly-typed)."

It's something you should avoid, as it tends to turn [compile errors](https://nolongerset.com/compile-errors/) into [runtime errors](https://nolongerset.com/runtime-errors/), [which is bad](https://nolongerset.com/some-bugs-are-better-than-others/). However, there are justifications for stringly-typed programming and maintaining backwards compatibility seems to be one of the more justifiable.

That said, there have now been at least **five** major releases to Microsoft Access since Access 2007\. You would have thought that *at some point* a few of these items could have been added to the object model.

## Video Demonstration

In his recent Access Europe User Group presentation, Access MVP Karl Donaubauer discussed this issue as one of his "baker's dozen" of Access tips and tricks.

Here's an excerpt from Karl's video:

> **Properties via VBA that do not exist in VBA**   
> Microsoft does not want to change the VBA object model for every new Access property so as not to lose backward compatibility. Therefore, some properties do not exist with .PropertyName in VBA. However, there is a workaround. 3 Examples:  
>  
> 1\. Image Control Source (since Access 2007)  
> Not like this: `Me!Mylmage.ControlSource`  
> Like this: `Me!Mylmage.**Properties("ControlSource")**`  
>  
> 2\. Control Layout (since Access 2007)  
> Not like this: `Me!MyControl.Layout`  
> Like this: `Me!MyControl.Properties("Layout").Value`  
> other properties: LayoutID, RowStart, RowEnd, ColumnStart, ColumnEnd  
>  
> 3\. [Label Name](https://support.microsoft.com/en-us/office/what-s-new-in-access-2019-f52c5317-3494-4105-9c56-5a2abb8e0f87#ID0EDR) (since Access 2019)  
> Not like this: `Me!MyTextbox.LabelName`  
> Like this: `Me!MyTextbox.Properties("LabelName")`

*Cover image created with [Microsoft Designer](https://designer.microsoft.com/)*