onCurrent doesn't seem to fire

[Devin]

Hi,
I'm trying to set up a form so that a certain element of the form
changes depending on the data that was loaded. When I click the
ellipses beside "On Current" it pops up vba and places the cursor at
this code:

Private Sub Form_Current()
MsgBox ("HI")
End Sub

The message box is obviously just a test. Once that works I can take
on the real task.

Suggestions?

 

[Clif McIrvin]

Hi,
I'm trying to set up a form so that a certain element of the form
changes depending on the data that was loaded. When I click the
ellipses beside "On Current" it pops up vba and places the cursor at
this code:

Private Sub Form_Current()
MsgBox ("HI")
End Sub

The message box is obviously just a test. Once that works I can take
on the real task.

Suggestions?

Is this a bound form? I seem to recall that unbound forms never get a
current event.

 

[Devin]

Is this a bound form? I seem to recall that unbound forms never get a
current event.

How can I be certain that it is bound? I can see that form items say
"Unbound" in them if they haven't been configured yet.

Thanks

 

[Clif McIrvin]

How can I be certain that it is bound? I can see that form items say
"Unbound" in them if they haven't been configured yet.

Thanks


In Access 2003 Form Design: On the menu bar select View. The "Field
List" option will be greyed out (Unavailable) in an unbound form.

Or, check the Form's (not control) property sheet Data tab Recordsource
property. If it's empty, you have an unbound form.

 

[a a r o n . k e m p f]

If I were you, I'd make sure that the database is executed from a
trusted location.

That is the probelm with keeping all your logic in VB (like these guys
in this group insist that you do) is that when VB is disabled, you
can't trust the data.

With SQL Server, you can keep the logic in a stored procedure-- or a
trigger-- so that no matter what happens-- any application that edits
a record in tableX, SQL Server can automatically run logic..

This is just vastly superior to anything available in Jet-- in other
words-- it can be used in any other application

 

[Devin]

If I were you, I'd make sure that the database is executed from a
trusted location.

That is the probelm with keeping all your logic in VB (like these guys
in this group insist that you do) is that when VB is disabled, you
can't trust the data.

With SQL Server, you can keep the logic in a stored procedure-- or a
trigger-- so that no matter what happens-- any application that edits
a record in tableX, SQL Server can automatically run logic..

This is just vastly superior to anything available in Jet-- in other
words-- it can be used in any other application

That definitely fixed the problem. I should have known.

I would prefer it to be server based, but from the perspective of the
person I am doing this for that is adding far too much overhead.

Thanks!

 

[Devin]

If I were you, I'd make sure that the database is executed from a
trusted location.

That is the probelm with keeping all your logic in VB (like these guys
in this group insist that you do) is that when VB is disabled, you
can't trust the data.

With SQL Server, you can keep the logic in a stored procedure-- or a
trigger-- so that no matter what happens-- any application that edits
a record in tableX, SQL Server can automatically run logic..

This is just vastly superior to anything available in Jet-- in other
words-- it can be used in any other application

That definitely fixed the problem. I should have known.

I would prefer it to be server based, but from the perspective of the
person I am doing this for that is adding far too much overhead.

Thanks!