Object, Microsoft Library Referrence and LASsie

[khurram7x]

Hi n Happy New Year to all!!

I'm getting Error: 438, Message: Object doesn't support this property or method. I'm getting this error while using LASsie from PetersSoftware for permissions and this happens when I try to put restriction on some Control on the Form. It works fine if i put restriction on full form, but whenever I try to do this for the 'Control' i get into this error.

Debug shows that I'm getting error when i use 'obj.Name' object on line 2 and 3 of following procedure. obj is defined as Dim obj AS Object, but I could not find this object has been initialized anywhere using 'Set obj = ...' in the program except in the end Set obj = Nothing.

I could guess that question is not clear enough as I'm not sure what more should I provide in this regard... and this is first time i'm coming across 'Object' type, but any direction will be helpful. Reference Library i think is set for 'Object' types or else i would get some other error?

Thanks in advance,
K

1: Do While Not rst.EOF
2: Debug.Print obj.Name
3: If rst!IsObjectBased And rst!ObjectName = obj.Name And rst!Restricted 4: Then
... '* This form is restricted for the current user
'mb "You are not allowed to view this " & strObjType & "."
iDenyAccessToThisObject = True
GoTo Continue
End If
rst.MoveNext
Loop

 

[sneuberg]

Could it be set (should it be set) by the calling procedure? Is obj a parameter in this procedure?

 

[The_Doc_Man]

Put a breakpoint in the code just before you attempt to set the property that you are trying to set (sounds like a permission). Open the Locals window. Find the object. Expand its properties and look for the property you are trying to set. At least that way you will be able to distinguish between "property not supported" and "method not supported" - because you will SEE all the properties.

 

[khurram7x]

Calling procedure is sending 'Me' as a parameter. Yes, Object is a parameter in function called.

I've put a break point and 'Name' property is indeed there for the 'Object' collection set, attaching screenshot, and its value is 'Microsoft Access'! I don't have any idea where this Microsoft Access is coming as a value in Name!!!

 

[sneuberg]

They look like properties of the object Application. They certainly are not the properties of a form. Instead of passing Me I suggest trying Forms!TheFormName or Forms("TheFormName") as a test.

Also the form has to be open for the object to exist. Is it?

 

[khurram7x]

Thanks. Yes the object was not the correct form. I was using onLoad event, but I should have used onOpen. Though I'm not clear why destination form is losing focus when it moves from onOpen to onLoad. Shouldn't it keep the focus theoretically between onOpen and onLoad events?

Thank you.

 

[sneuberg]

Shouldn't it keep the focus theoretically between onOpen and onLoad events?

I don't know. Sounds like something The_Doc_Man might know about. You could send him a PM or start a new thread with this question.

What I do know is that a form can't receive focus if it has any controls. If the form has controls the focus will end up on one of the controls in the form; the first in the tab order I suppose. I believe that during one of these events (load and open) the form has controls and during the other it doesn't. Maybe that has something to do with it.

 

[The_Doc_Man]

The only time I've ever seen a "production" form take focus was when the form's OnLoad or OnCurrent event evaluated its condition and disabled all controls potentially capable of having individual focus. It happened in my big project where the security code would disable controls based on your role. (I later fixed that so that the launcher button would just not launch the form in the first place, but hey - it was a work in progress at the time. Sometimes the form launched when it shouldn't have...)

As to the OnOpen, OnLoad sequence, the only thing that COULD interrupt them is if multiple forms are open and one of the non-current forms with code running in the background on a timer takes an OnError event during the OnOpen event of the form being scrutinized. Normally, events are linearized because events cannot interrupt each other, which is why you have a DoEvents call.

By any chance does the OnOpen do any lengthy calculations? Because otherwise the window for that gap between firing the OnOpen and OnLoad events is miniscule, like less than 1 millisecond. (I've measured it once using the system high-precision timer when debugging a particularly troublesome form.)

If the form in question has active controls, then the form never truly has focus - though it can contain a control that DOES have focus. However, in a really picky sense of the term, focus has no meaning in form-level event code unless you use something like the Screen.ActiveControl method to see which control has the focus. The "picky" concept is that unless the active control has an event that just fired - a control event such as OnChange or GotFocus or something like that - the active control is just like any other control for VBA purposes. Focus is a "display" / GUI concept.

The more precise term is that the form is Activated or Deactivated - but that is also an event that fires AFTER the OnLoad event - and after OnCurrent if applicable. I'm not going to swear on a stack of your favorite holy books, but I think the GotFocus event for the control that DOES have focus doesn't fire until all of the form-as-a-whole events are finished. Further, if it was an Activate event because some other form went on top and later was closed so that the form in question activated again, I'm not sure that a GotFocus occurs for the control that DOES have focus in that case.

 

[khurram7x]

Thank you Sneuberg and Doc Man for detailed discussion. It indeed helped to clear quite of concepts. In my case OnOpen do have calculations but I could not say that they're very lengthy and the whole process, once 'OK' button is pressed and switchboard form is opened, takes less than a second.

If Form object is sent as a parameter to a function with an Object argument type, then in my limited knowledge, form had the focus. This lead to few questions which I tried to clear with your kind help.

 

[The_Doc_Man]

In this, you are correct, khurram7x. If you were executing code from a form that could send its name, then at least something on that form either DID have focus or shortly WILL have focus. And of course, that means the form is loaded, open, and active.

If your function is in a general module, then you have a few acceptable ways to pass arguments that will lead to that form. I don't know what nomenclature you used when learning how to do this, so forgive me for a clarification that you might know already. The FORMAL argument is the argument in the definition of the function and inside the body of the routine you use the formal argument's name. The ACTUAL argument is the variable or constant that is provided when you invoke/call the routine in question.

1. You can pass the form's name as a string formal argument, using "Me.Name" for the actual argument.

Public Sub MyCode( FName as String )

... x = Forms(Fname).Height

If so, you would use the name in a construct like "Forms(name-string-variable).property" to reference the form.

2. You can pass the form as an object formal argument using "Me" as the actual argument, in which case you would use the formal object variable as "object-variable.property" to do things on the form.

Public Sub MyCode( objX as Object )

... x = objX.Height

3. You can pass the form specifically as a form reference. Again, you would use "Me" as the actual argument and would use "form-variable.property" to do things on the form.

Public Sub MyCode( fFrm as Access.Form )

... x = fFrm.Height

The difference between #2 and #3 is that Intellisense recognizes #3 as using an object of type Access.Form so will know the properties of the object immediately. Method #2 uses a generic object and Intellisense will be limited in what it can do to help you.