Exportin OLE objects(files) from container field

[xtrim]

Hi,

My windows users use the drag & drop capabilities in FM.

The problem is that I only now found out that once you do that you cannot export the content of the container via script or even manually (right click -> export field content)

is there an OS level script that can extract the content somehow?

I have many users across the globe with their own copies of the Database and I need to automate the upgrade process, so I cant just convert the files..

[fseipel]

You can name the container field on a layout (layout mode|click on container field, Edit Menu|View|Inspect|Position Tab, input layout name (alias) for container field in Name text input box). You can then have a script loop through the records, using GetLayoutObjectAttribute("Container Alias Name","content"). For (properly) inserted files, content will be the text comprising filename, no path. For OLE objects dragged & dropped, it will be '?'; for records with empty container field, 'content' will be empty. So that will at least identify the offending records. If the record also indicates who input the record or the computer name, you can then narrow the problem down further. Note that if you switch the Winblows clients to FM12, the problem won't be experienced, because OLE support was dropped; hence drag & drop will insert the file, not an OLE link. If clients must run 11, a script trigger, on modify, to check the field's 'content', and disallowing '?'/clearing it/displaying dialog message, might be advised. Once you have identified the records containing OLE links using the looping method above, you should be able to right-click on the container field (at least on the Windoze client). Right clicking will allow you to select 'properties packager shell object'. Under location, will be the path to the file. The file can then be inserted from that path. I don't know of a way to get at that from an automated script, however, because I do not think the FM API exposes the OLE link property.

[xtrim]

Well - I think I can resolve that problem with "Convert File" script step...

Is there a way not to auto-open the file after conversion?

[fseipel]

I take it you are converting from .fp7 to FM12 to resolve the problem. The file will open upon conversion. You could include a startup script that checks if the first record in a dummy table is set to say 'close', and if so, unset it and close file, or simply have startup script interrogate the converted file's name to determine whether to close. On successive opens the file will open. You can also perform script in the converted file. Since some commands, such as perform script in second file, don't accept variables (e.g. filename), you may end up needing to rename files prior to running your script & again afterwards, so their name conforms to the fixed name used in the script to close it. If you use 360Works Scriptmaster, you can run a script with variable filename. Another option would be to close the window automatically to close the file. For Windoze, you can achieve that by sending CTRL+F4 key, e.g. run a VBSCRIPT to close the window. See http://www.pctools.com/guides/scripting/detail/149/?act=reference -- similar should be possible with Applescript, kind of a kluge but does work.