Form controls links to code funky 2

[fredzeppelin]

1. Have an Access form with several controls with custom 'on-event' code. One procedure was tied to the 'Lost Focus' event on a ComboBox. I wasn't happy with the usability of that and tried to link the procedure to a different event on the same control/form.

I now receive this message.

"The expression OnClick (or any event) you entered as the event property setting produced the following error: Procedure declaration does not match description of event or procedure having the same name."

I've cut and pasted proc's all over the form's code module to different

Private Sub btnDoThis_Click()
End Sub

procedures. I've deleted the event procedure references in the control properties. I've deleted the code. What I haven't done is start from scratch, there's a really gnarly procedure with 5 subforms, etc. running in there. (It's ugly, I inherited it).

I found a ref to this error in another thread, but that thread boiled down to conditional formatting, the error just sort of disappeared from the thread.

2. I guess the general question is are there any gotcha's with code linked to control events, and how do you change your mind after testing them.

3. What's the best way to make something happen after mouse-clicking a selection from a rowsource bound combo box?

with eternal gratitude, I'm off to search some more .....brad

 

[Sheco]

"Procedure declaration does not match description of event or procedure having the same name."

Just a guess but to me this error message sounds like your event is perhaps expecting some sort of argument that it doesn't have.

For example, a regular button click might be something like:
Private Sub btnDoThis_Click()

But if your button is part of a control array it might be:
Private Sub btnDoThis_Click(idx as integer)

Is it possible that one of your arguments is wrong or perhaps declared as the wrong data type? By argument data type I mean suppose it was As Integer when it should have been As Long.

 

[fredzeppelin]

Thanks for the reply.

I ran into the suggestion of the control array problem on another site as well. So far that's the most proposed candidate. If that's what's going on it's unintentional.

While I've been programming off and on for over 30 years (I had a dBaseII with a 3 digit serial number), this is my first time deep under the hood of Access. (I have been able to weed a bunch of similar, but modally different, forms out of the app by creating a multipurpose form and then manipulating the form/control properties.) That's what I was trying to do here, dis/enabling controls dependent upon text and combo box selections, to limit user choices to the sane ones.

I'm not sure why I'd want an array of controls, and I surely didn't build one on purpose. I understand about the argument passing into the procedure, thru proc(foo as bar). I don't think that's what's going on.

On another site, someone with the same problem was told that they were encounetering a compile error and was advised to keep debug/compiling until no errors remained.

I'm not at my own machine right now, so I'll give your idea a more thorough look when I get there.

thx ...brad

 

[RoyVidar]

If you want to copy event procedures (code attached to controls or form events), don't copy the sub header/declaration and end sub, but only the code within. Then delete the remaining header/declaration and and sub. I think sheco is right, this is the compile error access gives, for instance by copy/pasting a sub declaration and attaching to a form/control event expecting different number of and/or different types of arguements. For instance the before update event of controls has a cancel arguement, the after update doesn't.

For future Access questions, do a forum search, as there are seven fora dedicated to Access.

Control arrays, as in VB doesn't exist in Access, but there are some workarounds, some of them can be found in this faq faq702-5010 in the Access Forms forum (pluss some dynamic ways of altering properties of form controls).

If you want something to happen after a selection in a combo/list, try the after update event of the control.

Gotchas with control events - yeah - don't overpopulate;-)

Sometimes, it seems Access remembers code that has been deleted - a mismatch between the textual representation of the code, and the compiled code that's executed - which is one sign of possible corruption. The info in this link, though marketed as something entirely different, can often resolve such Decompile or how to reduce Microsoft Access MDB/MDE size and decrease start-up times

And - Welcome to Tek-Tips!
Here's a faq on how to get the most out of the membership faq181-2886

Good Luck!

Roy-Vidar

 

[fredzeppelin]

Thanks for two valuable replies. And the FAQ references.
The situation was, as speculated, that I edited/ tinkered with the existing declaration

   Private Sub Foobar_Click()
       code
   End Sub

then changed the [event procedure] references in the control properties.

Instead of creating a new event procedure, I just [red]edited[/red] the declaration to

    Private Sub Foobar_Dirty(...)

Wrong. Indeed, as stated earlier, some of the event calls have different passed argument arrangements, and my change method confused me and the compiler.

I salvaged the code, deleted all the events and recreated the form. Problem resolved.

[Red]Bonus:[/red] gave me a chance to create a more rational/logical approach to the user's interaction. (Probably wouldn't have bothered if my first shot sorta' worked)

[red]Lesson learned:[/red] apparently there's more hiding behind that proc declaration than a simple text file. (Most of my recent work has been in Python, which is all text)

[green]Etiquette:[/green] Not sure if this follow up is an appropriate use of bandwith, apologies if not.

Thanks for the help.


Keywords:
"The expression ... you entered as the event property setting produced the following error: Procedure declaration does not match description of event or procedure having the same name."