Can access create a user defined object?

[jancheta]

Thx,
Jason

 

[cmmrfrds]

Class Modules are treated as objects and you can create class modules.

 

[jancheta]

cmmrfrds,
thx for the reply.

Here's more info. What I want to do is to create say for example a command button for saving records. Then I will write code for it only once and create an instance of the object on each form. Currently what i'm doing is copying and pasting.

Any ideas?

 

[cmmrfrds]

I don't understand, typically saving records is specific to a table. So, I don't see how you would general enough to make it useful in an object.

 

[jancheta]

Say for example, for the project I'm working on I have 20 data entry forms. Each form would have common buttons - "Add", "Delete", "Next", etc. Which means I would have to copy these buttons 20 times and copy the code of each button 20 times as well. What i'm asking is if there's a way to create a user defined object which possible has its own event procedures.

Something similar to the ActiveX controls where you could plug it in but you still have to code them individually.

Furthermore, I would like to have a common library which encapsulates the objects that I have created so that I can use them again for the next project.

 

[cmmrfrds]

You should be able to encapsulate logic and create events in a class module. To do what you are suggesting would require a grid control for a dynamic number of columns. I don't know of one in Access but there are probably 3rd party grid controls. Try experimenting with and doing research on class modules.

 

[MichaelRed]

Hmmmmmmmmmm,

Class module is probably the better approach. The logic and information doesn't vary. The cmd buttons should reasonably just call the common routine(s) with the information. GENERALL speaking, all the common routine(s) need to know is the name of the form and the desired activity (but this is/can be infered from the routine called?). From whence, the common routine can retrieve the recordsource and acocmplish the desired. Of course this ASSUMES the recordsource is a tabledef, otherwise the issue(s) are complicated by needing to know which table each (control) field belongs to.

Much of this can be done without any copy / paste by generating a SUBFORM with the appropiate command butons.

Use the SUBFORM on each form you need to use the common routines with. I still place the actual routines in a seperate (user) module. To derive the reference to the "main" form, use the parent property of the subform.

You need to be careful of the tendancy of MS. A. to 'autoupdate' the underlying recordsource whenever the record focus is moved.

I did actually implement this scheme a few years ago on an MS. A ver 97 db, although not for the specific purpose noted in this thread.

I, like cmmrfrds am a BIT puzzled about the add function, as simply placing the record pointer on the 'new' (or tenative append) record, filling in fields and movint the record pointer (on a BOUND form) is all that is required to actually ADD a record. Likewise, "Delete" the current record is a simplistic operation easily accomplished without the 'overhead' discussd here. My need to do the process was a requirement to include an audit trail of EVERY data change, including the user id and date/time stamp as well as a set of (common) validation steps for each change. And the "next" function is actually available w/o any code or command button - if your users can accept the record selector approach.

MichaelRed
m.red@att.net

There is never time to do it right but there is always time to do it over

 

[jancheta]

cmmrfrds and Michael,
Thx for your suggestions!

I'm not sure if I'm on the right path but here it goes. What I've come up with is writing functions for my Add, First, Next, Previous, etc. command buttons in the standard module. Then created a macro for each function. So for each button on the form, the On Click points to the macro (since I couldn't find a way for the On Click to point to the function in the standard module).

The reason why I'm shying away from the built in record selector approach is that I couldn't determine which of the buttons my users would click on. Say for example on a bound form, they clicked on the new record button, then populated certain field(s). If the user clicks on the previous record button or closes the form, and other fields which have relationships were not populated, then they'll get a slew of messages - some which I can control and others which I couldn't. So I thought that if I create my own record selectors then I'll have full control of the form with an open ended approach and for future projects I could re-use the buttons.

any comments?

Jason

 

[MichaelRed]

If the thrust is just to minimize the potential of errors/messages on record changes ([add | edit]), there is the normal use of the validation and cancel procedures which can simplify the process. Another alternative is to implement your app w/ UNBOUND forms. There is a bit more to code in this apprpoach, but a LOT more control of USER operations. In any instance, it is YOUR (the programmer) responsability to do reasonable V&V if data manipulation.

My advice - place all 'real' code in standard modules.

I would adivse that you review what is going on with the incapacity of generating code for your command buttons. First because MACROs are more-or-less a no-no for real applications, and second because it is either just a minor issue of how/what you are doing - or a quite serious problem which will eventually cause a lot of problems.

MichaelRed
m.red@att.net

There is never time to do it right but there is always time to do it over

 

[jancheta]

Michael,

Thx again for your suggestions!

I just found that I can place an equal sign then the function name ( like =gPrevRec() ) for the On Click event.

In my stadard module I have a function:
Function gPrevRec()
Dim fForm As Form
Set fForm = Screen.ActiveForm
On Error GoTo Err_gPrevRec
DoCmd.GoToRecord , , acPrevious ' move to previous record
Exit_gPrevRec:
Exit Function
Err_gPrevRec:
MsgBox Err.Description
Resume Exit_gPrevRec
End Function

Any further advise is appreciated.

Jason