File Associations - Append General Problem

[GriffMG]

Hi

I have a 'growing' problem with the 'append general' I'm using to get a bitmap into a general field - which is used as a logo on all the paperwork that the systems print.

In the past, when the resultant image has ended up muddled - generally with a squiggly bit and the file name and under it - I have told the user to use ASSOC .BMP=Paint.Picture and it's worked ok after that.

But this seems to have stopped working on some machines.

Can VFP do the assoc at runtime?





Regards

Griff
Keep [Smile]ing

 

[Scott24x7]

Griff,
The age old problem of corrupt OLE objects in a General Field... there are a couple of ways you can "deal" with this issue, once and for all. It depends on how "Protected" your .bmp really needs to be. (i.e. is it really necessary to have it in a General Field only accessible by VFP?)

1.) Keep a copy of the .bmp in some "System" location. When you run that part of your code, always have it "load" that image back into the data table's general field before you try to use it to print with. A little "overhead" but, in today's machines it should hardly be a blip, as long as you're not printing it 10,000 times in a print job. You can do this by just forcing it in every time over whatever is in there by getting that record, and issuing an "APPEND GENERAL <field> ... contents <filename>" If it's a single company logo, and to minimize your "code updates" this is probably the easiest permanent fix for it. (Forgive my not remembering the Append General syntax off the top of my head... been a while since I had to do that...)

2.) Alternately, if you have LOTS of images, and LOTS of fields to associate with them (perhaps even in multiple tables) I have found (begrudgingly over several years...) that the best thing to do is abandon the general field for used with image data. For some reason, it just corrupts, corrupts, corrupts. You can instead use a memo field to store the location of your .bmp (or whatever graphic image, I recommend .JPG in reality for both options as it will be MUCH smaller and faster.
This actually solves 2 problems. 1 - Table Bloat from LOTS of General Field image data, and 2 - No OLE corruptions ever. Then, you use an image field in your report, and pass it the contents of the memo field name into the "Image" property, and like magic, you get your graphic, Untainted, and unaltered, still sized or stretched as you define. Much to my dismay, this has proved to me to be the best way. And it keeps your image reference down to a single source... so if you have a logo change, or image update you only have to update the single image file, and everything picks it up from there... (Poor man's inheritance, eh?)

Anyway, hope this helps. I know it's probably not the answer you were hoping for, but it truly will end your headaches in one go...

Best Regards,
Scott

&quot;Everything should be made as simple as possible, and no simpler.&quot;

 

[GriffMG]

Hi Scott

Thanks for your very full answer, but that isn't really my problem.

My problem is that VFP 6 (maybe 9 too, I haven't tested) is unable to do the append general properly unless Paint is properly associated with the .bmp file.

The bloat thing isn't really applicable either, this is effectively just a corporate logo to personalise (corportatify?) the printed output - so there is only one for most people.

Any ideas how to force the association before doing the append?



Regards

Griff
Keep [Smile]ing

 

[Scott24x7]

Griff,
I'll have a look at an "old" application where I used to do heaps with General Fields, but one thing I do know that I did in the past to "Fix" the multitude of general field problems, was to do something like the following (and you could do this at run time each time, before you print... would only add a second or two to the process...)

SELECT DATATABLE
<Locate your record, through whatever means...>
SCATTER MEMVAR <localize this to an object now if you like>
DELETE
APPEND BLANK
GATHER MEMVAR <from localization if you have done that>
APPEND GENERAL [PictureField] FROM <.bmp file stored elsewhere> CLASS PAINT.PICTURE

The problem is you can not "Replace" the existing General Field, so you have to create a new record for it, and replace your empty field with a clean copy of the bump. Then just "Pack" the table (I assume this is probably a 1 record table anyway, with corporate info, and a logo in the general field...), and continue on with your report printing...

As I mentioned, you could still dump the general field, replace it with a Memo field that has the path and file name to your .bmp and ditch all the messy general field mucking about anyway. You then just pass the value of the Memo field to the .PICTURE value of the object in your report form (even in VFP6) and you will get a perfect image every time...

Anyway, hope this helps


Best Regards,
Scott

&quot;Everything should be made as simple as possible, and no simpler.&quot;

 

[GriffMG]

Hi Scott

Actually you can replace the general field - you can clear it with an APPEND GENERAL MYGENERALFIELD and/or just reissue the original fully specified APPEND GENERAL... command.

I just need some way of making sure I have the right associations - and possibly OLE settings in the registry.

Thanks

Martin

Regards

Griff
Keep [Smile]ing

 

[GriffMG]

I * THINK * I may have found a solution... or at least part of one.

Firstly removing the windows component MSPaint from the system and putting it back - may well work.

Secondly, yet to be tested,

This link

http://www.lns.cornell.edu/~draft/Manuals/IV9/AutodeskInventorPro9_Readme.rtf

Gave me somewhere else to look in the registry... now all I need is a 'broken' system to fix it with!

The answer is about half way down the document and in the section headed Part Modeling & Sheet Metal

It says to put back a reference to paint.picture in the registry HKLM\software\classes\.bmp

I *think* it means change the default from whetver it is back to Paint.Picture

Regards

Griff
Keep [Smile]ing