Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Code generator bad practices
Message
From
02/05/2006 14:48:46
Mike Yearwood
Toronto, Ontario, Canada
 
 
To
01/05/2006 17:16:02
Al Doman (Online)
M3 Enterprises Inc.
North Vancouver, British Columbia, Canada
General information
Forum:
Visual FoxPro
Category:
Other
Environment versions
Visual FoxPro:
VFP 9 SP1
Miscellaneous
Thread ID:
01118155
Message ID:
01118507
Views:
11
>>One way generators can be bad for the reasons you mentioned. However, some tools have two-way generators. So, for example, if you changed the MPR, the MPX and MPT files would be recreated, and your code changes included.
>>
>>>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?
>>>
>>>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?
>
>There's nothing inherently wrong with code generators. After all, we all use one that is very flexible, but is extremely slow and tends to be buggy. You just have to understand their limitations e.g. the one-way ones that have shipped with various versions of Fox.
>
>Re: why some people would modify Fox2x .SPR/.MPR etc. - years ago I took over maintenance of a FPD2.5 app. The client had contracted to have it built by a 3rd party. The contract stated that the client would receive source code. There was a contract dispute, but that clause was not in dispute, so the 3rd party had to hand over source code. What did they do? They only provided .SPRs/.MPRs, not the .SCX/.MNX etc. The scoundrels used this as a bargaining chip to meet the letter of the contract but still extract further funds from my client. So, I can see some circumstances where modification of .SPRs/.MPRs could happen, because of necessity.

But barring that - it's a bad idea to modify the output?

Here's a work around. The generator for spr reads the scx. If needed, open the SCX and changes the numbers. Regenerate. Repeat.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform