Partilhar via


Templates: Quick Overview of SaveAsText and LoadFromText (aka let’s get boring again)

Before we dive into the way the Access Objects are persisted in the Access 2007 template files, I thought it would be best if we talked briefly about the Application.SaveAsText and Application.LoadFromText methods and what they generate and read in, respectively.

 

In case you don’t recognize these two methods, don’t be surprised: they are hidden and undocumented. Before we get all cloak and dagger, it’s worth saying that these methods are not undocumented as in here, but as in here. Now, let’s take a look at the signature for these methods:

 

Sub Application.SaveAsText(ObjectName As String, _

ObjectType As AcObjectType, _

FileName As String)

Sub Application.LoadFromText (ObjectType As AcObjectType, _

ObjectName As String, _

FileName As String)

For both of these methods, you specify an object type, the name of the object and a name of a file. For SaveAsText, the given object is stored in a text format in the given file, and for LoadFromText, an object is created given a text format in the given file.

 

If you look at the text format for a simple form with a single button on it, it looks like this:

Version =20

VersionRequired =20

Checksum =-540535037

Begin Form

    DividingLines = NotDefault

    AllowDesignChanges = NotDefault

    DefaultView =0

    TabularCharSet =204

    PictureAlignment =2

    DatasheetGridlinesBehavior =3

    GridX =24

    GridY =24

    Width =8884

    DatasheetFontHeight =11

    ItemSuffix =2

    Right =7755

    Bottom =7860

    RecSrcDt = Begin

        0x5e1d77333303e340

    End

    GUID = Begin

        0x215548c7105bb74f9c5a62a34852d43e

    End

    NameMap = Begin

        0x0acc0e5500000000000000000000000000000000000000000c00000004000000 ,

        0x0000000000000000000000000000

    End

    DatasheetFontName ="Arial"

    FilterOnLoad =0

    DatasheetBackColor12 =16777215

    ShowPageMargins =0

    DisplayOnSharePointSite =1

    DatasheetAlternateBackColor =16053492

    DatasheetGridlinesColor12 =16765357

    FitToScreen =1

    Begin

        Begin CommandButton

            FontSize =11

            FontWeight =400

            ForeColor =-2147483630

            FontName ="Calibri"

            LeftPadding =30

            TopPadding =30

            RightPadding =30

            BottomPadding =30

            GridlineStyleLeft =0

            GridlineStyleTop =0

   GridlineStyleRight =0

            GridlineStyleBottom =0

            GridlineWidthLeft =1

            GridlineWidthTop =1

            GridlineWidthRight =1

            GridlineWidthBottom =1

        End

        Begin Section

            Height =7560

            Name ="Detail"

            GUID = Begin

                0x074cc32161de494c80853bffa393c314

            End

            AutoHeight =1

            Begin

                Begin CommandButton

                    OverlapFlags =85

                 Left =1800

                    Top =960

                    Width =900

                    Height =840

                    Name ="Command1"

                    Caption ="Command1"

                    GUID = Begin

                        0x3822e4b79de09b4b8acf9150c95debd3

                    End

                    LayoutCachedLeft =1800

                    LayoutCachedTop =960

                    LayoutCachedWidth =2700

                    LayoutCachedHeight =1800

                End

            End

    End

    End

End

As you can see, this format is pretty straightforward: blocks are defined by the BEGIN … END clauses and each property off of the object takes the format of <PROPERTY NAME> = <VALUE>.

 

The control, called “CommandButton” is within a BEGIN … END loop at the end of the description of the form, and its own properties are also described under them. Tabs clearly define a hierarchy here.

 

You will also notice that the binary properties (such as NameMap and GUID) get BEGIN … END blocks with their value codified in hexadecimal numbers. The LoadFromText/SaveAsText format obviously handles all property types for all Access objects: numbers, text, binary, enums…

 

Finally, Access is smart enough to only write out properties that have values that don’t match their defaults. This way we save a lot of space writing things we already know.

 

As an interesting tidbit, you will notice that the option to load and save tables is missing. Yes, you cannot save or load tables using this mechanism, and that’s for historical reasons. This mechanism was never meant as a import/export entry point, but as a simple way to create form, macros, report and queries from a pre-canned source, such as a number of the wizards shipped with Access.

Comments

  • Anonymous
    August 31, 2006
    XML is for losers, eh? ;)
  • Anonymous
    August 31, 2006
    Not really - If I'm not mistaken, this was implemented way before XML became a standard and/or popular.

    Yes, there was once a world without XML :)
  • Anonymous
    August 31, 2006
    I know. I remember this format from Access 2.0, I think.

    I was just kidding.