Thanks to Yu Tang a Japanese translation is now available too.

Using custom objects is great in your applications.It gives you organized and visual way to access global options, configuration data, etc...
      However usally when it is time to load up these objects on start up or save them on exit you have to read in each field one by one from an ini file or from registry values.
      This technique will show you a way that you can save the entire configured object into a binary file and then latter extract the completly configured object with about 3 lines of code. I suspect that you can also use this technique savign objects to a database assuming the column is set for a binary data type.
      Here is an example program that demonstrates the technique. Start up a new standard exe project, paste this source in to the code window and run it.
Private Type blah
      name As String
      plan As String
      goal As String
      number As Integer
End Type

Private Sub Form_Load()
      Dim b As blah
      b.name = "Just some guy"
      b.plan = "eat yummies and get fat like sumo wrestler *flexes*"
      b.goal = "find a decent job that actually pays enough to live on :-\"
      b.number = 3

      f = FreeFile
      Open "c:\blah.txt" For Binary As f
      Put f, , b
      Close f

      Dim ha As blah
      Open "c:\blah.txt" For Binary As f
      Get f, , ha
      Close f

      MsgBox "Object data read in from saved file:" & vbCrLf & vbCrLf & _
            "blah.name = " & ha.name & vbCrLf & _
            "blah.plan = " & ha.plan & vbCrLf & _
            "blah.goal = " & ha.goal & vbCrLf & _
            "blah.number=" & ha.number

End Sub


This code is deceptivly simple...the thing to notice is the line:

Put f,,b

f is the filehandle, the empty argument is the start-at offset (BOF) and 'b' is the configured object. We are telling it to write the entire data structure with data to disk. Basically we are creating a memory dump of the structure.

Like wise it is worth to note the lines:

Dim ha As blah

here we are telling the system that 'ha' is actually the datatype "blah" which is composed of 3 strings and an integer value. Then when we tell the system to:

Get f, , ha

where we are telling it to read the file until the datatype has been filled. Here is a how the file "c:\blah.txt" appears in a hex editor:
 0D 00 4A 75  73 74 20 73   6F 6D 65 20  67 75 79 33   ..Just.some.guy3 
 00 65 61 74  20 79 75 6D   6D 69 65 73  20 61 6E 64   .eat.yummies.and 
 20 67 65 74  20 66 61 74   20 6C 69 6B  65 20 73 75   .get.fat.like.su 
 6D 6F 20 77  72 65 73 74   6C 65 72 20  2A 66 6C 65   mo.wrestler.*fle 
 78 65 73 2A  3A 00 66 69   6E 64 20 61  20 64 65 63   xes*:.find.a.dec 
 65 6E 74 20  6A 6F 62 20   74 68 61 74  20 61 63 74   ent.job.that.act 
 75 61 6C 6C  79 20 70 61   79 73 20 65  6E 6F 75 67   ually.pays.enoug 
 68 20 74 6F  20 6C 69 76   65 20 6F 6E  20 3A 2D 5C   h.to.live.on.:-\ 
 03 00                                                 .. 


      Its also neat to look through the output file so you can literally see the physical representation of the binary data that comprises the object. Look at the first line: "0D 00" then our string of data. 0D is hex for 13. There are 13 characters (bytes) in the string "Just some guy". The null byte looks as if VB uses a 2 byte (vb integer) type to hold the string length so 0d 00 is 00 0d held in little endian format.
      From just this much we know that data structures are held in memory as binary data with a header preceeding each component of the structure that details how many bytes are held in the structure. Now look to the beginning of the next string "33 00". &H0033 = 51 decimal..hey guess what there are 51 bytes in the next saved string. so it looks like we have a valid hypothesis from our preliminary data.
      Now if we shift our attention to how it saved the integer value we notice a different setup. For stored integers there is no header. Just the value and an end delimiter (which could either represent the end of the integer value or end of the data structure need more evidence and tests here.) This change is likley due to the way that the C language holds string. I consider VB style strings like a gift from the gods above *bows head in moment of reverance*. In C if you want to save a string...you have to declare an array of characters and have to tell it how many elements are in the array to hold the whole thing! If you tell it wrong then well you are usally overwriting other data as you barge and stomp over other data types. This is called a buffer overflow and there is oodles of infos and warning on it out there. Anyway as i digress...
      We need more tests before we really understand how all the data types are what limitations may be. This is to say that this may not work in every situation. I have yet to really test its boundries. A variable length array for instance can not be directly saved to disk and restored without knowing how many elements the original array contained. Things like preserving data types for variant arrays looks to work, as does things like allowing strings to contain embedded nulls.
      At any rate this is a valid technique and is capable of saving you some significant coding time. The actual data structure of objects as binary data isnt somthing VB developers usally have to worry about..but it is a valuable thing to know and this helps demystify what is actually going on when you pass objects to functions or create new types. Have fun with it, and if anyone does more any experimenting to determins the techniques bounds drop me a line and i will include your comments inline here. If you are intrested in this stop from time to time and see how i and others progress with it. I have not seen this documented anywhere and i have yet to really sink my teeth into it an anlysis of it. I can already forsee some nifty uses of this nto to mention just the sheer visualization factor this brings to my thought and understanding of what is goign on behind the scenes.


Update:

It also appears you can use this same technique to serialize variant arrays to disk. Restored arrays will even maintain their variable types :)

Private Sub Form_Load()
    
    Dim args(), x()
    Dim cnt As Byte
    Dim f As Long, tmp
        
    f = FreeFile
    
    ReDim args(1 To 3)
    args(1) = CLng(21)
    args(2) = CByte(2)
    args(3) = "21"
    
    Open "C:\test.bin" For Binary As f
    Put f, , CByte(UBound(args))
    Put f, , args()
    Close f
    
    Open "C:\test.bin" For Binary As f
    Get f, , cnt
    ReDim x(1 To cnt)
    Get f, , x()
    Close f
    
    tmp = "Recovered elements: " & UBound(x) & vbCrLf
    For i = 1 To cnt
        tmp = tmp & "Element: " & i & " Type: " & TypeName(x(i)) & " Value: " & x(i) & vbCrLf
    Next
    
    MsgBox tmp
    

End Sub