Well, if you need the same behaviour as the wizbtns have, there's a lot to redo or copy over. One thing you could do is cyop the VFP classes int your project folder and redo the form navbar with the local copy. Then you can start changing code. But that's patchwork, fiddling with something even I don't know fully.
It's easy enough to start designing based on a container base class.
In the project manager change to the classes tab, click on New... In the New Class dialog enter "mynavbar" as the new class name (whatever you like), choose based on "container" and store In a new vcx file you put into a subdirectory "libs" of your project folder, which you can create, when clicking on the ... button beside the "Store In" textbox.
Now you're in a designer with the container as your visual design canvas. You can put anything on it, of course mainly a number of buttons, and double click on them to get into methods editor and write your code, mainly in the button click events, of course. You can use the graphics in the ffc home folder, they are among the things you are allowed to redistribute, but you may start with texts in the button captions.
What you need for he buttons mainly is just a simple command:
first: GO TOP
prev: SKIP -1
next: SKIP 1
last: GO BOTTOM
add: APPEND BLANK
delete: DELETE
edit: Thisform.setall("Enabled",.t.)
save: Tableupdate() and thisform.setall("Enabled",.f.)
exit: Thisform.release()
This is giving you some idea of what each button mainly does, it's not much needed, is it? Unfortunately the reality is a bit more complicated. One problem is, you can't be sure, the table you work on is the active one, so in almost all cases you need to add a SELECT of the correct table or add an IN clause (to GO, SKIP, DELETE, APPEND) or use the alias parameter (eg of Tableupdate). Another problem is skip -1 at top or skip 1 at bottom of a table will lead to an error, so you need to look out for BOF() and EOF() and either disable prev button at BOF() and next button at EOF() or test that before skipping. Also setting ALL controls disabled of course also disables all navbar buttons. That's why the wizard classes have a dedicated method to set the buttons enabled/disabled based on editmode and other conditions. The main idea isn't bad, you'll need it, too. But you don't need all the stuff you find in the wizbtn class, this is really an overdose of complicated checks in many cases.
It's harder to do a navbuttons bar working with any form, no matter how it's designed in detail, but it's possible. As a start you give the main container class some properties, eg editmode, as the wizbtns have, and an alias property to store the table or view name the navbuttons should work on.
Once you've got all or part of the code you need, save the class, then open the form, remove the wizbtns (if you can't, put RETURN .F. in the parent container class INIT() event, so at runtime these buttons are removed) and add your own navbuttons container to the form.
A completely different idea would be to make at least half of your form a grid and simply let the user scroll through a list of records, with the most important columns showing the main record fields. Then add normal textboxes etc to the other half of the form. You then neither need first, prev, next, and last buttons, because it's much easier to scroll in the overview list and pick a record to see details in the other part of the form.
You also don't need to change between edit and read mode, if users usually are allowed to edit, it's much more convenient all controls are enabled from the start and don't change their state.
Just some ideas.
Bye, Olaf.
