How can a control on a Form not have a TYPE property ?????

This simple code in a form

=============================
Public Sub test()
Dim intcounter As Integer, IntCtrlCount As Integer
IntCtrlCount = Me.Controls.Count
On Error GoTo errhandle

For intcounter = 0 To IntCtrlCount - 1
Debug.Print Me.Controls(intcounter).NAME
Debug.Print Me.Controls(intcounter).Type
Me.Controls(intcounter).Enabled = False
Next
Exit Sub

errhandle:
Debug.Print CStr(Err) & " " & Error
Resume Next
End Sub
==============================

Produces these errors

Label51
438 Object doesn't support this property or method
438 Object doesn't support this property or method
CmdHoldFocus
438 Object doesn't support this property or method
Label53
438 Object doesn't support this property or method
438 Object doesn't support this property or method

...............................................................................

I know many controls do not have the ENABLED property, (like
CmdHoldFocus ) but those controls with the second error message (like
Label51, dont even seem to have the .TYPE property, which seems really
crazy to me.

How can a control not have a .TYPE property ??????

Does anyone know what is going on ?

Cheers

Ray

"Accessed" <(E-Mail Removed)> wrote in message
news:497d5af6-58ed-4606-ad6f-(E-Mail Removed)...
> How can a control on a Form not have a TYPE property ?????

Because it has a ControlType property instead.

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no private e-mails, please)

Accessed wrote:

>How can a control on a Form not have a TYPE property ?????
>
>This simple code in a form
[snip a bunch of misguided code]


Maybe because controls have a ControlType property instead?

--
Marsh
MVP [MS Access]

On Mar 24, 10:23*am, Marshall Barton <marshbar...@wowway.com> wrote:
> Accessed wrote:
> >How can a control on a Form not have a TYPE property ?????
>
> >This simple code in a form
>
> [snip a bunch of misguided code]
>
> Maybe because controls have a ControlType property instead?
>
> --
> Marsh
> MVP [MS Access]

yes true - but maybe I am not so much misguided, as misdirected by
Access documentation.

What on earth would me.control(0).type refer to if not the "type" of
a control? ( It works for some controls but not others) - the data
type ?, the phase of the moon ?? Why is the TYPE property there, but
inconsistantly applied, I ask myself! There is probably some MSLogical
reason - do I want to know ?.

for now I thank you for the enlightenment, and will chastise myself
with a strong cup of coffee

(I have tried other types of Enemas, but they just dont work as well)

Accessed wrote:

>On Mar 24, 10:23*am, Marshall Barton <marshbar...@wowway.com> wrote:
>> Accessed wrote:
>> >How can a control on a Form not have a TYPE property ?????
>>
>> >This simple code in a form
>>
>> [snip a bunch of misguided code]
>>
>> Maybe because controls have a ControlType property instead?
>>
>
>yes true - but maybe I am not so much misguided, as misdirected by
>Access documentation.
>
>What on earth would me.control(0).type refer to if not the "type" of
>a control? ( It works for some controls but not others) - the data
>type ?, the phase of the moon ?? Why is the TYPE property there, but
>inconsistantly applied, I ask myself! There is probably some MSLogical
>reason - do I want to know ?.
>
>for now I thank you for the enlightenment, and will chastise myself
>with a strong cup of coffee
>
>(I have tried other types of Enemas, but they just dont work as well)


Don't get so bent out of shape over your expectations being
off base ;-)

You second guess is the most sensible. Controls that do not
have a value don't have a data Type property. Try searching
VBA Help for Type Property (DAO)

--
Marsh
MVP [MS Access]

What you see are the public properties of the object. However, in object
orienting programming (OOP), there are a lot of internal (not public to the
outside but visible to the programmer programming the code source of this
object) properties and methods, for the object itself or one of its
ancestors. I won't be surprised to know that in these cases, the name TYPE
was already reserved for something else and that defining a public property
would possibly cause some clash at some point. At happens quite frequently
with some generic names such as TYPE or DATE or NAME.

Also, in OOP, event when there is a clash, it's usually possible to use it
anyway and to resolve the clash by some other way with some override when
it's necessary. However, this lead to more confusing code to the external
developers because at some point, it can become very hard to simply know to
what property or method you are referring to at any particular point of the
code. Some developers will go this way but others won't.

In modern OO language such as C# or VB.NET, namespaces are usually used to
evit many of these potential clashes.

--
Sylvain Lafontaine, ing.
MVP - Windows Live Platform
Email: sylvain2009 sylvainlafontaine com (fill the blanks, no spam please)
Independent consultant and remote programming for Access and SQL-Server
(French)


"Accessed" <(E-Mail Removed)> wrote in message
news:f2a17639-be5a-44d9-b331-(E-Mail Removed)...
On Mar 24, 10:23 am, Marshall Barton <marshbar...@wowway.com> wrote:
> Accessed wrote:
> >How can a control on a Form not have a TYPE property ?????
>
> >This simple code in a form
>
> [snip a bunch of misguided code]
>
> Maybe because controls have a ControlType property instead?
>
> --
> Marsh
> MVP [MS Access]

yes true - but maybe I am not so much misguided, as misdirected by
Access documentation.

What on earth would me.control(0).type refer to if not the "type" of
a control? ( It works for some controls but not others) - the data
type ?, the phase of the moon ?? Why is the TYPE property there, but
inconsistantly applied, I ask myself! There is probably some MSLogical
reason - do I want to know ?.

for now I thank you for the enlightenment, and will chastise myself
with a strong cup of coffee

(I have tried other types of Enemas, but they just dont work as well)