Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
ReportListener: it is powerful or not?
Message
 
 
À
28/01/2005 13:10:10
Information générale
Forum:
Visual FoxPro
Catégorie:
Gestionnaire de rapports & Rapports
Versions des environnements
Visual FoxPro:
VFP 9
Divers
Thread ID:
00981650
Message ID:
00984217
Vues:
23
Sorry, Fabio.

The only reason for the LoadReport example was to illustrate the fact that, at this point in the report output processing, the engine does not consider the report run to have begun, and you thus have the opportunity (only at this time) to make physical changes in the report file.

This includes not only swapping out the FRX, as I did in that example, but also using the FRX file and making changes to the table. The latter is a more obvious thing to do -- in fact, it's exactly the way one of the old utilities for reports (GenRepoX) did its work. I swapped the entire table because I thought it was a more dramatic illustration, and also because I think we have better ways of intercepting and altering report behavior for a specific FRX, during a report run, using a Listener, than physically altering the table.

I realize the example wasn't brilliant code, I was just trying to make a point: Load/Unload are different from the rest of the report run, from the engine's POV.

Probably the most important help topic in the docs, for your purposes, is the one titled 'Understanding Visual FoxPro Object-Assisted Reporting'. I hope this answers some of your questions.

The reason why we used nFRXRecno is simple: you have the datasession with the copy of the FRX and we found that the fastest way to go to the appropriate information for a given record -- i ncluding of course the User and Comment fields -- was a GO . We originally worked with the ID values, but it wasn't nearly as good, even with index dynamically added at runtime. Not only was it faster on our side (which we knew) but it was faster for the engine to provide it. The fact that it's a RECNO() is kind of irrelevant, think of it as a hash value for the record you want. Not guaranteed to be the same between report runs, IOW, just a unique value for this processing run.

I would recommend that you look at some XML memberdata options along with User and Comment for additional capabilities in report extensions. This is different from the XML provided by the XMLListener which I've been recommending people pay attention to (the VFP Report XML itself). You'll find our recommendations for XML member data use in Reports in the topic 'Report XML MemberData Extensions'. The code there is (I hope <g>) somewhat more to your taste.

Regards,

>L<
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform