Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
VFP+Excel chaingang
Message
De
20/02/2012 16:36:00
Dragan Nedeljkovich (En ligne)
Now officially retired
Zrenjanin, Serbia
 
 
Information générale
Forum:
Visual FoxPro
Catégorie:
COM/DCOM et OLE Automation
Versions des environnements
Visual FoxPro:
VFP 9 SP1
OS:
Windows XP SP2
Divers
Thread ID:
01535820
Message ID:
01535902
Vues:
49
This message has been marked as a message which has helped to the initial question of the thread.
>>If the function is an excel function, why not simply put the expression in the .formula property of the cell? If, OTOH, it's a VFP function, why not just store the result?
>>
>>The elegance of the answer would depend a lot on the circumstances - like, is this a sheet you are generating from Fox periodically, or is it a permanent sheet that you update from Fox, and in the latter case, whether the numbers in it all come from Fox or from other sources too (like manual entry or being created/updated by other software).
>
>Hello , Dragan
>My main desire is to achieve flexibility. Accountants are prone to changing their reports. If i store the results from the app directly into cells then every time a report (xls) changes i will have to rewrite the VFP code. If , on the other hand, i store in a comment a VFP expression that the app just evaluates, then what i have to do is to supply a new xls which tells the app what to do and i don't have to rewrite the code.

You're trying to store your metadata (formulas) in an Excel sheet? In a comment field that you don't see until you hover your mouse over it (but then so can the users see it) and can't touch unless you rightclick the cell (but then so can the users - or you'll have to write some serious VBA code to stop them)? What happens when your code-in-excel-comment requires something you haven't foreseen? You'll have to write more code again in your main app to provide it. Code is code is code, and your attempt to answer The Question Of OOP ("where does the code go?") is among the more complicated ones.

Why not keep your metadata in a table - scripts and formulas and whatnot? Just three fields - (row I, col I, formula M) would be a start. If the coordinates of your formulas are variable, well, then, store their address (name of a named range, or the code which calculates the location) in a location memo.

That way you don't have to rebuild your app - but...what Scott said - I concur. You keep your code in memo fields, in a separate file. But then, a .prg is also a file, and far more readable than that in memo fields (and you get the syntax checking, intellisense etc), and, besides, rebuilding an app isn't such a big deal nowadays. It's just a few seconds. I know my machine creates a 22M exe in about six seconds or less.

IOW,
- yes it can be done your way but I expect it to become complicated and/or potentially unstable
- yes it doesn't have to be inside the app; there are ways (metadata tables, separate out-of-exe .prg files, even prg files generated and compiled from metadata on the spot - I do that sometimes)
- still, no convincing reason why not to keep it inside the app.

back to same old

the first online autobiography, unfinished by design
What, me reckless? I'm full of recks!
Balkans, eh? Count them.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform