<doc>
	<legacy_id>2287</legacy_id>
	<name>filename</name>
	<type>property</type>

	<syntax>
		<example>set the filename of {<i>image</i> |<i> player</i>} to {<i>filePath</i> | <i>URL</i>}</example>
	</syntax>

	<synonyms>
	</synonyms>

	<summary>Specifies the file associated with a player or image.  </summary>

	<examples>
<example>set the filename of image "Animation" to "/HD/Projects/blipvert.gif"</example>
<example>set the filename of last player to "http://www.example.com/myMovie.mov"</example>
	</examples>

	<history>
		<introduced version="1.0">Added.   </introduced>
		<deprecated version=""></deprecated>
		<removed version=""></removed>
		<changed version="6.5">6.5</changed>
		<experimental version=""></experimental>
		<nonexperimental version=""></nonexperimental>
	</history>

	<objects>
		<player/>
		<image/>
	</objects>

	<platforms>
		<mac/>
		<windows/>
		<linux/>
		<ios/>
		<android/>
	</platforms>

	<classes>
		<desktop/>
		<server/>
		<web/>
		<mobile/>
	</classes>

	<security>
	</security>


	<classification>
		<category>Images &amp; Multimedia</category>
		<category>Files, Folders, &amp; Resources</category>
	</classification>

	<references>
		<function tag="shortFilePath">shortFilePath function</function>
		<function tag="tempName">tempName function</function>
		<command tag="import">import command</command>
		<property tag="fileType">fileType property</property>
		<property tag="constantMask">constantMask property</property>
		<message tag="saveStackRequest">saveStackRequest message</message>
	</references>

	<description>
	<overview>Use the <b>filename</b> property to reference a separate file that holds the data for an image or player that's a referenced control. </overview>

		<parameters>
		</parameters>

	<value>The <b>filename</b> of an image or player specifies either a file path or a URL. A file path specifies the name and location of the file. If you specify a name but not a location, LiveCode assumes the file or relative paths are from the defaultFolder or the folder the stack is saved in. A URL specifies the name and location of a file on your system or anywhere on the Internet. <p></p><p>By default, the <b>filename</b> property of newly created images and players is set to empty. </p></value>
	<comments>The contents of an image can reside either in the stack or in a separate file. If an image's <b>filename</b> is empty, the image uses its own data, which resides in the stack, instead of loading a separate file. (You can import an image with the import command, or paint an image with the paint tools. ) Setting an image's filename property to the name and location of a file deletes the previous contents of the image. <p></p><p>Using an image from a separate file reduces memory use, since the image does not need to be loaded into memory unless it is in use. But it increases the time it takes to go to a card containing the image, since the file must be loaded from the disk it's on or from the Internet. </p><p></p><p>The contents of a player must reside in a separate file that is specified in the player's <b>filename</b> property. If a player's filename is empty, the player does not display any data. The file specified by the filePath or URL must be in a format supported by QuickTime. </p><p></p><p> set the filename of player "My Player" to "SecondMovie. mov"</p><p> set the currentTime of player "My Player" to zero</p><p></p><p>If the filename of a player is set to an invalid file/URL, or to a corrupted file, then an error message of "could not create movie reference" is returned in the result. Otherwise, empty is returned in the result.</p><p></p><p>If you specify a URL for a streaming QuickTime movie file, LiveCode displays the movie sequentially as it downloads. Otherwise, LiveCode must download the entire file before you can play it. To pre-fetch a file from the Internet in order to speed up access to it, use the load command before visiting the card that holds the player or image that references the file's URL. </p><p></p><p>You can use the "New Referenced Control" submenu in the File menu to create a new image or player which references the contents of a file you specify. You can also set the filename to an absolute path or relative path by changing the Source field in the image's or player's property inspector.</p><p></p><p></p><change><p>The URL option was introduced in version 1.1. In previous versions, the filename of an image or player always specified a file path on the local system, and files on the Internet could not be used. </change><p>&#9;</p><p></p><change><p>Support for Density Mapped Images was introduced in version 6. In previous versions, the filename of an image would only be able to use that particular image for display. Images with differing resolution are now supported, allowing applications to take full advantage of Hi-DPI.</change><p>To take full advantage of Hi-DPI, images must be provided at appropriate sizes for different densities. This can be done by having multiple image files in the same location named appropriately (with the image object referencing the image file at the natural density). The naming convention is as follows:</p><p>- @ultra-low.</p><p>- @ultra-low. - 0.25x</p><p>- @extra-low. - 0.5x</p><p>- @low. - 0.75x</p><p>- @medium. / . - 1x</p><p>- @high. - 1.5x</p><p>- @extra-high. / @2x - 2x</p><p>- @ultra-high. - 4x</p><p>When an image is required, the current scale factor is rounded up to the nearest standard density (one of 0.25, 0.5, 0.75, 1, 1.5, 2 and 4). The image with the lowest scale factor that is greater or equal to the nearest standard density is then selected. For example, if the scale factor is 1.75 and there is an extra-high image available, then that is used.</p><p>Images should be created at appropriately scaled pixel size. If the natural size of an image is x points wide and y points high, the scaled versions should be x scale pixels wide and y scale pixels high in order to have the same natural size. You should take care that the natural size of the image scales to integer pixel sizes, as the logical point size of the image is rounded up to the nearest integer. If this is not practical for a given image, you may need to design your apps to handle slightly different resulting image sizes.</p><p>A useful rule of thumb is for images to have natural width and height values that are multiples of four, this way all the supported densities result in integer pixel sizes for each version of the image, and the resulting image has the same logical point size as all display densities.</p></comments>
	</description>
</doc>