>Hi, All!
>
>I have posted this message after Thread #636093.
>
>There are a lot of things collected last time related to VFP grids, and it seems a good idea to organize materials well and write a book with all information collected.
>
>It would be good to know the opinion of you, folks:
>
>- Is it needed to devote the book for VFP grids? The book just for a single control in VFP?

Absolutely not; you're locking yourself into a market of people whose sole tool for development is VFP5-7(8?,9? - who knows how long it will be until we can use common UI elements from .Net as easily as the native grid, and it's only for people writing fat clients. You further limit your audience to people who want to use it as the centerpiece of their 1:M interface.

You further limit your audience to people who would actually read the book. My guess is that 85% of the grid-related questions here on UT are already covered in either the samples and docs that come with VFP or KiloFox. And the real can of worms isn't the grid itself, it's all the other controls you might want to embed in the grid.

I think you'd be addressing the issue better writing a replacement for the VFP Grid Builder - the problem is that there are too many people who're simply too lazy to create custom grid classes because they aren't Visual Classes you can drag and drop to construct your complete interface without having two functioning braincells to rub together.

From a commercial standpoint, a grid builder utility that could be added to any of the common frameworks would be a commercially more viable product. The problem of grids and grid behaviors is as closely tied to the UI philosophy of an app squirted out through an app genrator. If you're capable of adopting a framework and a consistent style or small set of styles of UI behavior based on a grid, you're 95% of the way through grids if your issue isn't "I want to drag and drop and not think about what goes on behind the curtain. " in which case, a book on grids won't help because they ain't gonna read it and make use of it...

BTW, I'm not a Grid fan in case you haven't guessed that yet...

>- Is it a good idea to make a tutorial for the most common use-cases for grid on how to put the grid on form and configure/program it to make it work ok?

Yes - constructing a grid example library would be as useful as something like the API example library. A central reference point - a Grid FAQ on the scope of the original hope for the WinAPI FAQ. The people who'd really gain from a book on grids would get as much from it as the book - more, because people could expand and flesh out the thing as they came up with neat fixes. Maybe a wiki-style collaboration on grids would be a good idea? If I weren't so lazy, I'd take a run over to the wiki to see how much stuff on grids and grid-related controls was out there; it'd certainly give an indication of interest beyond the D&D interface got discussed there.

If, as I suspect, the market is for D&D, not exploring the intricacies of the grid control, which by itself is interesting, you'd see what issues were the hot topics for the crowd who'd buy a book and read it for content as opposed to the people who'd never make it past the TOC.

>- Is it worth to include into the book about VFP grids some source code for advanced grid functionality and also include and describe some control for grid, like Grid Highlighter, Sorting by header click, mover bar for grid, multi-select grid, grid drag dropper, parallel grids scrolling, saving the grid appearance properties into user's profile an many other things?
>

Again, I think a tool to build the more advanced custom grids would be a commercially more viable thing. Realizing that the advanced grid functionality largely exists in the wild and can be gotten pretty easily from places like KilFox and the download section of UT, I think the issue is not that grids are not understood, it's that they aren't dain-bread simple to do the first time. Once you've got a custom header class for sort by click, a highlighter, etc, you've got it forever, if it's actually been obtained by something more than code creebing and the user really understands what they have. If it's just a feature that they use but don't understand, a book isn't going to help them. A tool to put the "advanced grid" in their hands would sell, if it could effectively be marketed and controlled. If it were a commercial project, I'd look at the history of FRX2WORD, which should have generated a little revenue for John K, who, in the brief time it was considered as a commercial product, produced maybe 3-4 people who paid and registered the software, a bunch of people who said "Gee great, this is neat and the best thing since sliced bread, but I wouldn't give you US$50 for it", and a whole lot more who bitched that it didn't work the way they wanted it to and John should make it do (fill in the blank) but certainly went ahead and used it to line their pockets with money billing clients for his work, and a few really decent people who said "Thanks for the great tool. Here are some things I did to make it better, and if you want, make them part of this so everyone gets the benefit!"

So a small group of people would pay for the product, and small group of people would cheerfully work to make it a better tool, and a bunch of people took a free lunch off it, many of whom had the balls to complain about how it worked, all the while billing other people for the sweat of the guys who loved the tool. 99.99% of FRX2WORD users haven't a clue about what goes on underneath (there's a ton of neat knowledge on automation that's right there for everyone interested to learn from. I'm getting cynical as I get old and decrepit...

>Lets discuss this opportunity. Your opinion will determine if this book writing will start.

I'd love to be wrong about this. It's a worthwhile project. I think if making money is the goal, a tool is more likely to succeed than a book, but I think you'll get FRX2WORDed.