>>Hi all
>>
>>If I'm not mistaken it was determined that code generators were a bad practice. I mean we don't generate SPRs anymore because the SCX is an object.
>>
>>However, given that the menu generator still exists, when one generates a menu - isn't it a fact that manually altering the resulting MPR is *really* bad practice? This must be true or there would not need to be a GENMENUX pre/post processor.
>>
>>I believe it is also true because if you change the MPR, you will lose those changes should you go back to the menu designer.
>>
>>The designer is supposed to speed and simplify laying out the menu - to a lesser degree than the screen designer.
>>
>>Now if that is true, why is anyone making generators at all? Is it just assumed that no one will alter the resulting code?
>
>I was reading you guys for three days now and finally I think it's time I jumped in, if you don't mind :).

Please do! :)

>
>The generators are there to do the grunt work. If the code has a lot of (meta)data in it, tiresome syntax and generally is a nuissance to write, it's about time to write a generator.

Perhaps. OOP can address much of that.

>
>GenScrn(x) was a good example for that. Is there anyone sane who would write all the coordinates in the say/get commands manually? Any redesign of a form, ahem, screen as it was called then (and we called it "mask", don't ask me why - nobody knows) would be a collonel PITA.
>
>My then framework consisted largely of generators. I had a bunch of those. Most of them were of the write-only type; sometimes they'd analyze the generated text and reintegrate the changes into the metadata, such a generator was (1) a general-lieutenant PITA to write, and therefore (2) used only for transition across versions.
>
>So yes, there was a house rule "don't edit this type of file, it will be overwritten". Even such a comment would be sometimes in the generated source.

Good!

>
>Sometimes the boys would insist on entering some changes in the generated code, mainly to introduce a feature which the generator wasn't capable of. That would happen maybe once or twice per feature - and then I'd enhance the generator to include the feature.
>
>Nowadays, most of this stuff is obsolete - and what generators I still use (and write occasionally) are Intellisense scripts which make my life easier, or write the initial versions of things which I'll edit later. IOW, they just write the default version of code, and I don't run them again. That's like the difference between wizards and builders - these are more like wizards.

Obsolete is true! I'm not sure I can call Intellisense or my SnippetFactory a code generator. Maybe generating an big components / entire systems might be considered a code-generator bad practice as it begs for post-generation mods.

Without suggesting you do this, relying on Intellisense possibly too much instead of good object / UDF design seems bad to me. With Intellisense embedding code snippets, should a problem be discovered in that, one would have to go through much code to repair that problem.

>
>>Here's the quandry. If someone did alter an SPR significantly - apparently because they didn't know enough about the screen builder or GENSCRNX would you take the manual changes and plug them into the screen builder so further work could proceed or make more manual changes - knowing how hard they will be to do in a really complex screen?
>
>Definitely the first. These changes can be in two places: visual stuff or code. Visual stuff better not be done in code anyway; and in any generator worth its name, there should be a place for any snippet/method/whatever that may be needed. So I'd just reconstruct the visual changes in appropriate visual editor, and put the code into the metadata's memos. If there wasn't a proper place for a given snippet, extended the generator.

Good. That's what I thought.

>
>Though, it's a bit tough - I never really trusted a generator I didn't write myself :). So the question is "how does any of these apply to the case when you don't have the guy who can tweak the generator?".

Get GenScrnX and add a plug-in? It's almost unfortunate that MODIFY SCREEN in VFP didn't leave the screens unconverted. If I MODIFY FORM oldscreen I should get a warning to run the converter.

However using FPW26 I can modify the screen, generate and run the system in VFP.