By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,804 Members | 1,631 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,804 IT Pros & Developers. It's quick & easy.

A97 permissions help example does not compile

P: n/a
MLH
Invalid qualifier error displays at compile time on this A97 example
from Permissions Property HELP. What's wrong with the strContainerName
assignment line? (6th line)

Sub SetDocPermissions(docUnknown As Document)
Dim strContainerName As String
' Set UserName property to valid existing group account.
docUnknown.UserName = "Marketers"
' Get value of Container property.
strContainerName = docUnknown.Container.Name
Select Case strContainerName
Case "Forms"
' Set permissions for Form Document object.
docUnknown.Permissions = docUnknown.Permissions Or _
acSecFrmRptWriteDef
Case "Reports"
' Set permissions for Report Document object.
docUnknown.Permissions = docUnknown.Permissions Or _
acSecFrmRptExecute
Case "Scripts"
' Set permissions for Script Document object.
docUnknown.Permissions = docUnknown.Permissions Or _
acSecMacWriteDef
Case "Modules"
' Set permissions for Module Document object.
docUnknown.Permissions = docUnknown.Permissions Or _
acSecModReadDef
Case Else
Exit Sub
End Select
End Sub

Oct 15 '06 #1
Share this Question
Share on Google+
13 Replies


P: n/a
MLH wrote:
What's wrong with the strContainerName
assignment line? (6th line)
It's a typographical error. The Container property is a string, not an
object, so it doesn't have a Name property. Change that line of code to this:
strContainerName = docUnknown.Container

--
Message posted via http://www.accessmonster.com

Oct 16 '06 #2

P: n/a
"Granny Spitz via AccessMonster.com" <u26473@uwewrote in
news:67d345dfca650@uwe:
MLH wrote:
>What's wrong with the strContainerName
assignment line? (6th line)

It's a typographical error. The Container property is a string, not
an object, so it doesn't have a Name property. Change that line of
code to this:

strContainerName = docUnknown.Container
Dim c As Container
Dim d As Document
Set c = DBEngine(0)(0).Containers("Forms")
Debug.Print VarType(c) '9 (object)
Set d = c.Documents(0)
Debug.Print VarType(d.Container) '8 (string)

Ohhhh yeah!

--
Lyle Fairfield
Oct 16 '06 #3

P: n/a

Don't you just love Microsoft.

--

Terry Kreft
"Lyle Fairfield" <ly***********@aim.comwrote in message
news:Xn*********************************@216.221.8 1.119...
"Granny Spitz via AccessMonster.com" <u26473@uwewrote in
news:67d345dfca650@uwe:
MLH wrote:
What's wrong with the strContainerName
assignment line? (6th line)
It's a typographical error. The Container property is a string, not
an object, so it doesn't have a Name property. Change that line of
code to this:

strContainerName = docUnknown.Container

Dim c As Container
Dim d As Document
Set c = DBEngine(0)(0).Containers("Forms")
Debug.Print VarType(c) '9 (object)
Set d = c.Documents(0)
Debug.Print VarType(d.Container) '8 (string)

Ohhhh yeah!

--
Lyle Fairfield

Oct 16 '06 #4

P: n/a
Lyle Fairfield <ly***********@aim.comwrote in
news:Xn*********************************@216.221.8 1.119:
"Granny Spitz via AccessMonster.com" <u26473@uwewrote in
news:67d345dfca650@uwe:
>MLH wrote:
>>What's wrong with the strContainerName
assignment line? (6th line)

It's a typographical error. The Container property is a string,
not an object, so it doesn't have a Name property. Change that
line of code to this:

strContainerName = docUnknown.Container

Dim c As Container
Dim d As Document
Set c = DBEngine(0)(0).Containers("Forms")
Debug.Print VarType(c) '9 (object)
Set d = c.Documents(0)
Debug.Print VarType(d.Container) '8 (string)

Ohhhh yeah!
Um, show me any MS example code that suggests anything else.

It's important to not confuse:

Containers(0).Name

with

Document.Container

Now, by analogy, this is basically a Parent property, and is perhaps
not parallel to other objects, but I don't see what the issue is. If
you use Intellisense and read the Help file, you'll get it right.

That's obviously why MLH can't get it right, but that oughtn't be an
obstacle to anyone with any sense.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Oct 16 '06 #5

P: n/a
Lyle Fairfield wrote:
Dim c As Container
Dim d As Document
Set c = DBEngine(0)(0).Containers("Forms")
Debug.Print VarType(c) '9 (object)
Set d = c.Documents(0)
Debug.Print VarType(d.Container) '8 (string)

Ohhhh yeah!
The Microsoft programmers were just checking to see if we were paying
attention.

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200610/1

Oct 16 '06 #6

P: n/a
David W. Fenton wrote:
Lyle Fairfield <ly***********@aim.comwrote in
news:Xn*********************************@216.221.8 1.119:
"Granny Spitz via AccessMonster.com" <u26473@uwewrote in
news:67d345dfca650@uwe:
MLH wrote:
What's wrong with the strContainerName
assignment line? (6th line)

