>Gooooood morning Vietnam .... euhhhh no VFP,
>7h30 am in Belgium ,....
>
>Ok lets start with that:
>
>I'v a small (not so small!) problem with general field,
>Some users of my app as installed photoeditors(like a photoshop, or others)on WS,
>In this situation, vfp app, show bitmap image as a kind of icon with the file name in bottom! i can't do nothing with the contend of general field (can't edit bmp file or show in image object or place this bmp in report)
>I suppose that the header of is neo more pointing to the right ole provider (like paint in Win NT)?
>What can i do ?

You can install a different OLE provider for the file extension that offers an Edit action for the file. You're limited to the functionality exposed by the current OLE provider for the file type - the General field uses the registry to select the app and command to use when the embedded or linked file is viewed, edited or printed via the General field. At a minimum, you want the OLE provider to offer an Open action; in some cases, the provider distinguishes between the Open and Edit action - for example, VFP typically will execute a .PRG file when Open is issued, but an Edit verb can be defined to run the VFP editor against the .PRG as well. If you need to print the content, the provider will need to support a Print verb. Other verbs may be available; typically, VFP uses the Open or default verb in a Form, and the Print action in a report.

If you know the command line or DDE parameters used by a particular OLE server app, you can alter the default behavior of the Open verb to edit as well as view the embedded file, assuming that the server supports editing the file type. The server determines the exact interface exposed when the General field is active; the server is defined on a system by system basis, so it's not unusual to have different behaviors for a General field when different servers are selected on different machines. I'd suggest that you standardize on a single server to use on all workstation for a given filetype; you can check the HKEY_CLASSES_ROOT\.filetype registry key to determine what if any server is installed, and alter it to point at another server or adjust the verbs pointed to for the server to your standardized OLE interface in the registry before initializing the General field on the Form or Report to provide a consistent behavior for the field for all systems.

Example:

HKEY_CLASSES_ROOT\.BMP points to "Paint Picture"
HKEY_CLASSES_ROOT\Paint Picture has a number of subkeys, including Shell defining OLE verbs
HKEY_CLASSES_ROOT\Paint Picture\Shell\Open\Command = "F:\WINNT\System32\mspaint.exe" "%1"
HKEY_CLASSES_ROOT\Paint Picture\Shell\Print\Command = "F:\WINNT\System32\mspaint.exe" /p "%1"
HKEY_CLASSES_ROOT\Paint Picture\Shell\PrintTo\Command = "F:\WINNT\System32\mspaint.exe" /pt "%1" "%2" "%3" "%4"

HKEY_CLASSES_ROOT\.PRG points to "Visual.FoxPro.Program"
HKEY_CLASSES_ROOT\Visual.FoxPro.Program has a number of subkeys, including Shell defining OLE verbs
HKEY_CLASSES_ROOT\Visual.FoxPro.Program\Shell\Open has both command and DDEExec subkeys
HKEY_CLASSES_ROOT\Visual.FoxPro.Program\Shell

has other subkeys, ncluding the default Print and PrintTo keys, and some custom OLE verbs I've defined for Edit and Debug, which are available when I right click a .PRG file in Explorer. I also changed the default verb for .PRG to Edit rather than Open using the REGEDT32 (the registry editor for NT/2K). The Edit verb runs a small .FXP that opens the specified file with MODIFY COMMAND. The Debug verb runs a .FXP that sets up my debug environment and launches the selected file. You can define whatever verbs you want either directly using the registry editor or the Windows Explorer File Types dialog.