>>>This is a FP2.6 WIN app. I tried to do a functional conversion once, but it just doesn't seem to work for me. Development started back in 1994 and has been ongoing since then. I've used GenScrnX and a number of other compiler hook modifications. Pushbuttons on my converted forms don't work, forms won't convert correctly - a whole host of problems that make the conversion process an exercise in futility. I haven't found a way to get it converted and working under VFP.
>>>
>>>I've been developing ancilliary programs in VFP9 for years, but the main app (over 1 million lines of code and hundreds of screens) is still in Fox 2.6a. It's a quite comprehensive system and I have clients in 26 states across the United States.
>>>
>>>I think that I may have figured out a workaround, however. All images are kept as JPEG files. I convert them, on the fly, to BMPs, store them in a temporary folder and then import them into a general field in a temporary cursor for printing. I'll spend the day writing a routine to copy the image report to a temporary folder, open the report file as a table, scan through and find the image object record and then replace the placeholder with the full path of the temporary BMP file. This will eliminate the need for general fields completely. Hopefully, that'll work as a temporary bandaid while I continue the process of rewriting my complete imaging and reporting module into VFP9.
>>>
>>>We shall see... :-)
>>
>>Walt,
>>
>>why do you need to have JPEG files to be converted to BMP? I have no problem to print a BMP file, in the report you drop an image in the band, right click for the context menu and fill in the details.
>>JPG or BMP or PNG or other image files no problem. No need to import them into a general field as the report cursor image field contains the fully qualified filename.
>>
>>This should work and eliminates the use of General fields completely. Also it will reduce your table size dramaticaly so no 2 GG limit ,
>>
>>Regards,
>>
>>Koen
>
>* IIRC you're limited to BMP files in FPW
>* I believe the reason why he's using general field was because he probably wants the image to be based on record data rather than having the same image being printed repeatedly.


Hi,


Sorry I have overlooked Walt is using FP2. All I have said about General Fields a.s.o. better forget. I have forgotten all the FPW stuff long time ago. My advise to Walt: upgrade to VFP9 and dont try to convert a FP2 application to VFP this will not work. For what it is worth I quote Alex here:
quote
Many (most) of use old-timers have done several conversions from FP to VFP years ago. The consensus, by far, is not to do a conversion but to rewrite the program completely. It is a huge leap in software development technologies from FPW2.6 to VFP9 (or any version of VFP for that matter)

You wil find that he biggest changes are in OOP, and the use of forms vs the old screens.

I can tell you now that if you use any automated converter tool you will not be happy with the results. Screens will mostly work but will look more than ugly. This is the time to re-architect the program as a 3-Tier (maybe web-enable if you need that) object oriented program.

The business rules and the code that enforces it can probably be saved and reused as it will be mostly compatible with VFP. The rest should be re-designed an rewritten from scratch. I know it is not what a client wants to hear, but take the advice from the old timers that have been there many times.
unquote

Regards,

Koen