In the video contained here (https://isladogs.co.uk/aeu-11/index.html), Karl Donaubauer addresses the topic of 'New Properties of Objects'.
It deals with properties of various objects that cannot be addressed using "." syntax, but only using the "Properties" collection of the respective object.
He lists the following properties as examples:
Code:
Me.MyTextBox.Properties("LabelName").Value
Me.MyImage.Properties("ControlSource").Value
Me.MyControl.Properties("Layout").Value
(and also "LayoutID", "RowStart", "RowEnd", "ColumnStart" and "ColumnEnd")
My question:
Is there a complete list of these properties that are only accessible via the "Properties" collection?
Perhaps we can leverage collective intelligence here.
Edit (for clarification):
Perhaps I should have phrased that differently at the beginning.
It's not specifically about compiling a complete list for the sake of it, but rather about gathering knowledge about such useful properties in one central location.
I would have thought that uncovering the possibilities this opens up would be of interest to many programmers.
So if anyone knows of any others of such properties, it would be great to mention them here.
First, "Properties" is a collection. You should be able to write a loop using the property's numeric index to find this as a list of names that you could then look up. If you want to be really a bit anal-retentive about it, include in the loop the ability that if the property doesn't exist, you trap the error and use Resume Next to continue the loop. BUT there is also the ability if you can catch a breakpoint that you could open the "local object" window and explore the list of properties in that object's properties collection.
Second, for some objects, the collection allows you to add a new entry that wouldn't be in the list you are describing until after you have added it, in which case... why did you ask in the first place?.
Third, it is my understanding that some of those properties are either "system" or dynamic properties that are hidden for reasons of stability, i.e. MSFT doesn't want you dorking around with them.
Fourth, ask Google Gemini to get you started on the list.
First, "Properties" is a collection. You should be able to write a loop using the property's numeric index to find this as a list of names that you could then look up. If you want to be really a bit anal-retentive about it, include in the loop the ability that if the property doesn't exist, you trap the error and use Resume Next to continue the loop. BUT there is also the ability if you can catch a breakpoint that you could open the "local object" window and explore the list of properties in that object's properties collection.
Second, for some objects, the collection allows you to add a new entry that wouldn't be in the list you are describing until after you have added it, in which case... why did you ask in the first place?.
Third, it is my understanding that some of those properties are either "system" or dynamic properties that are hidden for reasons of stability, i.e. MSFT doesn't want you dorking around with them.
Fourth, ask Google Gemini to get you started on the list.
@ First: Sure, I could loop the collection, but how to check programatically which of them doesn't exist of a named property in the object model (e.g. in the object browser)? And if I really find some, there will be no explanation/description.
@ Second: I don't quite follow what you mean.
@ Third: I didn't think about "system or dynamic properties that are hidden for reasons of stability". But they could be interesting though. But properties such as “LabelName” are certainly not hidden so that they cannot be used, but probably rather to maintain compatibility. These were the properties I was referring to.
@ Fourth: I was more interested in finding something out within the community. Then everyone would benefit. I would also be more inclined to believe you than an AI.
Perhaps I should have phrased that differently at the beginning.
It's not specifically about compiling a complete list for the sake of it, but rather about gathering knowledge about such useful properties in one central location.
I would have thought that uncovering the possibilities this opens up would be of interest to many programmers.
As a starting point, have you considered asking Karl if he has a list (even if incomplete)?
He’s not an AWF member so it’s unlikely he will get to read this thread unless prompted.
Well, as a FYI?
I think what matters most, and what will affect most developers?
Why of course the properties that Access generates WHILE in form design mode, and you change the form's record source.
This "effect" and "design time" creating of properties is critical to most developers.
Why?
Well, have you ever worked say on some forms of a application that been under development for a long time?
You will "often" see a dog pile of invisible controls piled up in some corner of the form. And the reason why this occurred?
Well, all of a sudden, out of the blue, a property (say a data column from the forms data source) stopped working!!!
But, why would this occur? Why all of sudden would a field from the data source go missing?
answer:
Because often, there is VBA code to CHANGE the forms data source! And if you change the forms data source at runtime, then Access does NOT re-generate the columns for you!
Hence this code fails:
Code:
Me.RecordSource = "select id, FirstName, LastName, HotelName from tblHotelsA"
Debug.Print Me.HotelName ' this line fails
But, if we use this syntax (! -- bang notation), then it runs:
So, why does first example fail?
Because when you first design the form, Access takes the DESIGN TIME recordsource, and has/does a "big favor" for you, and generates properties for all of the field (column) names for you!!!
But, if you actually add the control on the screen (a textbox named hotelName), then the code will ALWAYS work. (hence that "dog pile" of invisible controls that the developer started using because their code was all of a sudden breaking). And their code started breaking because the runtime change of data source has/had extra columns not present when form was designed, or it's missing columns that existed when the form was first made.
In fact, you can re-trigger this re-creating, and I have often done this. The "trick" is to empty the forms data source, tab out, and then change/re-enter the data source. And with a large application, you often see/notice a big delay when you tab out, as access THEN re-generates and "adds" the properties to the form for you.
So, at the end of the day?
Some big huge long lists of properties? Gee, not much use.
However, using "." (dot) notation in code to reference column values? I consider that a bad habit!!!
Dot notion will ALWAYS work if a control of given name exists, but for pure data operations, and NOT careing if a control on the form exists or not?
Then I suggest using "!" (bang) notation, as it will ALWAYS work!
Now, to be fair, there are differing views on this issue. And in fact some LIKE the fact that code exists using "dot" notation, since then if they change the form's reocrd source (at design/developer) time, and ALSO re-force access to re-gen the forms properties? Then you get a compile error for any column that does not exist anymore!!! While using bang will trigger a run-time error - but NOT at compile time!
So, there's really no "one way" or the "other way" to deal with this pesky issue, but I've adopted this rule:
If I only care about the data column, then I use ! (bang).
If I care about if the control exists on the form, then I use "dot" notation.
So, over time as a developer does more and more code with Access?
Then I find that VBA code to modify, or change the forms record source will occur more often, and thus you "more often" can then introduce bugs and issues if said code used dot notation (and a control of given name is NOT on the form).
Of course, some developers also get around this issue by ALWAYS using a different name for the control vs it's data source.
I don't mind this idea, and is in fact a great design approach.
However, oh so many of the applications I worked on, or have made didn't follow this design choice.
So, from at developer point of view? Never really cared about some long list of a forms built in properties or some document.
However, WHEN it comes to accessing a forms data source then over time, developers will be bitten by the above nasty behaviors -- often fixed by that "dog pile" of hidden controls piled up in the corner of the form -- thus ALWAYS allowing dot notation to work....
As a starting point, have you considered asking Karl if he has a list (even if incomplete)?
He’s not an AWF member so it’s unlikely he will get to read this thread unless prompted.
Hi, no, I didn't ask him yet. I could actually do that, thanks for the suggestion.
@Albert D. Kallal :
Thank you for your detailed reply.
While reading, I wondered when you would get to the point of this thread, but ultimately I feel that your post would be better suited to its own thread, as it deals with a different topic and your 'trick' would otherwise get lost? If I were you, I would repost it in a separate thread.
To view a list of the properties of something, just add the expression to the watch window:
It could be traversed using a loop, but it's handy to just open it from the watch window because you get to see how it is initialized, type, value, etc. To know which ones are not accessible using dot notation you would require a programmatic way to traverse all the members of an object. Doing so requires low level programming and I've seen it done by a user on MrExcel, where he retrieves not only the members visible, but also those that aren't even exposed. Maybe you can cross his solution with a loop through the properties collection of your desired object in order to achieve what you desire.
@Edgar_ : Thank you for the information. But as I have already written here and added in my first post now, it's not specifically about compiling a complete list for the sake of it, but rather about gathering knowledge about such useful properties in one central location.
So if anyone knows of any others of such properties, it would be great to mention them here.
Access (in fact, everything that uses VBA) has the potential for such "hidden" items that can only be determined by very determined people. It has a LOT of "hooks" but internals documentation is not forthcoming. Access is not an OpenSource utility. It was/is oriented for people who want to "roll their own" favorite special stuff.
@ First: Sure, I could loop the collection, but how to check programatically which of them doesn't exist of a named property in the object model (e.g. in the object browser)? And if I really find some, there will be no explanation/description.
> But if you DO find something via enumeration, you can later look it up by name. However, it is possible that MS wouldn't reveal a list of such things because they treat Access as proprietary code, i.e. "keep your chopsticks out of my rice bowl." Which means that except by accident, there would BE no documentation out in the wilds. Only internal to the folks at the MS offices in Redmond. You also have to ask whether such an activity would violate the EULA by "reverse engineering" Access internals. If you dig deep enough, your EULA forbids that.
@ Second: I don't quite follow what you mean.
> VBA allows this little method called .CreateProperty that allows you to create an arbitrary property as part of an object's .Properties collection. If someone hides info in a created property, maybe as a way to retain operational information unique to his/her app, you would only get documentation for it by asking the author of the app. In essence, we can create what we wish as a property, within the limits of VBA itself, and if we did so, it would fall into your class of undocumented properties.
@ Third: I didn't think about "system or dynamic properties that are hidden for reasons of stability". But they could be interesting though. But properties such as “LabelName” are certainly not hidden so that they cannot be used, but probably rather to maintain compatibility. These were the properties I was referring to.
> It isn't commonly referenced, but in fact .LabelName is a property that is filled in when a control has an associated label. I don't know how long that has been a property, but originally you had to use the .Parent property on a label to find the control associated with the label. But more important, dorking around in intentionally hidden object properties can lead to a LOT of confusion. Turns out that there is potential in the Locals window for you to identify infinite loops. Because one of the properties is often "Parent" which, if you follow it (EDIT: Specifically, using recursion methods), eventually leads you back to where you started... and then you are on the whirligig, going round and round, and where it stops, nobody knows.
@ Fourth: I was more interested in finding something out within the community. Then everyone would benefit. I would also be more inclined to believe you than an AI.
> A commendable intention, and thanks for the implied vote of confidence. It's nice to know I'm more believable than an AI. Might not be a well-founded trust, but hey, I take whatever compliments I can get.
As to benefitting the community, I don't disagree ... BUT see discussion about EULA in the "first" comments. Looking for a quick-and-dirty link to "hidden property" definitions is a good goal, but I did some searching before I answered the first post of this thread and if there is such a page, I have yet to find it. I can't say it doesn't exist, but it may well be disguised - if it exists at all. MSFT might well want that hidden to prevent someone from building an unapproved utility that would lead to the ability to crack security on an already-weakly secured product. We just don't know what is in there. But MSFT hides things for a very understandable reason... killing the competition so they can make more money. (Was I being a bit too cynical there?)
As I said, I don't want to use a sledgehammer to find the Holy Grail or other artifacts, but rather encourage the community to introduce properties that haven't been mentioned here yet.
At least that was my idea, which unfortunately was somewhat misunderstood (but I think I may have expressed myself poorly).
Let's wait and see, maybe someone else will come forward with another useful property.
One thing that hasn't been mentioned yet in this thread is that there are two Properties windows: the one in Access when designing an object, but also the one in VBA. The latter has several new-ish properties such as the Theme-related ones that are not in the former.
