UDT的長度有兩種，一種是寫入文件時的長度，一種是實際在內存中的長度。二者肯定是不一樣的！
對於定長UDT，一般都是需要其寫入文件時的長度。
若所有UDT都是定長的，可用len直接得出，若包含變長內容，如你的xx() as xxx動態數組，或變長String，那就很難了，可能需一個個計算。
因爲對於UDT中的動態數組或變長串，Len只返回4個字節，相當於一個32位指針
例如:
Public Type a
xx As Integer
xxx As Long
End Type
Public Type b
xx() As Integer '動態維
xxx(100) As a
End Type
Public Type c
xx As a
xxx As b
End Type
Public ccc As c
ReDim ccc.xxx.xx(10)
Debug.Print Len(ccc)
不管ReDim ccc.xxx.xx(10)，還是ReDim ccc.xxx.xx(1000),都會得到
Len(ccc) = 616
的結果
自己看一下Len是怎麼算長度的：
類型a長度：Integer+ Long=2+4=6 Byte
類型b長度：Integer()+a(100)=4+101*6=610
類型c長度：a+b=6+610=616
而實際長度：當ReDim ccc.xxx.xx(10)時
ccc的長度=616-4+2*11=634
以上方法，的確很麻煩。而且雖能算出寫入文件的長度，但VB能否正常按此長度寫入，還說不定！
再說一個推測出的觀點，僅供參考：
對於定長UDT，不管多少層嵌套，VB在內存中都是連續存放的，所以VB可用Len直接得出長度，而且可用CpyMemory直接複製結構；
而對於變長內容，VB在連續存放的內容中，只包含一個指向變長內容存放地址的指針，這時VB會無法按計算出的實際長度寫入文件，只能按Len的結果寫入，所以可能也只是個內存指針，肯定出錯。同時CpyMemory也很危險，若按計算出的實際長度Copy，會在後面帶上不知預知的內容，若按Len長度Copy，這樣又有可能產生兩個不同變量指向同一地址的結果。
綜上分析，對於變長UDT，因其存放時的不連續性，所以取得其長度，幾乎毫無實際利用的意義！所以，VB基於這點，也就不提供計算其長度的方法了。