It's a typographical error. The Container property is a string,
not an object, so it doesn't have a Name property. Change that
line of code to this:

strContainerName = docUnknown.Container
Dim c As Container
Dim d As Document
Set c = DBEngine(0)(0).Containers("Forms")
Debug.Print VarType(c) '9 (object)
Set d = c.Documents(0)
Debug.Print VarType(d.Container) '8 (string)

Ohhhh yeah!

Um, show me any MS example code that suggests anything else.
You could always look at the top post in this thread
or
http://msdn.microsoft.com/archive/de.../D2/S5A27E.asp

Oh, wait, you've plonked me so you won't see this.

Oh wait again, how did you reply to my post if you plonked me? Gee, I'm
so confused!

Oct 16 '06 #7

P: n/a
Granny Spitz via AccessMonster.com wrote:
Lyle Fairfield wrote:
Dim c As Container
Dim d As Document
Set c = DBEngine(0)(0).Containers("Forms")
Debug.Print VarType(c) '9 (object)
Set d = c.Documents(0)
Debug.Print VarType(d.Container) '8 (string)

Ohhhh yeah!

The Microsoft programmers were just checking to see if we were paying
attention.
I wasn't paying attention. Your post enlightened me.

Oct 16 '06 #8

P: n/a

It is a stupid and counter-intuitive design decision though.

--

Terry Kreft
"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn*********************************@127.0.0.1 ...
Lyle Fairfield <ly***********@aim.comwrote in
news:Xn*********************************@216.221.8 1.119:
"Granny Spitz via AccessMonster.com" <u26473@uwewrote in
news:67d345dfca650@uwe:
MLH wrote:
What's wrong with the strContainerName
assignment line? (6th line)

It's a typographical error. The Container property is a string,
not an object, so it doesn't have a Name property. Change that
line of code to this:

strContainerName = docUnknown.Container
Dim c As Container
Dim d As Document
Set c = DBEngine(0)(0).Containers("Forms")
Debug.Print VarType(c) '9 (object)
Set d = c.Documents(0)
Debug.Print VarType(d.Container) '8 (string)

Ohhhh yeah!

Um, show me any MS example code that suggests anything else.

It's important to not confuse:

Containers(0).Name

with

Document.Container

Now, by analogy, this is basically a Parent property, and is perhaps
not parallel to other objects, but I don't see what the issue is. If
you use Intellisense and read the Help file, you'll get it right.

That's obviously why MLH can't get it right, but that oughtn't be an
obstacle to anyone with any sense.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Oct 16 '06 #9

P: n/a
Lyle Fairfield wrote:
>The Microsoft programmers were just checking to see if we were paying
attention.

I wasn't paying attention. Your post enlightened me.
Then I'm very pleased to start repaying the debt I owe you for all your posts
that have enlightened me. Only 10,000 more to go ... <g>

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200610/1

Oct 16 '06 #10

P: n/a
"Terry Kreft" <te*********@mps.co.ukwrote in
news:EL******************************@eclipse.net. uk:
"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn*********************************@127.0.0.1 ...
>Lyle Fairfield <ly***********@aim.comwrote in
news:Xn*********************************@216.221. 81.119:
"Granny Spitz via AccessMonster.com" <u26473@uwewrote in
news:67d345dfca650@uwe:

MLH wrote:
What's wrong with the strContainerName
assignment line? (6th line)

It's a typographical error. The Container property is a
string, not an object, so it doesn't have a Name property.
Change that line of code to this:

strContainerName = docUnknown.Container

Dim c As Container
Dim d As Document
Set c = DBEngine(0)(0).Containers("Forms")
Debug.Print VarType(c) '9 (object)
Set d = c.Documents(0)
Debug.Print VarType(d.Container) '8 (string)

Ohhhh yeah!

Um, show me any MS example code that suggests anything else.

It's important to not confuse:

Containers(0).Name

with

Document.Container

Now, by analogy, this is basically a Parent property, and is
perhaps not parallel to other objects, but I don't see what the
issue is. If you use Intellisense and read the Help file, you'll
get it right.

That's obviously why MLH can't get it right, but that oughtn't be
an obstacle to anyone with any sense.

It is a stupid and counter-intuitive design decision though.
I don't see it.

It really isn't at all like the .Parent property of a form or
report, which exists only when the form/report is open.

The objects in document containers don't really exist. You're
reading the definitions from the data store, so I don't know why the
parent of a document should return a reference of object type
instead of a string.

Documents just aren't like other objects in Access.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Oct 17 '06 #11

P: n/a
Of course they are like any other object. An object in COM terms is
defined by it's interface not by what it is created from.

This was a counter-intuitive design decision because it would be natural to
assume that if you derive an object from a collection of objects then if
that derived object has a property which is named as the singular of it's
parent collection then that property is a pointer back to the collection.

