>>Ed,
>>Maybe that's why I'm having a problem! I have embedded objects (mostly Word and Excel) in a general field in a table. I want to create a form where I can control the user access to the document by way of push buttons: Print it, Look at it - but NOT make any changes, Edit it, Create a new one. (This is becuase of security reasons. Not all users can modify these docs, but they can "see" them) So with the "Print" button, I just want to send a command to print the document. With View I just want to print preview. Edit and create I think I can manage from the documentation I've got. I don't know how to send the print and print preview commands to Word or excel or powerpoint or whatever because I can't find what they are!
>>
>>On a related note, when you embed an object interactively through the dialogue, you have a check box to display the object as an icon. How do I do this with the appe/modify general command? There doesn't seem to be an option for it in the appe general help topic or the "Adding Ole" chapter 10 in the VFP help.
>>
>
>I haven't got a clue about OLEBound controls beyond having played with them - that's not how I use Word in my own apps; I normally instantiate Word through OLE Automation directly, so that I have a hook to an instance of Word.Application, which lets me access the entire automation object. I don't use General fields; I either save the path of the document, or save the document in a binary memo field.
>
>The verbs mentioned in the VFP6 docs for an OLEBound Control invoke the registry entries entries associated with the document type in the registry; since I don't know the numbers, what I'd do is rely on the name of the verb you want to execute; if there's a "print" verb associated with the document type in the registry, it can be fired by name rather than y number. You may want to check the registry entry to see what shell commands are associated with the document type - you can view that with the Windows Explorer (under current shells, View-Folder Options, the File Types tab; find the document type; the defined verbs will appear in the Actions box, with the default verb highlighted.) Alternatively, you can inspect HKEY_CLASSES_ROOT to see what's defined there; look for the ProgID of the provider, and enumerate the subkeys of the Shell subkey to get the names of the defined actions. For example, if the default provider for .DOC were Wordpad.Document.1, I'd search
>the subkeys of HKEY_CLASSES_ROOT\Wordpad.Document.1\Shell to get the names for defined verbs on my system; in my case, I have entries for open (default), print and printto available. I can invoke them by name, and have no clue as to what number they are.
>
>You have significantly more control using direct manipulation of Word using the available automation model, but there's no trivial way to bind it to a general field AFAIK. I tend to store separate documents and reference their path; the only other approach has been to store the object in a binary memo field rather than a general field, and write wrapper code that extracts the content to a .DOC file and works on that - if the date/time stamp on the file changes when you finish, then you need to save the temp file back to the memo field using APPEND MEMO (if you use VFP6, the STRTOFILE() can copy the content to a file and FILETOSTR() can be used with REPLACE, or you can use the COPY MEMO and APPEND MEMO commands with any version.
>
>One significant advantage of using the OLEBOund control is that you're less affected by the exact app software installed; on a system with Word installed, the .DOC file type will be handled by Word rather than Wordpad; if you rely on using Word.Application, you'd better make certaint he Word is there. If anything can provide services for the filetype, you can access the defined verbs in the registry.

////////////////////////////////
Ed

Ahh, maybe I should rethink my approach- The business requirement is that first of all, these are control documents. Not just anyone can access them. Even among those who can, changes are NOT allowed - they can't even print them. They can look at them on screen - that's it. Currently I use network security, but that does not disallow the choice of opening a file with read only access to a drive, changing it and saving it to another location on the network where the user has full access. We can't have that with these kinds of documents. They are proprietary (design instruments) and we also don't want to run the risk of someone "selling" them to a competitor. We also can't have someone making unauthorized changes. So I figured I had the most control over them from within VFP if I treated tham as embedded objects. If one is printed I need to log date time and who printed it. If it's changed I need to log that as well. If I link them (by way of general field or just a text field pointer to their directory/name) that still means someone could open from outside of VFP and circumvent required security. The binary data in a memo might be OK, but I've had far too many memo file corruptions to feel that's a safe bet. Any suggestions?

Susan
/////////////////////



>
>>Thanks for your help!
>>Susan
>>
>>>>Hi!
>>>>Can anyone tell me where I can find the OLE verbs for manipulating Office97 docs from within a VFP6 application? I just spent two hours looking for this on MSDN on this with no luck!
>>>
>>>What do you mean by OLE verbs? Do you mean the published methods of the ActiveX components associated with various automation objects associated with Office97 applications? If so, try David Frankebach's web site.