APPEND GENERAL FROM FILE
fan
viewable without double-clicking?
.xls, .avi, .doc all allow for viewing and printing without launching the
associated app, but graphic files seem to require it.
I attempted to use the Class Name and tried MSPAINT and PBRUSH, but they
make no difference.
How do you determine the Class Name? Is that even the issue?
Dan Freeman
storage.
To your issue, the display of objects in general fields is COMPLETELY out of
VFP's hands. It is handled by the application-owner of the object stored in
the general field. VFP just rents out the space. So if you have a different
application on two different machines for type "jpg" (for example), the
object may look different on those two machines.
General fields solve few problems and cause many.
What are you trying to do? Perhaps someone will be able to suggest an
alternate approach.
Dan
fan
there would still seem to be a way understand what the settings are when it
does work, and that is what I am trying to figure out.
If I ask Microsoft, what do the settings in the OS or MSPAINT need to be in
MSPAINT to be able to execute the VFP command
append general field from file
They will tell me to contact VFP, and if I ask VFP, they will direct me to
Windows Support - ask me how I know this, so I come to you, my fellow front
lines and ask, what do the setting need to be so that it works, because
sometimes it does,.
Has anyone figured it out?
TO ANSWER YOUR QUESTION, I AM TRYING TO STORE AND DISPLAY .BMP AND .JPG IN
VFP.
.xls and .ppt and .doc all permit displaying the contents without
double-clicking the General field, and sometimes .jpg, and .bmp? When it
works, why does it and how can you reset those settings, when it stops.
"Dan Freeman" <sp...@microsoft.com> wrote in message
news:uayXPFOJ...@TK2MSFTNGP04.phx.gbl...
andrew...@gmail.com
> Is there a trick to import graphic files into a General Field and have them
> viewable without double-clicking?
APPEND GENERAL table.genfield FROM c:\mypic.bmp CLASS Paint.Picture
Sorry I can't expand on how to discover the class, I just read that
somewhere or other, tried it and it worked. I don't know anything
about jpg in Fox since I'm (still :D) using FPW2.6a. Upgrading's
overrated <s>
As for displaying, how do you want to display?
Browse example:
MODIFY GENERAL table.genfield
BROWSE
Or you can create a form and put a picture field on it pointing at the
general field.
--
HTH
Andrew Howell
Dan Freeman
original .jpg or .bmp file (possibly stored in a blob field). You cannot
control the display of a general field. That is ENTIRELY controlled by the
application that owns the data inside the general field.
Dan
fan
Perhaps you can try it and tell me what you get?
add a general field to a table called graphic
locate 4 example files on your PC,
.doc, .xls, .jpg, .bmp
execute this command
append blank
append general graphic from path\file.doc
append blank
append general graphic from path\file.xls
etc.
Browse the table
Double click the general field and adjust it to view the contents
scroll through the 4 records and tell me what displays for each.
In my case, I see the .xls and the .doc, but for the .jpg and .bmp, I see a
thumbnail of the image and the file name. If I double click the thumbnail, I
see the image in full size in whatever application is associated with the
extension, but all I see is a thumbnail.
If I change the association and append again, the thumbnail is still all I
see although the applicatrion that permits viewing in normal size after
doubleclicking the image changes
If I append using:
append general graphic from path\file.xls class MSPaint
for instance, there seems to be no difference.
However, I am able to add records using this approach from time to time and
they display as full images and not just thumbnails, but I don't know why
that is the case.
Once they are in the table, they always display as either thumbnails or full
images.
What I am trying to understand is how to control the environment so that
they when they are appended, the PC is set to append them as full images,
and not simply thumbnails.
This may require a registry mod prior to appending any records, I
understand. WHat I need to know is what is the registry change to do it. I'll
figure out the security rights issues etc. later, I am just trying to figure
oiut why it works sometimes and not others.
I attempted opening an incident with Microsoft, but you know what good that
does you with anything that deals with more than one element, in this case,
VFP and the OS, and/or MSPaint. They don't seem to be able to get a hold of
another part of India to see who handles that other part of their (our)
product.
"Dan Freeman" <sp...@microsoft.com> wrote in message
news:ul6t1CXJ...@TK2MSFTNGP02.phx.gbl...
Olaf Doschke
> Browse the table
Don't browse it, show it on a form with the Olebound control. Set
controlsource to the general field. That should solve your main problem,
which is binding the general field to the wrong control.
The browse always display fields with the textbox control, and as it is not
the control to display Memo, it's not the control to display General fields.
An additional reason may be those BMP and JPG are not supported by MS Paint
or Paint.Picture (see later).
As Dan said, what happens inside that Olecontrol is not under the control of
VFP. And as you can't change class/file association of a general field after
it is appended and can only extract it with trickery back to the original
file, it's not a good idea to use the general field at all other than for
temporary use as the source of an oleboundcontrol in a form or report, as
then you insert it at the mchine, where you use it and dispose it
afterwards.
What Ole class is associated with the file depends on HKEY_CLASSES_ROOT.
Open the registry.
HKEY_CLASSES_ROOT .bmp key. The (Standard) value is Paint.Picture. And in
the "OpenWithProgIDs" you'll also see Paint.Picture as a ProgID. At least
all this is what I see in Vista.
Paint.Picture is the ole class used to display the BMP. While MS Paint is no
OLE automatable application - eg there is no "MsPaint.Application" - it
still uses an/this Ole class to display pictures.
You'll also find Paint.Picture in the CLSID branch of HKEY_CLASSES_ROOT.
The HKEY_CLASSES_ROOT file extension keys are also influenced by file
associations, but they mainly associate extensions to an application, not an
ole class. Therefore this is a root of problems with general fields, most
file extensions are not associated to some ole class. But somehow even just
changing this file extension association does break General fields to
work.And eg associating BMP or JPG with a more modern image processing
application is quite usual and breaks this. To use a certain image
processing application before append pictures will help even less, as not
even the most expensive image processing software will provide such an OLE
class to work in conjunction with genral fields.
Perhaps now you know enough to stay away from those field type. It's likely
to only work on computers with no additional image processing software,
which is even less and less likely on business PCs. The usage of General
fields for pictures dies, has already died in my opinion. You can only use
it with PCs that provide an ole class for pictures and that will only be
MSPaints Paint.Picture. And if somehing more modern is installed you don't
have an alternative ole class. There's nothing you can do about it, unless
you can forbid users to install anything else than MS Paint.
You can easily use a Blob field and the PictureVal of an image control for
images, if you insist on embedding them into data.
Bye, Olaf.
fan
My environment being a business setting is actually locked down, with users
unable to install applications, so it is feasible to control it in this way.
Additionally, there are also two classes of machines, those used for viewing
images, and those for adding images.
The machines used for adding images can be controlled so that it is
practical to prevent them for breaking this function.
Because we also want to be able to print the images embedded in the field,
we created a report and use the print preview function to view the image on
the report.
Just so I am clear, you have stated that the file association is not what is
critical rather that the OLE Class be Paint.Picture
So if
>HKEY_CLASSES_ROOT .bmp key. The (Standard) value is Paint.Picture. And in
>the "OpenWithProgIDs" you'll also see Paint.Picture as a ProgID.
and I
APPEND GENERAL FIELD FROM FILE.BMP CLASS PAINT.PICTURE
should that be sufficient?
If so, that is how my PC is configured but it it still doesn't work, all I
see is the thumbnail. There must be more to it.
Any other clues, or am I missing something?
"Olaf Doschke" <olaf.d...@t-aufderlinie.de> wrote in message
news:D90DD306-CD50-4056...@microsoft.com...
Olaf Doschke
>
>>HKEY_CLASSES_ROOT .bmp key. The (Standard) value is Paint.Picture. And in
>>the "OpenWithProgIDs" you'll also see Paint.Picture as a ProgID.
>
> and I
>
> APPEND GENERAL FIELD FROM FILE.BMP CLASS PAINT.PICTURE
>
> should that be sufficient?
No it isn't
As I said: But somehow even just changing this file extension association
does break General fields to work.
I don't know the inner workings of this and the only
fix I know to make general fields work again with Paint
is to use the DOS command ASSOC.
The problem of a thumbnail is a problem with Paint not being
able to display the real image inside the general field.
VFP always stores a BMP thumbnail with the image file,
and VFP displays that thumb if it's unable to display
the embedded file.
If you still did not have enough trouble, I don't know what
else to say to convince you of using the alternative Blob field.
Bye, Olaf.