UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> Event for Form/Save in Design, or from Import?    
 
   
JohnCusack
post Feb 15 2008, 03:18 PM
Post#1



Posts: 72
Joined: 2-July 07
From: Vancouver, WA USA


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 :(
Go to the top of the page
 
theDBguy
post Feb 15 2008, 03:44 PM
Post#2


Access Wiki and Forums Moderator
Posts: 75,727
Joined: 19-June 07
From: SunnySandyEggo


I don't believe so. What are you trying to accomplish?
Go to the top of the page
 
Sligo
post Feb 15 2008, 03:45 PM
Post#3


UtterAccess VIP
Posts: 972
Joined: 22-June 07
From: Indianapolis, IN (between Terre Haute & Muncie)


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
Go to the top of the page
 
JohnCusack
post Feb 15 2008, 04:49 PM
Post#4



Posts: 72
Joined: 2-July 07
From: Vancouver, WA USA


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.
Go to the top of the page
 
jwhite
post Feb 15 2008, 11:12 PM
Post#5


UtterAccess VIP
Posts: 5,818
Joined: 31-August 06
From: North Carolina, USA


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.
Go to the top of the page
 
JohnCusack
post Feb 17 2008, 03:26 AM
Post#6



Posts: 72
Joined: 2-July 07
From: Vancouver, WA USA


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.
Go to the top of the page
 
jwhite
post Feb 17 2008, 03:55 PM
Post#7


UtterAccess VIP
Posts: 5,818
Joined: 31-August 06
From: North Carolina, USA


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 to the top of the page
 
JohnCusack
post Feb 18 2008, 08:30 AM
Post#8



Posts: 72
Joined: 2-July 07
From: Vancouver, WA USA


Go figure...
From ACC2000: DAO LastUpdated Property Returns Incorrect Date/Time
<
I'll look to see if exposure is now available sad.gif
Go to the top of the page
 
jwhite
post Feb 18 2008, 10:10 PM
Post#9


UtterAccess VIP
Posts: 5,818
Joined: 31-August 06
From: North Carolina, USA


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.
CODE
SELECT GetObjectType([Type]) AS ObjectType,
       MSysObjects.Name,
       MSysObjects.DateCreate,
       MSysObjects.DateUpdate
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.
CODE
SELECT GetObjectType([Type]) AS ObjectType,
       MSysObjects.Name,
       MSysObjects.DateCreate,
       MSysObjects.DateUpdate
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...
Go to the top of the page
 
JohnCusack
post Feb 19 2008, 12:41 PM
Post#10



Posts: 72
Joined: 2-July 07
From: Vancouver, WA USA


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.
Go to the top of the page
 
jwhite
post Feb 19 2008, 06:05 PM
Post#11


UtterAccess VIP
Posts: 5,818
Joined: 31-August 06
From: North Carolina, USA


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.
Attached File(s)
Attached File  Ac2003_MSysObjects_DateUpdate.jpg ( 54.95K )Number of downloads: 8
 
Go to the top of the page
 
JohnCusack
post Feb 19 2008, 06:43 PM
Post#12



Posts: 72
Joined: 2-July 07
From: Vancouver, WA USA


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!
Go to the top of the page
 
JohnCusack
post Feb 19 2008, 07:19 PM
Post#13



Posts: 72
Joined: 2-July 07
From: Vancouver, WA USA


My Form Object dates are all outta-whack. Take a look at my screenshot.
Attached File(s)
Attached File  FormDates.JPG ( 263.59K )Number of downloads: 4
 
Go to the top of the page
 
jwhite
post Feb 20 2008, 06:58 AM
Post#14


UtterAccess VIP
Posts: 5,818
Joined: 31-August 06
From: North Carolina, USA


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.
Go to the top of the page
 
JohnCusack
post Feb 20 2008, 07:17 PM
Post#15



Posts: 72
Joined: 2-July 07
From: Vancouver, WA USA


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?
Go to the top of the page
 
jwhite
post Feb 23 2008, 10:51 PM
Post#16


UtterAccess VIP
Posts: 5,818
Joined: 31-August 06
From: North Carolina, USA


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!
Go to the top of the page
 
JohnCusack
post Feb 25 2008, 12:51 PM
Post#17



Posts: 72
Joined: 2-July 07
From: Vancouver, WA USA


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
Go to the top of the page
 


Custom Search


RSSSearch   Top   Lo-Fi    21st July 2019 - 10:21 AM