Picture buttons question 3

[k2a]

I'm using the picture buttons (picbtns) in one of my form but do not need all function.
Therefore i want to disable all those buttons not being used from the buttonset.

When the cmdAdd is set to Enabled = .F. the add button appears shadowed in the edit mode but running the form the add button gets enabled and can be activated.
What is wrong here?

Regards
Klaus

 

[Olaf Doschke]

The navbar isn't designed for your requirement. The buttonrefresh method inherited from txtbtns is enabling the single buttons depending on editmode. The initvars method is enabling the cmdAdd based on !ISREADONLY(), so any writable recordsource leads to an enabled Add button.

You can't easily modify the nav button bar without interfereing, for example deleting buttons will lead to runtime errors because of missiing buttons. Either you try with visible insterad of enabled, as I don't see that being changed by class code, or you change class code (which I wouldn't recommend because of side effects on other projects also using the FFC and wizard classes), or roll your own set of buttons.

Bye, Olaf.

 

[Mike Lewis]

This is an excellent argument against using the wizard-style buttons supplied with VFP. They are notoriously difficult to modify, even for minor adjustments.

It's really not at all difficult to create your own edit / navigatition buttons. If you do, you will be able to fine-tune them in exactly the way you want. Creating your own is also a good general exercise in creating classes. I'd suggest you go for that approach.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[EzLogic]

I agree with mike, i never use native classes from VFP.

Always try to make your own classes and then you can sub class them.

Ali Koumaiha
TeknoSoft Inc.
Michigan

 

[Olaf Doschke]

Well, self made clases also are not a gurantue you can easily modify them to new requirements.
That needs very good design and forseeing of new requirements. But usually it's much easier to extend a self made class, of course.

One way to make the add button disabled obviously is opening the table your form should only read and not modify with NOUPDATE clause of the USE command or set the Readonly property in the properties of the object in the dataenvironment, table or view.

If you intend to only restrict the user only, but not your code, that won't help much, as that readonly state then is effecting both the user and you. If you only intend to suppress adding new records again you're bad off, because a readonly status of the table would also lead to disabling editng exisitng records.

A fix without changing class code would be to bindevent() to the cmdAdd.enabled property and change it back to .F., anytime anything is changing it to .T. ; It's a cludge, I'd rather set the button visible = .f. and see if that works out before trying that.

Bye, Olaf.

 

[k2a]

Thank you all for your quick answers, without your help i would be totally lost.

Knowing now the cause of that behavior and your advice against using the native VFP class in that case opens the question for an optimal solution. I must admit that my knowledge about class design wasted away and the application i am working on right now lives from those classes i developed in my younger ages.

One quick and ugly solution came to my mind to convert those unused buttons (picbtns) into no-operation button but this is not a user friendly option. On the other hand i would prefer to have my own buttonset that I understand.

I would appreciate if you could give me some inputs.

Regards
Klaus

 

[Olaf Doschke]

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.

 

[k2a]

Thank you Olaf for your greate help.
I think i got it now.

Regards
Klaus