kascemass.blogg.se - Which is not a microsoft access database object

#Which is not a microsoft access database object code

This property returns a reference to the object from which the currently executing macro or VBA procedure was called. If intState = acObjStateDirty + acObjStateOpen ThenĭoCmd.Close intCurrentType, strCurrentName, acSaveYesĪnother useful property, especially in error-logging, the CodeContextObject property of the Application object. IntState = SysCmd(acSysCmdGetObjectState, intCurrentType, _ If intCurrentType = acForm And strCurrentName = "Products" Then StrCurrentName = Application.CurrentObjectName IntCurrentType = Application.CurrentObjectType If these conditions are true, the form is saved and then closed. You can see how it uses CurrentObjectName and SysCmd to check the state of a particular form: The following example uses the CurrentObjectType and CurrentObjectName properties with the SysCmd function to determine if the active object is the Products form and if this form is open and has been changed but not saved. The example below appears in the help file for Access 2003. For that, you can use SysCmd acSysCmdGetObjectState, or check the IsLoaded property of the appropriate AccessObject via CurrentProject.AllXXXXX (AllForms, AllReports, and others)) or CurrentData.AllXXXXX (AllTables, AllQueries, and others). However, they don't tell you whether the current object is open, or what view it's in.

These properties will give you the name and type of the object that Access thinks is active.

Application.CurrentObjectType - the type (numeric, from the AcObjectType enumeration e.g., acTable = 0, acQuery = 1, acForm = 2, etc.) of the current object.

Application.CurrentObjectName - the name of the currently active object, whether it's open or not, even if it's just selected in the database window.

I believe they have existed since at least Access 97. There are also a couple of properties of the Application object that can come in handy. Also, ActiveDatasheet won't tell you about a query or table that is open in design view. There's a difficulty with the ActiveDatasheet property, in that it's not easy to tell whether the datasheet is a query datasheet or a table datasheet (though you can figure it out from the TypeName of the object).

Screen.PreviousControl - returns a reference to the control that last had the focus, before Screen.ActiveControl received the focusĪll of those properties will raise an error if there is no such object.

In addition, the Screen object provides a means to refer to the object that *previously* had the focus:

Screen.ActiveDatasheet - returns a reference to the table or query datasheet that has the focus (if there is one).

Screen.ActiveReport - returns a reference to the report that has the focus (if there is one and it's not a popup report).

Screen.ActiveForm - returns a reference to the form that has the focus (if there is one and it's not a popup form).

Screen.ActiveControl - returns a reference to the control that has the focus (if there is one).

There are some properties of the Screen object that return object references to active objects:

This article will list a variety of them. Nevertheless, there are various ways to find out. If you are writing a general-purpose routine, you may not know in what context that routine will be called, what form or control triggered it, or what the user was doing when it happened. For example, if you are writing an event procedure, you know what object raised the event.

#Which is not a microsoft access database object code

Most often when you are writing code for an Access application, you know what object - control, form, report, etc.