Templates: Access Objects parts
Last week I talked about how the template core data is laid out. Now, I’ll focus on the actual Access objects.
For every Access object part (each file in template\database\objects), there is a corresponding” XML file in the \template\database\objects\properties folder containing it’s properties: type and name. For example:
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
- <AccessObject xmlns="https://schemas.microsoft.com/office/access/2005/04/template/object-metadata">
<Type>Form</Type>
<Name>Add Related Issues</Name>
</AccessObject>
Now, as for the object itself, there are two types of objects: tables and everything else (form, reports, macros and queries). The table objects are XSD files, with the customary .xsd extension.
Since XSD files only define schema, the actual data within these tables are saved in the template/database/objects/sampleData folder, in XML format. There is one XML sample data file for each XSD file in the folder above: both constitute one table.
As for the form, queries, reports and macros, these are simple text files in template\database\objects. These are not XML, XSD or such – they are actually the SaveAsText/LoadFromText persistence format already used elsewhere in Access. For example, here’s what a query looks like:
Operation =1
Option =0
Where ="(((Issues.Status)<>\"Closed\" Or (Issues.Status) Is Null))"
Begin InputTables
Name ="Issues"
End
Begin OutputColumns
Expression ="Issues.*"
End
Begin OrderBy
Expression ="Issues.Status"
Flag =0
Expression ="Issues.Priority"
Flag =0
Expression ="Issues.[Due Date]"
Flag =0
End
dbBoolean "ReturnsRecords" ="-1"
dbInteger "ODBCTimeout" ="60"
dbByte "RecordsetType" ="0"
dbBoolean "OrderByOn" ="0"
dbByte "Orientation" ="0"
dbByte "DefaultView" ="2"
dbBoolean "FilterOnLoad" ="0"
dbBoolean "OrderByOnLoad" ="-1"
dbBinary "GUID" = Begin
0xa26c0cbd84d1be499edb2029597a5e25
End
dbBoolean "TotalsRow" ="0"
dbLongBinary "DOL" = Begin
0x0acc0e5500000000cce68fc558b3bd4a9ab9ec7673e9b5cd00000000ea387df8 ,
0xef00e3400b000000c05f11004900730073007500650073000000000000007c14 ,
0xd0158996884e8e1461b254a168da07000000cce68fc558b3bd4a9ab9ec7673e9 ,
0xb5cd53007400610074007500730000000000000046b553afdd076a40a5be3384 ,
0x98df0bda07000000cce68fc558b3bd4a9ab9ec7673e9b5cd5000720069006f00 ,
0x72006900740079000000000000004a6c0fd2c964584eb9cea65e577d52090700 ,
0x0000cce68fc558b3bd4a9ab9ec7673e9b5cd4400750065002000440061007400 ,
0x6500000000000000000000000000000000000000000000000c00000004000000 ,
0x0000000000000000000000000000
End
Begin
End
Begin
State =0
Left =0
Top =0
Right =776
Bottom =710
Left =-1
Top =-1
Right =760
Bottom =213
Left =0
Top =0
ColumnsShown =539
Begin
Left =48
Top =12
Right =192
Bottom =156
Top =0
Name ="Issues"
Name =""
End
End
As per our previous discussion about the LoadFromText and SaveAsText formats and functions, it is not surprising that tables use a different mechanism, right?
The other folders (“AddFuriganaVariation”, etc) are internal mechanisms we use to be able to generate localizable templates. We need to be able to deal with requirements such as right-to-left content flipping, font replacement depending on locale and others. That’s why we have copies of specific objects in these folders – so we can do specific treatment when necessary.
Comments
- Anonymous
September 05, 2006
I noticed that in a Form's SaveAsText there is a checksum, and if you mess with the resulting text file, say with notepad, it will not load back into an mdb but a query object does not have this restriction. I can see where it would be easy to manipulate the text file and then load an object instead of loading the object and then opening in design mode which you can not do under runtime anyway. Is there anyway to manipulate the results from SaveAsText for a form?
Steve - Anonymous
September 05, 2006
Not really.
The way to do that is to LoadFromText the form, do the necessary modifications and SaveAsText it out. And yes, this doesn't allow you to work around the restriction of not being able to go into design mode in the runtime.
This was meant as a persistence format, not to be changed programmatically or manually.