[21:00] {Evan Delay} The Wednesday Night Lectures is a weekly series of chats on topics of interest to VFP developers. The log for tonight log will be posted from a link off of http://fox.wikis.com/wc.dll?Wiki~WednesdayNightLectures Thanks to Cindy for editing and posting these each week.

[21:00] {Evan Delay} John is also a MicrosoftVisual FoxPro Most ValuableP rofessional and a lead Technical Contributor for both the Distributed and Desktop VFP MS MCP exams. And, as of March 27, 2000 an MCSD. Owner of digital elite services. He also worked on both SQL Server 2000 exams

[21:01] {JohnKoziol} As some of you may know I spent a lot of time last year taking apart the FRX file, the main report metadata file

[21:01] {JohnKoziol} There were two results of that research: FRX2Word and an August 2000 Fox Talk article

[21:02] {JohnKoziol} Apparently, with VFP7, the FRX is not changing

[21:02] {JohnKoziol} It still will be used the same and interpreted the same

[21:02] {JohnKoziol} So when Evan asked if I wanted to do a topic, I thought it might be interesting to discuss the FRX since it will still be around when 7 ships

[21:03] {JohnKoziol} There are two main areas of concern when studying the way the FRX works and is put together: 1) The physical structure and what is stored where and 2) how ther values stored are used

[21:03] {JohnKoziol} I'd like to start by going over the physical structure a bit

[21:04] {JohnKoziol} The record layout for an FRX file is comprised of the following fields (and values):

[21:04] {JohnKoziol} 1) PLATFORM C(8) -- Always contains WINDOWS. This is a holdover from when Fox ran on multiple platforms

[21:05] {JohnKoziol} 3) TIMESTAMP N(10,0) -- Timestamp for the last time the record was changed

[21:06] {DenisChasse} Is it too soon to ask a question?

[21:06] {JohnKoziol} 4) OBJTYPE N(2,0) - The type of report object that the current record is describing. Examples would be 7 for Shape, 23 for font object, 8 for field, etc.

[21:06] {JohnKoziol} No, Denis, ask away!

[21:06] {DenisChasse} Why a TIMESTAMP?

[21:07] {JohnKoziol} I would speculate that this is used for compile decisons (SET DEVELOPMENT). The value seems to be mainly the same for all records in the same FRX

[21:08] {JohnKoziol} Back to the list.....

[21:08] {CarlKarsten} how about a hold over from the multiplatform transporter days?

[21:08] {JohnKoziol} 5) OBJCODE N(3,0) -- Sort of a subtype depending on what the OBJTYPE is.

[21:08] {JohnKoziol} Could be, Carl....

[21:08] {CarlKarsten} (never midn that - it is what came to mind, but I don';t know why)

[21:10] {JohnKoziol} 6) NAME M -- Contains the variable name for variables, contains the type of object described if the dataenvironment or a DE object

[21:11] {JohnKoziol} 7) EXPR M -- For the report definition record (objtype=1) contains printer driver and setup information. For group headers, contains the group expr. For labels contains caption. For report vars, contains value to store. For DE and DE objects, contains properties and values

[21:11] {JohnKoziol} (I'm not going to list all of the fields, just the important ones)

[21:12] {JohnKoziol} VPOS N(9,0) -- Contains the number of columns in the report def record, for report objects, the vertical position. For fonts, character height in pixels

[21:13] {JohnKoziol} HPOS N(9,0) -- Left margin in report def record. For fonts, avg. character width in pixels. For report objects, relative horizontal position (relative to band the obj is in)

[21:23] {JohnKoziol} For report objects the 4 coordinates are used as follows:

[21:23] {JohnKoziol} VPOS = Absolute measurement of the object with the value of the graphical separator bands in the Report Desinger added in (!)

[21:24] {JohnKoziol} HPOS = Leftmost position of the object relative to the left margin of the current column

[21:24] {JohnKoziol} HEIGHT = Height of the object in FRU; WIDTH = Width of the object in FRU

[21:25] {JohnKoziol} Now here comes another number into the equation.

[21:25] {JohnKoziol} As I mentioned the VPOS value factors in the graphical separators between the bands in the Report Desinger, so you have to subtract those out to get a good relative placement value

[21:26] {CarlKarsten} to similivry that: VPOS is the placement you see in the GUI report tool

[21:26] {JohnKoziol} What are the graphical band heights? With inches, the FRU height is 1979.16666666, with cm it's 502.7083333

[21:26] {JohnKoziol} Carl: Yes

[21:26] {JohnKoziol} Thanks for the clarification

[21:27] {CarlKarsten} which you have to then do nutty things if you try and use it

[21:27] {JohnStAndria} Why such an odd value?

[21:27] {JohnKoziol} I think that's just the way it works out between pixels and the FRU, John

[21:27] {JohnKoziol} It took me close to forever to nail it down exatcly, I can tell you!

[21:29] {JohnKoziol} So what you have to do to interpret where the report objects are is to determine the starting VPOS for each band and the ending VPOS. Then subtract out the separatoir for each object, then compare the VPOS of the object to the range for each band

[21:29] {DavidStevenson} One more heckler has arrived...

[21:29] {JohnKoziol} Hi Dave...

[21:30] {JohnKoziol} Anyway, the result is that you have to establish the bounds of the bands by one passs though all the band OBJTYPEs and then another pass for each report object to determine actual band and position relative to the band

[21:30] {JohnKoziol} Any questions?

[21:30] {DenisChasse} n

[21:31] {Evan Delay} Just dazzled

[21:31] {JohnStAndria} What can you do with all this info?

[21:31] {JohnKoziol} Sorry -- but it is a heavy topic :-)

[21:31] {JohnKoziol} Well, John, you can do a lot of things. You can take the report apart and lay it out in another application, such as Word or even Visio

[21:31] {CarlKarsten} perhaps a 'simple' example of what you can do

[21:32] {JohnKoziol} You can emulate the repor engine with external output, such as what I did in FRX2Word

[21:32] {RandyJean} Did anyone mention the \VFP98\Filespec folder. All metadata is documented in there with reports, etc.

[21:32] {JohnKoziol} Randy: Yes...but it's not always right

[21:32] {DenisChasse} About the FRX: Why make something simple when you can make it complicated :-)

[21:32] {CarlKarsten} lol

[21:32] {JohnKoziol} Randy, for example the MS docs say that NAME holds the filename for bitmap objects ... WRONg

[21:33] {JohnKoziol} The STYLE field is also incorrectly documented

[21:33] {JohnKoziol} TAG field as well...

[21:33] {DenisChasse} ROFL

[21:33] {JohnKoziol} ....shall I go on? :-)

[21:33] {JohnStAndria} yes

[21:33] {RandyJean} No! I get the idea {g}

[21:33] {JohnStAndria} oops - no

[21:34] {JohnKoziol} I wasn't trying to be facetious....I could list more errors is what I meant :-)

[21:34] {Evan Delay} Yes

[21:34] {JohnKoziol} The RESOID field. What the hell is it?? I dunno...not documented and I never figured it out

[21:34] {CarlKarsten} may I drop in my simple example?

[21:35] {JohnKoziol} Sure thing!

[21:35] {CarlKarsten} if you waned to know what all the fields were that a report used

[21:35] {CarlKarsten} you could click on e3ach objec in the GUI and write it down

[21:35] {CarlKarsten} or suck them from the FRX

[21:36] {CarlKarsten} I have a few more, but now you know that there are things that you can do t hat are not a major undertaking

[21:37] {CarlKarsten} Ill dig them up and drop them on the wiki later. (the end)