View Full Version : Custom Navigation Buttons


Shep
05-24-2007, 07:06 AM
Hello all,
I've looked at the examples of custom navigation buttons people have created. Some are better than others, but none of them are fully functional, in my opinion.

I like Stephen Leban's technique; manipulating a Parent's .Recordset from a SubForm. My goal is to create a set of instantly reusable custom navigation buttons.

However, even his code lacks Save and Delete buttons.

In studying this problem, I noticed something about the built-in navigation buttons that nobody seems to have addressed, even those who claim their button set mimics "exactly" the built-in buttons. None do.

And that is that when clicking the "New" button (built-in), the New and Next buttons are disabled. This is fine and expected.

Then, when any field on the form is changed (form made Dirty?), the built-in New and Next are instantly enabled.

Does anyone understand how this is being done?

Simon_MT
05-24-2007, 08:42 AM
I used Command Buttons everywhere in my database. I do think I ever used the Wizard that produces the proxy picture. All Openform OpenReport etc are dome from these Buttons.

My advice would be make your own, I don't want to sound arrogant, but this gives you the flexibility to create these Buttons for your own purposes. You may need to borrow some code and if the scripts are held in a Modules they can be used throughout your application..

Simon

Shep
05-24-2007, 08:51 AM
I am making my own, Simon.

In so doing, I want to mimic the functionality of the built-in navigation buttons.

I need to find out how Access is enabling the built-in New button when the user makes the Form Dirty.

Thanks

gemma-the-husky
05-24-2007, 09:06 AM
i think the after insert event occurs when a new record is added, so i would set the button their. look in help for sequence of events

Shep
05-24-2007, 09:31 AM
Thanks gth.

Actually, it's the BeforeInsert event but you've pointed me in the right direction. Much obliged.

gemma-the-husky
05-24-2007, 10:20 AM
it probably dsoesnt matter, but i'm not sure it is the before insert. the before insert will enable you to cancel the insert if you don't like it

so it really should be the after insert, when the new record becomes dirty

---------
also presumably you need to unwind the actions if you cancel the edit with undo

Shep
05-24-2007, 10:37 AM
Yeah, I suspect I'll have to make use of both events to make my custom button set as fully functional as possible, but it is the BeforeInsert event which triggers the actions of the built-in buttons I described above. That's really what I was searching for. :D

I'll probably post the thing if I get it hammered out well enough not to be embarassed by exposing it to the world.

Moniker
05-26-2007, 06:43 AM
It's actually found in the form's After Update event. The After Insert assumes new data was added, but the After Update will catch both a new record and an edit to an existing record.

Shep
05-30-2007, 12:36 PM
Moniker, I have found that On Dirty catches edits, and I don't understand how an AfterUpdate would catch anything until after a record is written. Please clarify if you happen to read this.

Thanks

RoyVidar
05-30-2007, 12:38 PM
It might be version dependent, but I'm not sure whether on dirty catches programmatic changes to the recordsource, so be sure to test that, if it applies to your situation.

boblarson
05-30-2007, 12:42 PM
It might be version dependent, but I'm not sure whether on dirty catches programmatic changes to the recordsource, so be sure to test that, if it applies to your situation.

Due to some problems I had with my own database recently, I believe you are correct Roy about the programmatic changes not firing the On Dirty event.

Shep
05-30-2007, 12:49 PM
Yes, I suppose it is version dependent, as I don't remember seeing the On Dirty Event in 97, which is what I was using previous to 2003.

I really wonder how it was being triggered before On Dirty became available. Or, was it available internally and not exposed to us? Or, was it available to us had we simply created the appropriate Sub? Heck, I don't know.

At any rate, thankfully, I don't need to worry about programmatic changes to the RecordSet, at least for this particular exercise.