Hi Fabio,

I'll verify all the necessary info. I have Windows 95, VFP 6.0 SP4, WORD 97 at work. 192 RAM. I don't think, it's ActiveX progress bar problem.

It's dcom98.exe in Windows/System

>Hi Nadya
>
>Today I test the sample with an old IBM ThinkPad (365xd), 40mb memory, win98se, and VFP6 sp5 and word97 sr1. I run the sample 4 times and the result is always the same: A nice 2 pages doc with 40.448 bytes in 3 minutes.
>Even with this slow machine, when I click the "proceed" button, it becomes disabled immediately. I can't figure why your work machine doesn't do the same. Maybe the problem resides in your activeX progress bar control. Mine is version 6 (sp4). Also please review your dcom version. Ensure you are using dcom98.
>
>If those criteria are ok, the only option left is run the sample program with debug, in order to check what is going on.
>
>Your word configuration was not restored because the process was aborted with an error. When it runs until the end, all word features are restored to its original state. The "original word configuration.cfg" file located in your temp folder keeps this defaults.
>
>Sometimes windows ignore its font table. This problem is reported in MS knowledge base (Q169330, Q133732) and how to solve this issue. Frx2word make no alteration in default word font.
>
>I hope this can be useful.
>
>Fabio
>
>
>>Hi Fabio,
>>
>>I've ran the test on my work machine. Sample file is 40KB, but there is nothing in it (I scrolled in all directions and the file has 2 pages with nothing).
>>
>>I have Windows 95 and Word 97 - SR1 at work.
>>
>>I tried yesterday at home. (Windows 98 + Word 2000, no printer installed). I installed generic printer driver and then ran the test. I'm afraid, I pressed the button few times, because it doesn't seem to do anything at the beginning.
>>BTW, suggestion: add a wait window immediatelly in button click and activate progress bar immediatelly. After it's finished, give a messagebox with "Finished". Allow ESC interruption from the beginning of the process (not only after progress bar appears).
>>
>>Anyway, after I've done it, my husband opened Word. The font was somehow different, than it was originally. So, he closed the file without saving and un-installed the printer. Then font goes back to normal, but vertical scroll bar was gone. Fortunately, we were able to restore it back from menu Options...
>>
>>The sample.doc was empty (0 bytes).
>>
>>>Hilmar.
>>>
>>>Another users perform the same test with success, You can try eliminate or rename normal.dot. Also check where the file must be generated.
>>>
>>>The languages distinction is a nice suggestion. I can create a method returning the error in English and the user can change this method for his needs. What do you think?
>>>
>>>The CHM file was written in the past by Jeff Bowman. But I take the task to me. No matter at all. But thank you for your suggestions.
>>>
>>>Fabio
>>>
>>>>Favio,
>>>>
>>>>Your sample program works, but when doing my own tests, I get a 0-byte Word file. Do you have any explanation why this can happen? (Return code = 0 - no error). I am using Word 97.
>>>>
>>>>Additional comments:
>>>>
>>>>1) I suggest including #DEFINEs for the error codes, preferably in several languages. I offer to provide the Spanish (L.A.) translation if you are interested. Another alternative would be to provide a property with the error text, to be invoked like this:
>>>>
>>>>

>>>>nError = oFrx.ReportForm(...)
>>>>if nError < 0
>>>>  MessageBox(oFrx.ErrorText)
>>>>endif
>>>>

>>>>
>>>>2) I believe it is too much trouble to maintain documentation in two different formats, and suggest keeping only one - DOC or CHM.
>>>>
>>>>Hilmar.