> > Is anyone from the original Fox team still inside or not? Grid sure > looks like a too-many-hardwired-defaults-kludge, not half the way Fox > used to be before. > I share your feeling here. Except for a few nice features, everything that is not FPD2.0 is not at the level of the original non M$ product. I passed from Turbo Pascal to FPD2, purely because I was impressed by the multitude of features it offered. FPW I did not use at all. VFP3.0 got me out of business. VFP5 is OK. At M$ it is obvious that they do not put their best guys in. Guess they cannot afford to drop it altogether, but they'd rather had that Foxpro would not exist. It has mostly to do with profitability. They think they cannot make money by putting an effort into VFP. Face it, your enduser does not pay anything to the M$, they'd rather you let them install SQL server or something they have to pay for. Programming languages are not a market anymore, like in the good old eighties. Guess FPD 2.0 is the last of its kind where the manufacturer could make a buck. If you do not believe me, look at Borland ... > > Inheritance of browse command's _abilities_ is the minimal request I ... the browse reminds me of Wordperfect. It could do everything and the contrary of everything, the challenge was to find out how!. It was the kind of product, that gave you the feeling that they lost the sources of the code:) ... > expected to find answered in the grid (they did advertise it as such, > didn't they say "forget the browse - here's the grid"). I think they > started the whole class with too much ambition, but never gave it any > final touch. Shipping date was always due yesterday, as it seems. > Again, I agree ... And to think that they could have used the cell concept like in VBA for excell ... > > On the other hand you must ask yourself is you _want_ to go OO here. > > Because I went OOP with this in FPD2.6 :) I had a grid-like incremental > search function, which worked on lots of @ says etc, and had a generator > written for it which generated snippets for defining/activating the > window, copying a record into an array row, and displaying an array row > on window in appropriate color. The main engine only called these > snippets (and, eh, the snippets were generated _into_ the .prg which > called the generator :), so whenever I changed something in the engine, > it reflected all the windows, no matter when they were generated. Now I > move to an OOP environment, and can't have my own class for that. > [what's the polite euphemism for "shit"?] > Here there is a nuance. Even if in terms of efficiency of programming there is only a small difference, I make a distinction between program generation and oo's Is_A and Has_A relationships between objects. (Builders and wizzards belong to the program generation type.). It took me a while (if you have time, look at a thread called 'OO, no more than a nice syntaxic enhancement?' of last year here on the UT) but there is no doubt in my mind that OO is a powerful paradigm, because it is applicable to Design and Analysis as well. So even if this sounds as science fiction at this stage, I think we will be 'reusing' elements at the analysis level in the future, which face it, does opens up amazing opportunities. Program generation, how powerful you make it, misses that dimension. > > argue that the grid is at the limit of both. Builders do give you a lot > > of flexibility and efficiency in the development effort, especially > > because more than other controles, they are linked to the tables, and > > since the latter are not objects, (and will they ever be?). > > Fiddling with builders and clicking around is what I want to save my > programmers from. What I meant is, build your own builders that are compatible with your grid base class. The work is in the grid base class. Once you have that, the builder is very easy to write, once you overcome a few typically Foxprolike idiosyncracies. Back in the FPD days, the Browse was the nec plus, if you could handle its quirkness. Most advanced programmers did. The grid only kept the quirkness, but conceptually it is quite different, even if internally, they must be very similar. For data input I have griddoc base class that supports automatic next line, which a feature that to this day I do not understand why it is not standard. They never had to fill out an invoice for christ sake? Mind you this is not a VFP problem, I know no package, not in DOS, not in Windows that supports the next line feature. I had to deploy treasurers of ingenuity to implement it, and it still does not work well! I also prepare xWhen and xValid statments at the grid level that are called by the When/Valid methods of the textboxes in the columns (these are textbox classes that are put as controlsource but the builder). The generate a case statement for each field of the underlying cursor. So I do not need to break my back to go to the textbox valid's method in the outline access (since we _are_ complaining, another 'marvel') for the local validation of the fields. >I strongly need to be able to define defaults, so the > wizard does it all, and some tiny percentage be left to customization > via builder. I will write the wizard, no problem (I'll take my time), > but if it had to set a dozen properties with the same values every time > it adds column, that's lot of unnecesary overhead. Besides, the builder > would have to do the same (any change in wizard would have to be > mirrored in the builder), and if a column was added manually in the > forms designer, it would still have to be worked on because it would > inherit wrong defaults... Having a class... OK, I am boring myself. That you do with builders that you make yourselve. You submit the cursor that will be underlying the grid to the builder, from there you create the columns, set the properties, and 'generate' code. > > > A lot would depend of course on what you are developing. Me, I develop > > customer tailored software, for which I find VFP quite appropriate, so > > OO is not necessarily a priority for me, allthough it surprisingly did > > help a lot. > > Custom tailoring assumes you don't invent sleeves and pockets every time > - you pick existing ones and sew them on :) To clarify the matter, what > I did with generators is the same what I expect of OOP - relieve me from > the physical work, do the 90% of dirty stuff for me, and leave me to do > the 10% nice and easy. > Here again, I do not agree. I think foxpro relieved us from the physical work. But in my line of work, I have to allow for exceptions here, and small adjustments there. I cannot build on strong and exhaustive system requirements, the environments change a lot, and are not defined(able) very precisely. As I said, under these circumstances, VFP is a very flexible tool. But for OO, you need a to build an abstract theory, which you cannot always do. This is why I was surprised that VFP layed so much emphasis on OO. I did not think that it was what the average (here _I_ was egocentric) programmer needed. I changed my mind about this. By building a framework, you can integrate sophistication into your programs, and what is more, each time you enhance the framework, these enhancemants are distributed across the application. Program generation is more discrete (as opposed to continuous) in this respect. > > One more thing, the under average quality of the grid contributes to the > > steepnes of the learning curve, I think we lost a lot of Fox Adherants > > because of it. > > I don't fall into the cathegory. I'm an addict :) And so am I, but they almost lost me for Delphi. If had not been for the sucking database, we would not have been dialoguing so pleasantly.... > > > My 2 BEF (again). About Russian COBOL, amazing no? > >) What? You do not know what a BEF is? 1 Belgian Frank, about 3.5 US cents, 2 BEF is 7 cents, like they say 'my 2 cents, pennies, roubles, dinars of wisdom'. Sure 7 cents is a lot under the circumstances, but then this is Belgium, everything is more expensive! Take care, Marc