strategy suggestion?

[Judi201]

Hi!

This is a once/twice a year procedure in VFP 6.0
I am using SELECT to verify balances on invoices and present any orphans (for whatever reason) to users to decide what needs to be done. Now I am presenting either a browse window or a report (user choice) so user can go to edit screen to fix problems. I just can't be satisfied with this because the user is sitting there looking at the file but I don't know how to present it for editing.

A while back, someone here told me to leave views alone and get familiar with cursors first and I think that was good advice because I have been amazed at what I can to with them.
But I am wondering if it is time for me to explore views for, as I understand it, they can update the table for me.

I would appreciate any suggestions on how to approach this as well as any cautions. Would you suggest a view for this ?
It was all new once, right?? But I am really asking for suggestions for 'best' way to do this, knowing that there are many ways.

Thanks for any thoughts.

Judi

 

[Mike Lewis]

Judi,

It looks like you've got two separate issues here: (i) the choice between views and cursor; and (ii) the user interface issues concerning browse windows.

Re (i), local views make sense. The main point is that you can update the view, and those updates will go straight to the underlying table (subject to buffering, of course).

As far as the UI is concerend, I'm disinclined to use a browse window in my applications -- probably because I always have a tough time making them behave. I would favour a form with a grid. You can use either a table, view or cursor as the data source for the grid.

But I wouldn't let the user edit the grid directly. Make the grid read-only, and fix it so that they have to double-click on a record in order to edit it. This would open a (modal) form, where they just edit the one record -- the one they double-clicked on.

In that scenario, I would use a cursor to populate the grid, but have the modal form edit the underlying table directly. The double-click event would launch the form, and pass the record ID of the selected record as a parameter.

However, that's just my personal preference. Ultimately, you've got to use a solution you're comfortable with.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[Judi201]

Hi, Mike!

I know that you don't remember, because you help so many people every day, but you are the one that gave me general directions that helped me get started including forgetting views for now and focusing on cursors. I appreciate all of the guidance you gave when I was first coming to this forum.

Your answer makes perfect sense and helps me distinguish between the issues. I have used 2 grids in similiar scenarios several times but always on the same form. Just didn't come to me to call a form to edit. I will play with this and see.

Thanks for your suggestions.

Judi

 

[Judi201]

Mike (Y)

A cursor can be made to update the tables. Ultimately you've got to use a solution that means you don't have to rely on lesser solutions

Would you elaborate. Which would be lesser solutions? I want 'best' not 'lesser' solutions. <vbg>.

Judi

 

[Judi201]

Mike,

Thank you so much for that reply for I had taken your response to mean something altogether different. I thought it was a poke at me for hesitating to use views and am relieved to see that I was wrong.
I am considering displaying 2 grids on the form that creates the 'errors' cursor. The first one will be readonly displaying the cursor holding records that need to be examined and deleted,changed,etc and the second one will show the several(2or3 most likely) entries relating to that ticket.
I will be editing in a grid as opposed to a browse window.

I would really appreciate a comment on that strategy.

Mike Lewis, am I correct in thinking that you were suggesting a form with textboxes and labels for editing? I am still considering that as a possibility.

I realize that I failed to make clear in my original post that the user would have to look at several entries (always at least 2 the charge and the payment) to determine the problem so I am thinking showing one under the other would be best. There are only 5 fields to show, so they will be completely visible in the grid.

Thanks for all thoughts.

Judi

I

 

[Mike Lewis]

Judi,

am I correct in thinking that you were suggesting a form with textboxes and labels for editing?

Yes, that's right. I generally avoid the user editing directly in the grid. I've watched them do it, and they are often find it awkward and confusing. I had in mind a form with text boxes, etc, which would let them edit just a single record.

That doesn't mean I don't use grids. They're fine for navigation, record selection and getting an overview of the records.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[Judi201]

Tnanks Mike,

If I may ask one more question on this, knowing that there are several records to be taken together would you suggest showing all entries in the first grid and calling a form to edit one or more from there? I really appreciate your time and suggestions.

I have not used a grid to edit anywhere else, so I guess since this is a once a year thing, I was getting lazy.

 

[Mike Lewis]

Judi,

If the records being edited logically "belong together", then my idea of letting the user edit one at a time might not be such a good plan.

It might be better to put the text boxes, etc (for editing a single record) alongside the grid. As the user navigates the grid, the textboxes would show the data from the highlighted record. The user would edit these textboxes.

If you do go for that sort of idea, be sure not to commit each record's edits as the user moves the highlight. In other words, use table buffering rather than row buffering. You want to let the user save or revert all the related edits in one go.

I hope this makes sense. It's difficult to know for sure what the best approach is without actually seeing it on the screen.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[Judi201]

Mike,

Thanks, that sounds very 'doable' to me. I have always used table buffering and only allowed the user to 'Save' or 'Cancel' on the entire edit, so that will be consistent. That was also a suggestion of yours to get me started and it fits my way of thinking. I think I can do a pleasant design that way and not need the extra form.

So, thanks for that and I have my plan.

Judi