MS Access raise form events programmatically

Question

Is it possible to raise built-in MS Access form events programmatically? I have a feeling it isn't but thought I would check. (I am using Access 2003).

For instance, I want to do something like this within a private sub on the form:

RaiseEvent Delete(Cancel)

and have it trigger the Access.Form delete event -- i.e. without actually deleting a bound record.

Note my delete event is not handled by the form itself but by an external class, so I can't simply call Form_Delete(Cancel).

Answer 1

I can understand your confusion -- I didn't explain any of the bigger context. Sorry.

Basically, the situation is I have an 'index' i.e. 'continuous-forms' form which is bound to a read-only query. The query has to be read only because it involves an outer join. But, I want to be able to delete underlying records from this form.

So my first thought was to do the deletion outside the form recordset, eg. using a delete query. And I was hoping to hook the standard Delete/BeforeDelConfirm/AfterDelConfirm events around this manual deletion routine by raising these events myself. But alas, this is not possible.

If the form itself handled these events, I could simply call the handlers (Form_Delete, etc), but my project has custom classes that handle form delete and update events (validation, confirmation, logging, etc.) for all the forms. (@Smandoli, it's not well-documented, I just discovered it a few months ago and use it extensively now -- maybe you know about it already -- you can set up external classes to handle your form events. See for example here)

Long story short, I found a workaround I'm satisfied with. It involves making the 'index' form a subform of another form that is bound to a recordset that can be deleted from. So the deletion can be done in the outer form using the standard Access form events, based on the selection in the inner form.

@Knox, I disagree in principle that being able to raise 'built-in' events yourself is difficult to document and maintain. Plenty of other frameworks depend on it. In practice, I agree with you, since we all have to work within the limitations of our tools and 'best practices' that evolve around those limitations. The blessing and curse of Access is its tight binding between recordsets and forms...