At 03:18 2019-01-07, "Fernando D. Bozzo" <fdbozzo(a)gmail.com> wrote:
>Hi Gene, About this: >"One of the things that Grid is supposedly not
>for is data entry"
> I don't agree.
Neither do I, but I have seen this opinion posted many times
over the years. I do not understand it myself, but there it is.
> Not sure about the complexity of what you need to do, but if you
> used FoxPro before VFP, you could remember that before the grid
> component was the BROWSE command with many parameters that allowed
> many validations and options for row/column, and that many
> validations and options where made exactly for that purpose, for
> data entry. Most of them have no sense for other purpose than data entry.
Yes, but I had a period of time where I was not using
xBASE. That was about when the fancy browses had their day. I have
looked at BROWSE, and it does not have quite what I want.
> One of my first programming challenges was to do a component
> exactly as you need it to (I'm talking about dBase III+ era), and
> could do it, but the problem was that performed horribly, too slow
> to navigate records and columns. I think that you could face the
> same problem. Do not forget that you have to control each and every
> aspect of the component, as: - Scrolling left/right controlling
> start and end columns
I have this scrolling already working in a concept case. It
was fairly easy. I grant that this may change when I add more
feature. I do not think so though.
> - Scrolling top/bottom controlling start and end rows -
> Controlling the data you load/unload, because you can't load a
> millon records in memory, and this forces you to control
> dinamically the loading of a new bunch of records in the direction
> you are navigating, and unloading records from the other side -
Yup! It is going to be fun, but I have some ideas.
I am concerned with how the scrollbar works, but I may just
come up with my own version that bypasses the issues.
>Controlling every key for navigation and other needed purposes -
>Controlling the visualization of each aspect of your info (think on
>Autosizing columns, pre-programmed sizes, combination of both,
>assuring that you show columns correctly and fluently ,etc)
I do not plan to have every feature that Grid has, at least for
the start.
I tried to get Grid working when allowing column order to
change, and it was horrible.
> - More things you may ancounter
Quite possibly.
What I have encountered is trouble with row-level
validation. Without that, Grid is NOT what I want.
> Obviously I'm thinking in a component that can be used for any
> table, and not just for one special table, because the programming
> effort to do this type of component is too high to do it for just
> one table. Don't know if you already said this because I didn't
> follow the entire thread, but: What type of validation do you need,
> and what is the problem you are facing that can't be handled with the grid?
I can not get proper row-level validation working
consistently. I have tried and tried and tried. I keep finding
cases where it breaks. I deal with a case, and something else
breaks. It is very frustrating.
I had quite a lot of trouble to get my test case to work. I
had to experiment with events and methods, but once I got it, it
worked and did so consistently.
> And more importantly: Is really a grid what you need? why can't
> you use an input form with navigation keys that scrolls data in background?
Because some of the work that needs to be done needs multiple
rows visible at once.
[snip]
Sincerely,
Gene Wirchenko