NEXT RECORD event (Access97SR2)

Topic

New Reply

Is it possible to trap or disable the buttons at the lower left corner of a Form?

I see a go to first, “go back one”, “type a number”, “Go forward one” and “go to last” (and another that is a mystery to me).

I fancy writing code that detects the click event on each of these buttons. In particular if my user (me!) has clicked “goto next” without making a change to the follow-up date of the client record, I want to pop up a reminder ‘Hey, you didn’t change the follow up date” and take appropriate action.

I can’t see anything in the help files that says the buttons can be hidden or disabled (in which case I’d be forced to use my own command buttons).

Reply | Quote

Replies

Hi Chris…

I think I could actually help with this one , IF I understood more about this form you’re referring to…

I’m assuming from what you said, that the database was created by someone other than yourself?… Are you even able to get into Design mode for the form?

Command buttons don’t do anything unless you tell them to… If you put one on a form and didn’t add any event procedures (or macros), you could click to your heart’s content and nothing would happen… There is code there (or macros) for the click event one of those buttons (if they do anything)…. but we need to know if you have editing capabilities on that database first…

Reply | Quote

(blush) I didn’t expect my ignorance to be that evident (grin).

I designed the database and the form. (I’m calling it “design” to keep the forum clean!)

My Forms work fine – I have command buttons that are hooked up to lirttle VBA procedures that do their thing, such as a button that adds 31 days to the “FollowUpDate”.

Now, when the form is excuting and working just fine, down on what I think is the Access97 status bar, extreme lower-left corner of the window, are the five or six buttons I referred to earlier. I believe that they are “owned” by Access. You’ll see them too if you have opened a Table to browse it. They are very common and quite standard, and not developed by me.

Those are the buttons whose event I would like to trap (or would like to diable or hide the buttons)

Essentially I don’t want the user to be able to use them at all, unless I can monitor/control their action.

I can get into design mode, and am having more fun than ever I had in the sandpit.

Reply | Quote

Chris ,

In the properties of the form you have a Navigation Buttons property on the format tab. Set it to No to hide the buttons.
If you want to know, the last button is to go to a new record.
I don’t think that you can trigger when these buttons are clicked.

Reply | Quote

> Navigation Buttons property on the format tab

Francois, thank you. I missed this when first I examined the form properties. I didn’t know enough (then) to look for “navigation”!

Reply | Quote

To add on to what Francois said, in addition to hiding the navigation buttons, you can create your own navigation buttons. You can then add your own code to check for your condition.

Create a command button and use the following code:

If 'your condition Then
    DoCmd.GoToRecord acForm, "", acFirst '/acLast/acPrevious/acNewRec/acNext
Else
   Msgbox "Whatever"
End If

You can also assign the pretty navigation icons to your buttons using the browse button to the right of the Picture Property setting on the button’s Property page.

HTH

Reply | Quote

> you can create your own navigation buttons

Mark, thanks. yes, now that I can hide the standard buttons I can go to town wityh my own.

Reply | Quote

Ahhhhh… Thanks… …I got caught taking your wording too literally… …I thought the buttons actually said those words on the face of them… Francois is right… I believe you are going to have to hide the standard navigation buttons and create your own…

You’ll have to add on click event code to the buttons… that will check the record for changes and bring up the message box when necessary…

Reply | Quote

> .I got caught taking your wording too literally.

I do that myself sometimes, with my own words (!).

Now I know to call them “navigation” buttons one last time before they are gone for good!

Reply | Quote

Oops… Mark beat me to it….
Have a great day!

Reply | Quote

You wouldn’t do it that way, Chris. If the record had been changed at all, you could use the BeforeUpdate event of the form to keep them from moving to another record. You could pop up your message there and cancel the update, which would not allow them to move to another record. You could leave the navigation buttons on the form and BeforeUpdate would still fire as long as *something* was changed in the record. So you could do something like this:

Private Sub Form_BeforeUpdate(Cancel As Integer)
  If Me.followupdate = Me.followupdate .OldValue Or IsNull(Me.followupdate ) Then
    Cancel = True
    MsgBox "You forgot to update the  followup date, Chum!"
  End If
End Sub

That would work regardless of which navigation button they clicked.

PS The button you didn’t understand is probably the new record button, which moves to a new empty record.

Reply | Quote

> If the record had been changed at all, you could use the BeforeUpdate event

Thanks Charlotte. I have implemented your code and yes, it works fine (and I learned something else about Access – “.OldValue”!).

I have to think about the condition “If the record had been changed”; if this form is meant to be used to wade through records and make a decision to keep-or-delete then I won’t want the user (me!) to skip forward or backward without hndling the record. The code supplied permits the use of the navigation buttons to avoid dealing with a record, and I was trying to force the user to deal with each record as it arrived on this particular form.

Reply | Quote

Well, BeforeUpdate is only triggered if the record has been changed. Otherwise, you’re stuck with custom navigation buttons because you can’t cancel events like Current, and it happens when the record pointer *moves*, which is what you don’t want. However, if you really want the user to handle every record they see, you can dirty each record in the current event by doing something like setting a datehandled control to null.

On second thought, the current event will fire if they save the current record as well, and you *don’t* want it to null out a control at that point. Oh, well, it gives you something to work on, Chris.

Actually, you could use module level flags to tell the Current event whether to dirty the record or not.

Reply | Quote

I should point out that I’m not a TYRANT to myself, just that on this particular form, it’s easy after chatting with a prospect to forget to update certain fields. Catching these events helps remind me to perform proper housekeeping on each record before moving on to the next. It’s a “deal with each piece of paper as it arrives, and handle it only once” situation.

I now have my navigation buttons removed, and the test for “Followup” on my “Re-Apply Filter” command button, and the Form itself sets the “date last accessed” field, which it ought to anyway, thereby dirtying the record.

Ok. next question: How do I get these prospects to pay me large sums of money for doing very little work? (grin!)

Reply | Quote

[indent]

---

How do I get these prospects to pay me large sums of money for doing very little work?

---

[/indent]According to Robert Ringer (Winning Through Intimidation), you tap into the “expert from afar” syndrome and persuade them that you have all the answers to all their problems, whether you know anything or not. Of course, later on, that kind of “expert” is often replaced (after thoroughly soaking the client) with an underpaid programmer who actually *does* have the expertise claimed by the aforementioned expert and who then has to fix the so-called solutions provided I’ve some some of those cleanup calls myself. Maybe you don’t want to go that route after all.

Reply | Quote