It was a stupid decision because if the Container property had been
implemented as a pointer back to the document container object it would have
made navigation through the collection much more fluid, and utilising a Name
property on this theoretical object would have achieved the same purpose as
is currently offered by the Container property.
--

Terry Kreft
"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn*********************************@127.0.0.1 ...
"Terry Kreft" <te*********@mps.co.ukwrote in
news:EL******************************@eclipse.net. uk:
"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn*********************************@127.0.0.1 ...
Lyle Fairfield <ly***********@aim.comwrote in
news:Xn*********************************@216.221.8 1.119:

"Granny Spitz via AccessMonster.com" <u26473@uwewrote in
news:67d345dfca650@uwe:

MLH wrote:
What's wrong with the strContainerName
assignment line? (6th line)

It's a typographical error. The Container property is a
string, not an object, so it doesn't have a Name property.
Change that line of code to this:

strContainerName = docUnknown.Container

Dim c As Container
Dim d As Document
Set c = DBEngine(0)(0).Containers("Forms")
Debug.Print VarType(c) '9 (object)
Set d = c.Documents(0)
Debug.Print VarType(d.Container) '8 (string)

Ohhhh yeah!

Um, show me any MS example code that suggests anything else.

It's important to not confuse:

Containers(0).Name

with

Document.Container

Now, by analogy, this is basically a Parent property, and is
perhaps not parallel to other objects, but I don't see what the
issue is. If you use Intellisense and read the Help file, you'll
get it right.

That's obviously why MLH can't get it right, but that oughtn't be
an obstacle to anyone with any sense.
It is a stupid and counter-intuitive design decision though.

I don't see it.

It really isn't at all like the .Parent property of a form or
report, which exists only when the form/report is open.

The objects in document containers don't really exist. You're
reading the definitions from the data store, so I don't know why the
parent of a document should return a reference of object type
instead of a string.

Documents just aren't like other objects in Access.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Oct 17 '06 #12

P: n/a
"Terry Kreft" <te*********@mps.co.ukwrote in
news:Dd********************@eclipse.net.uk:
It was a stupid decision because if the Container property had
been implemented as a pointer back to the document container
object it would have made navigation through the collection much
more fluid, and utilising a Name property on this theoretical
object would have achieved the same purpose as is currently
offered by the Container property.
Well, whatever.

I've never had any problems with Containers because I've always
modelled my code for using them on the examples in the Access help
file.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Oct 17 '06 #13

P: n/a
"Terry Kreft" <te*********@mps.co.ukwrote in
news:Dd********************@eclipse.net.uk:
It was a stupid decision because if the Container property had
been implemented as a pointer back to the document container
object it would have made navigation through the collection much
more fluid, and utilising a Name property on this theoretical
object would have achieved the same purpose as is currently
offered by the Container property.
I've rethought this whole issue, and decided that I may agree to
you.

In the model you are proposing you could do this:

MyForm.Container

and get a reference to the parent container.

But that reference doesn't mean anything anywhere in Access. It
would only be useful if you could refer to something by name when
you didn't know what the type of that thing was. I can't think of
any context where we can utilize an Access object (not a Jet object)
interchangeable without needing to know its parent container.

Likewise, the subroutine posted by MLH took a Document object as its
sole parameter. There is actually no way in Access to do a:

Dim doc As Document

Set doc = [something that returns a document-type ref]

without doing it off of a container object. This is because there
are no functions or properties anywhere in Access that return a
reference of type Document except the children of containers.

Put another way, you can't get to a document without going through
the parent container. This means you have to know the parent
container to get to the document in the first place, so you already
know the name of the parent container in any context in which you
could even attempt to evaluate the value of doc.Container or of the
hypothetical doc.Container.Name.

Now, I don't know how you could unify these namespaces in Access so
that you could just refer to something by name without a container
identified, but it seems that you are claiming that doing it that
way is somehow both inconsistent with the rest of Access and
undesirable. While I might agree that it's undesirable, it is, in
fact, completely consistent with the rest of Access. Even in A2K and
above where you have CurrentProject.AllForms, etc., you still have
to go through the parent container, it's just a shortcut for
CurrentDB.Containers!Forms. It's certainly easier to understand and
a nice feature, but it doesn't actually fix the problem you seem to
me to be raising.

Indeed, it apparently returns a reference of type AccessObject,
instead of one specific to the collection/container, and it's only
the .Type property that tells you what type of object it is.

But, here again, you already know what type of object it is, because
the only way to get the reference is through a parent container.
Indeed, the model there seems rather incoherent, as it has a .Parent
property, which doesn't exist in any object that can be accessed
through one of the AllXXXX collections.

But all of that is irrelevant, as MLH is programming in A97, which
lacks those new collections.

It just seems to me that it's not at all inconsistent with the way
all of Access works, and that the property itself, whether it
returns an object pointer or a string, is pretty much irrelevant,
since you can't use the property in any context that is not already
being accessed through the relevant container/collection.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Oct 21 '06 #14

This discussion thread is closed

Replies have been disabled for this discussion.