At 08:13 2019-01-06, juergen@wondzinski.de wrote:
I want to create my own grid
WHY, just WHY?
Because the VFP grid does not work.
Haven't yet found a problem for which I would need a homegrown grid. What can't you do in VFP's native grid, in combination with the excellent container hierarchy which you could add into any / every column of a grid?
Full validation of a row.
I came close, but it required a lot of kludges and an innocent change in one place could blow it up.
Build a set of controls, save them as class, add that class to the Column, change Column.CurrentControl to point to that class, set Column.Sparse to .F. and presto, you can do any complicated setup and stil have the benefits of VFP's native gridspeed.
I wish.
One of the things that Grid is supposedly not for is data entry. I need a grid that can handle that.
Sincerely,
Gene Wirchenko
Hi Gene,
About this:
"One of the things that Grid is supposedly not for is data
entry"
I don't agree. 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.
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 - 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 - 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) - More things you may ancounter
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?
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?
Best Regards!
El lun., 7 ene. 2019 a las 6:20, Gene Wirchenko (genew@telus.net) escribió:
At 08:13 2019-01-06, juergen@wondzinski.de wrote:
I want to create my own grid
WHY, just WHY?
Because the VFP grid does not work.Haven't yet found a problem for which I would need a homegrown grid. What can't you do in VFP's native grid, in combination with the excellent container hierarchy which you could add into any / every column of a grid?
Full validation of a row. I came close, but it required a lot of kludges and an innocentchange in one place could blow it up.
Build a set of controls, save them as class, add that class to the Column, change Column.CurrentControl to point to that class, set Column.Sparse to .F. and presto, you can do any complicated setup and stil have the
benefits
of VFP's native gridspeed.
I wish. One of the things that Grid is supposedly not for is dataentry. I need a grid that can handle that.
Sincerely,
Gene Wirchenko
[excessive quoting removed by server]
Gene The native VFP grid can handle datahandling perfectly. Please explain why you differ on opinion Koen
Op ma 7 jan. 2019 om 12:19 schreef Fernando D. Bozzo fdbozzo@gmail.com
Hi Gene,
About this:
"One of the things that Grid is supposedly not for is data
entry"
I don't agree. 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.
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
- 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
- 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)
- More things you may ancounter
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?
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?
Best Regards!
El lun., 7 ene. 2019 a las 6:20, Gene Wirchenko (genew@telus.net) escribió:
At 08:13 2019-01-06, juergen@wondzinski.de wrote:
I want to create my own grid
WHY, just WHY?
Because the VFP grid does not work.Haven't yet found a problem for which I would need a homegrown grid. What can't you do in VFP's native grid, in combination with the
excellent
container hierarchy which you could add into any / every column of a
grid?
Full validation of a row. I came close, but it required a lot of kludges and an innocentchange in one place could blow it up.
Build a set of controls, save them as class, add that class to the
Column,
change Column.CurrentControl to point to that class, set Column.Sparse
to
.F. and presto, you can do any complicated setup and stil have the
benefits
of VFP's native gridspeed.
I wish. One of the things that Grid is supposedly not for is dataentry. I need a grid that can handle that.
Sincerely,
Gene Wirchenko
[excessive quoting removed by server]
Been watching this thread and decided to pipe in - I have to observe that I have done some pretty tricky stuff with the VFP grid. Granted some not so straight forward but subclass columns and headers etc. and you can go for broke. Not found anything that can’t be done with the VFP grid. Not to say it can do everything but I'm yet to find what that is. Spend a bit of time (a few hours) and enlightened you will be.
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Koen Piller Sent: Monday, 7 January 2019 11:44 PM To: profoxtech@leafe.com Subject: Re: AW: Custom Scrollbar
Gene The native VFP grid can handle datahandling perfectly. Please explain why you differ on opinion Koen
Op ma 7 jan. 2019 om 12:19 schreef Fernando D. Bozzo fdbozzo@gmail.com
Hi Gene,
About this:
"One of the things that Grid is supposedly not for is data
entry"
I don't agree. 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.
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
- 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
- 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)
- More things you may ancounter
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?
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?
Best Regards!
El lun., 7 ene. 2019 a las 6:20, Gene Wirchenko (genew@telus.net) escribió:
At 08:13 2019-01-06, juergen@wondzinski.de wrote:
I want to create my own grid
WHY, just WHY?
Because the VFP grid does not work.Haven't yet found a problem for which I would need a homegrown grid. What can't you do in VFP's native grid, in combination with the
excellent
container hierarchy which you could add into any / every column of a
grid?
Full validation of a row. I came close, but it required a lot of kludges and an innocentchange in one place could blow it up.
Build a set of controls, save them as class, add that class to the
Column,
change Column.CurrentControl to point to that class, set Column.Sparse
to
.F. and presto, you can do any complicated setup and stil have the
benefits
of VFP's native gridspeed.
I wish. One of the things that Grid is supposedly not for is dataentry. I need a grid that can handle that.
Sincerely,
Gene Wirchenko
[excessive quoting removed by server]
Gene, correct me if I'm wrong, but as far back as this list goes, I remember you talking about your own VFP grid replacement, honestly as far back as 15+ years ago. Am I right?
On 2019-01-07 00:20, Gene Wirchenko wrote:
At 08:13 2019-01-06, juergen@wondzinski.de wrote:
I want to create my own grid
WHY, just WHY?
Because the VFP grid does not work.Haven't yet found a problem for which I would need a homegrown grid. What can't you do in VFP's native grid, in combination with the excellent container hierarchy which you could add into any / every column of a grid?
Full validation of a row. I came close, but it required a lot of kludges and an innocentchange in one place could blow it up.
Build a set of controls, save them as class, add that class to the Column, change Column.CurrentControl to point to that class, set Column.Sparse to .F. and presto, you can do any complicated setup and stil have the benefits of VFP's native gridspeed.
I wish. One of the things that Grid is supposedly not for is data entry.I need a grid that can handle that.
Sincerely,
Gene Wirchenko