Full Version: Event for Form/Save in Design, or from Import?
UtterAccess Forums > Microsoft® Access > Access Forms
I am curious as to whether there is an Event fired when a new form is saved in DesignView? If so, is there another Event fired when a Form is exported from then imported into another mdb (the event occuring when imported rather than exported)?
I've looked at the Application object, a little, not immediately finding what I want.
I thought of using MSysObjects table events (if they exist).
Haven't found a breadcrumb yet :(
I don't believe so. What are you trying to accomplish?
I am not aware of any trap-able events that fire during any of these operations. Pretty much, form events only fire when the form is open in normal mode. An external routine (i.e. a code module or another form) can open a form in design mode and actually make changes (like adding or deleting controls), but while this is happening, none of the events on the form itself will fire.
hope this helps.
- Sligo
I am building a "UserFormsAppearance" table (not the actual name) to allow users control over the appearance of some form properties and form's object properties for specific forms. I want to provide to the user a "FormsAvailable" table that identify the forms and the objects on that form that are customizable.

The "FormsAvailable" table should be self-maintaining:
The addition of a form will require a row to be inserted into the "FormsAvailable" table. Upon a new form's save (or the import of a form, if possible), I would like the creater of the form to be prompted to set certain "flags" or yes/no fields before the row is inserted. These column values would determine whether or not the user had control over certain aspects of each form's appearance (label or textbox properties like fontname or fontbold, for instance).

Oknow that the MSysObjects table's MSysObjects.Flags = 0 AND MSysObjects.Type = -32768 will return the existing forms of a mdb. Is there an Event that fires when new rows are inserted into this table? I could use that.

Are there any Application-level objects that are made aware of new form saves or imports?

I suppose I could create a Form, launched on startup, with a cmdNewForm button, with code attached to do just as described above (i.e. create a form, prompt for "FormsAvailable" info, save the form, insert the "FormsAvailable" row)...

Edited by: JohnCusack on Fri Feb 15 17:11:12 EST 2008.
This sounds interesting...
Perhaps before opening form for the user to Edit, read MSysObjects.DateUpdate for the form. After the form is closed, read the value again to see if there is a difference.
HAs for NEW or IMPORTED forms... Hmm.... Maybe before giving them the option to import form names, build a temp table of the current forms. After they complete the import process, do it again, and run a mis-match query between the two to get a list of what's new. I'm thinking this way because they could do a Save As on ya and it wouldn't match what they may have said it would be named in your interface...
Hope that helps clear the mud alittle.
Oh, helps greatly. Makes me take a step back and think about it.
like your thinkin...I'll just "monitor" MSysObjects for new forms and prompt the "admin" of the app to update the secondary table for any new forms that may appear in MSys...
Much better than worrying about all the ways a new form could be created...
Thanks for the idea.
You're Welcome! thumbup.gif Good luck with your project!
Any chance you would be willing to post a demo in the Code Archive after all is working okay? Sounds like it would be a worthy edition.
Go figure...
From ACC2000: DAO LastUpdated Property Returns Incorrect Date/Time
I'll look to see if exposure is now available sad.gif
Appears to have been fixed in Access 2003 (I'm running Ac2003 SP2). The query below (and called function) correctly returns the .DateUpdate value for objects that I updated moments ago.
SELECT GetObjectType([Type]) AS ObjectType,
FROM MSysObjects
WHERE (((GetObjectType([Type]))<>"") AND ((Left([Name],1))<>"~") AND ((Left([Name],4))<>"msys"))
Order have been fixed in Access 2003 (I'm running Ac2003 SP2). The query below (and called function) correctly returns the .DateUpdate value for objects that I updated moments ago.
SELECT GetObjectType([Type]) AS ObjectType,
FROM MSysObjects
WHERE (((GetObjectType([Type]))<>"") AND ((Left([Name],1))<>"~") AND ((Left([Name],4))<>"msys"))
ORDER BY GetObjectType([Type]), MSysObjects.Name;
Function GetObjectType(pType) As String
    Select Case pType
        Case 1,4,6
                GetObjectType = "Table"
        Case 5
                GetObjectType = "Query"
        Case -32768
                GetObjectType = "Form"
        Case -32764
                GetObjectType = "Report"
        Case -32766
                GetObjectType = "Macro"
        Case -32761
                GetObjectType = "Module"
        Case Else
                GetObjectType = ""
    End Select
End Function
Are you actually using Ac2000? If so, ugh...
But, but...

(Look above, I'm on 03 sad.gif

You're not displaying the "internal mechanism" object as described in my previous post. You're only displaying the .DateUpdate value from MSysObjects, which is no longer used by Access (according to kb entry) to maintain the modified date of the object. You'll note that the DateUpdate value NEVER changes (atleast not in mine).

HAs of yet, I haven't found whether or not this object has been exposed.
Eh, you quoted an Ac2000 KB, which makes the reader think you may be on Ac2000.

"Internal Mechanism" ???????????????? What is that? sad.gif

Eh, the .DateUpdate in my MSysObjects tables changes whenever I update an object...

The screenshot attached is using the query and function posted earlier in this thread.
Ah, yes. I could see why one would think I'm on Ac2000...
can see that the objects displayed in your form have more recent DateUpdate values. Is this true that the Form objects, of which I see none, do as well?
I've looked at the DateUpdate values for all my objects. All DateUpdate values match the database window values, and appear to be reflecting the same values in MSysObjects, EXCEPT forms.
If it's just me, then frizzle frazzle!
My Form Object dates are all outta-whack. Take a look at my screenshot.
I retrack my statement :(
orry, I didn't look beyond the tables. For me, only tables show the .DateUpdate as the correct update date. I reckone to see if a new form has been added, you will have to refresh a forms list table, let the user to his/her thing, then do a forms count against the count in your table - if 1 more then they saved to a different name - create another forms list table and run a mis-match query to get the name.
Well, I be sad for you, too!
That is worse, neither forms nor tables retain their MSysObjects.ID after additions, deletions, or renames. What's an ID for? Sheesh!
From what I have seen, the only constant value in the MSysObjects table is the DateCreate. How likely is it that two forms will have the same creation date? So, even in the situation where a form is renamed, it will still retain the same DateCreate value. Perhaps by pairing the DateCreate and Type fields from MSysObjects, I could create a unique ID in my own forms table, and automatically update my forms table based on the existence of a form with a new DateCreate_Type field combination in the MSysObjects table? The form may run-change names, but it can hide - it's DateCreate field, atleast. sad.gif
What are your thoughts on that?
Very minimal, as the Time portion includes seconds. Sounds like .DateCreate is the only way to go. Not sure what you mean by "DateCreate and Type fields".
Glad you posted here, as I never would have known about the Date/Time not updating until it bit me in the rump sometime later!
I'm thinking of concatenating the DateCreate and Type fields from MSysObjects, and using that concatenated value as the Unique ID field for my own Form table. So, I'd get an ID similar to "2/20/2008 3:42:25 PM-32768".
Perhaps one day I might want to build a table of Queries, so "2/20/2008 3:42:25 PM5" for a Query object, and so on...
Thanks for improving my thought process sad.gif
This is a "lo-fi" version of UA. To view the full version with more information, formatting and images, please click here.