- #date storage: Sometimes the seconds part of a date will be rounded up in a date retrieved from a vList file. Unfortunately the rounding error is inside MOA, so it can't be fixed. If you are going to need precise seconds stored inside a #date data type the best thing to do is store it in two parts in a list, with the seconds part obtained via Lingo before storage:

aDateList = [#date: dateObject, #seconds: dateObject.seconds]

- You cannot use a relative file name of 2 characters or less before the file extension with the read command. It will return a "File not found" error. Workaround: pass a full path. This will error:

inst = new(xtra "vlist","aa.lst")

data = inst.read()

This will work:

inst = new(xtra "vlist",the moviepath & "aa.lst")

data = inst.read()

- If you use the new 2004 syntax to call a handler in an MIAW that returns a list, the thing returned is a "list object" rather than a Lingo list. vList cannot work with list objects. For instance, an MIAW called "miaw" contains this handler in a movie script:

on getList

return [1,2,3]

end

The stage does this:

w = window().new("windowTitle")

w.filename = _movie.path & "miaw"

-- new syntax

listObject = w.movie.mGetList()

-- old syntax

tell w to normalList = mGetList()

put listObject

put normalList

And you get:

-- <Object list 3 6a34b90>

-- [1,2,3]

List objects were introduced in 2004 so that the Javascript engine could work with the list datatype.

- Storing sound sprites in a vList member or file may cause type 2 errors when you quit Director 8 in authoring, in a projector and may crashes your Browser in Shockwave 8 on the Mac. This is a Director problem that is fixed in Director/Shockwave 8.5, The workaround for Director 8 is to set variables referencing sound objects to 0 before quitting.

alist = list( sound(1) )

member("vList mem").content = alist

newList = member("vList mem").content <---- May cause type 2 error in D8

-- workaround to use before exit

newList = 0

- vList's character cross-mapping for stored strings relies on Director's fontmap.txt file. FONTMAP.TXT contains several mapping errors for high-ASCII characters (characters in the range numToChar(128) and above). Since many developers have workaround code in place that would break if these characters were mapped differently, vList Xtra uses FONTMAP.TXT's mappings for all characters. Notice that when running in Director 11 vList will store strings in UTF8 format, and will convert to/from UTF8 and Latin/MacRoman character mappings if necessary, if you attempt to use media from one version of Director in another.

- While it is possible to store the .image property of a member directly in a vList file or member, this actually stores a pointer to the image data. The problem is that if you go to another movie, this pointer will be useless. If you actually want to have an image object that can be used in any movie, you have to create a duplicate of the image data and work with that, like so:

newImage = duplicate(member("bitmap").image)

The newImage object is similar to one created using the Lingo command:

newImage = image(100, 100, 32) -- a 100 by 100 pixels with 32-bit colors

In this case what vList will store in a file or a member is the complete pixmap information needed to recreate that image object at runtime. Note that at the moment vList stores the independent image objects without any compression. So in the example above, vList will need at least 40.000 bytes to store that information. Use member().media to store your images if size is an issue. Director uses compression on bitmap members in order to reduce the size of movies on disk.

- Director gives you the option of decreasing the size of bitmap members even further, in movies converted to Shockwave, by applying JPEG image compression to them. vList cannot currently apply JPEG compression to bitmap members stored using media of member inside vList. Therefore a Shockwave movie comprised mostly of internal JPEG members will have a smaller file size if the members are not saved inside vList containers.

When you import a JPEG compressed file into a movie, Director creates a member with TWO images. The first one is the internal representation, that uses a lossless compression format on disk, and the second one is a copy of the JPEG compressed (lossy) original image. The lossless copy is necessary in case you want to edit the image.

When you save the file as a Shockwave movie (.DCR), Director strips the internal image and retains only the smaller JPEG one. When you save the file as a protected movie (.DXR), Director strips the smaller JPEG image and retains only the larger lossless compressed internal image. When vList stores member("bitmap").media for a member that uses JPEG compression, vList, like the DXR file, stores the larger lossless compressed internal image. This was a design decision of necessity that may impact Shockwave files that make heavy use of internal JPEG images. Solutions will be investigated for a future version, for instance, the addition of optional JPEG compression that could be selected for a stored member().image property. Meanwhile, one advantage of storing images in this format is that the larger internal image takes much less time to decompress at runtime than a JPEG-compressed image.

- postNetText: Director's postNetText command is limited to 64K of data on all platforms in versions prior to Director 8.5. In Director 8.5, in authoring and projector, on the Mac Classic platform only, postNetText corrupts strings longer than 40K (40960) by overwriting the data starting at byte 40961 with data from the beginning of the string. This is not a problem in Shockwave on the Mac, which relies on the browser to perform the post. It is not a problem in any environment, authoring, projector, or Shockwave, on Windows.

- If you use "put data after member 'vlist member'" syntax to add list items to a vList member, under certain rare circumstances a saveMovie will not be successful until the vList member contains at least 2 items. The problem exists only in Director 7. It is fixed in Director 8 and above.

Example:

-- member("vlist) starts out empty

repeat with x = 1 to 3

put #picture after member("vlist")

-- workaround code

if x >= 2 then

saveMovie

end if

end repeat

- Mac only. Under some undetermined circumstances, setting the media of one vList member to the media of another within a repeat loop will corrupt the media property so that the copy fails.

Example:

repeat with x = 1 to 3

member("vList" & x).media = member("vList" & (x + 100)).media

end repeat

Workaround is to use vList_readFromMedia to obtain the data and avoid the media property in this situation.

repeat with x = 1 to 3

data = vList_readFromMedia(member("vList" & (x + 100)).media)

member("vList" & x).content = data

end repeat

Although in the situation above you could always use the content property instead of the media property, it is possible to store the media of vList members in other vList members. In that case, when trying to restore the vList members, there is ONLY the media property and no content until a new member is created. vList_readFromMedia can help in the following situation:

alist = member("vList container for other vList

embers").content

put alist

-- [ <media 83838>, <media 83838>, <media 83838> ]

-- old method for getting vList data back out

repeat with x = 1 to 3

mem = new (#vList)

mem.media = alist[x]

dataYouWant = mem.content

-- do something with data, then erase dummy member

erase member mem

end repeat

Another workaround from Gregory Lardon is to force a pause or add something that gives more time to Director. For example the following is problematic and leads to apparent media corruption:

repeat with i = 1 to n

maList.add(member("x").media)

end repeat

But this works if we add an intermediate step:

repeat with i = 1 to n

vMedia = member("x").media

maList.add(vMedia)

end repeat

Gregory also says that adding a put "" statement inside the loop was a solution to the problem. This problem is not present in Director under Mac OS X or Windows.