Append general CLASS "RICHTEXT.RICHTEXTCTRL.1" does not work after windows 10 creator upda

[kiyo]

Hi All.
I am using foxpro9 sp2 Hotfix.
I ran the Creator Update of windows 10.
My report's general field (rtf file) can not be printed.
It printed correctly before running Creator Update.

I tried executing "append general" with a command.
The file seems to be registered in the fpt file.
I noticed that I can not see it with MODIFY GENERAL.

Sample code
APPEND GENERAL aaa FROM a.rtf CLASS "RICHTEXT.RICHTEXTCTRL.1"
MODIFY GENERAL aaa

Is there additional setting required after creator update?

Thanks for your helps.

 

[Olaf Doschke]

Let me test, I had that update already, too.

CREATE CURSOR crsGen (gRTF G)
APPEND BLANK
APPEND GENERAL gRTF FROM GETFILE("rtf") CLASS "RICHTEXT.RICHTEXTCTRL.1"
MODIFY GENERAL gRTF

Works. So it has nothing to do with the creator update.

If you get Error 4 - End of file encountered, you most probably try to APPEND GENERAL at EOF. APPEND GENERAL does not create a new record, you need to be in a record to be able to APPEND GENERAL.

Bye, Olaf.

 

[kiyo]

Hi Olaf
Thank you for your reply.

I understand that.
There is no error during execution.
I was able to print normally before running Creator Update.
The actual program is as follows.

SELECT PR
APPEND BLANK
APPEND GENERAL MSGR FROM &W2_RTF CLASS "RICHTEXT.RICHTEXTCTRL.1"
GATHER MEMVAR

I am printing the DBF I created here later.

 

[Olaf Doschke]

GATHER MEMVAR might render your general field useless or empty.

Also don't use macro expansion on a file name, if it contains a space in the name or path that will fail.
I still don't think this has to do with the update of windows.

Trying to print the gen field I only get a word icon with the file name of the RTF, but I still don't think this has to do with the Windows update, I see others have reported that error (sorry for pun #1) though it should work in general (sorry for pun #2).

I have Office 2007 installed, but everyday Windows 10 also offers me to test, install or buy their latest Office. This might be connected to this problem. Anyway, I still think it will work with slight modifications. What I found in Tamars 1001 Things is to add the RTF with LINKED and as CLASS "Word.Document" rather than "RICHTEXT.RICHTEXTCTRL.1", but I also saw CLASS "RICHTEXT.RICHTEXTCTRL.1" used.

If you have that same problem we're at the point to be able to reproduce this, but as there were solutions earlier for that symptom, I think it will be solvable by doing things right.

Try, if this works for you, it's a condensed and slightly varied version of and so should work, but it also only shows the word icon preview to me. The report is just having an olebound control set to the gRTF field as its controlsource.

LOCAL lcStr  && Déclarer un variable local 
lcstr = "Note that there is a limit of 32 characters total for the sum of text"+;
"before and text after for simple numbering. Multilevel numbering has a limit"+;
"of 64 characters total for the sum of all levels.NOTE: The file must have a"+;
       ".RTF extension to work properly." && Remplir la variable de texte.

CREATE CURSOR crsGen (mText M, gRTF G)
INSERT INTO crsGen (mText) VALUES (lcStr)

_rtfFile = ADDBS(GETENV("TEMP"))+SYS(2015)+".rtf"  && Créer un instance d’un fichier RTF

SET TEXTMERGE TO (_rtfFile) NOSHOW
SET TEXTMERGE ON
\\{\rtf1 <<ALLT(crsGen.mText)>>}
SET TEXTMERGE TO

APPEND GENERAL gRTF FROM (_rtfFile) CLASS "RICHTEXT.RICHTEXTCTRL.1"
* CD JUSTPATH(GETFILE("frx"))
REPORT FORM genReport.frx PREVIEW

ERASE (_rtfFile)

So, is that reflecting your problem? If so, others might know how to change it.

Bye, Olaf.

Edit: I also tried MODIFY GENERAL and now that doesn't edit the RTF file directly for me, too. I now had to double click and then came out in Word Viewer.

It was not the creator update, which caused this, but an update of the Office trial version package nagging you to test and/or buy Office in any modern flavor. So I guess that hit you, too. Since creators update was before my first tests, I am now sure it wasn't that but another software update. Most likely some update of the trial Office package coming with Win10 caused this. That update just came yesterday to me, and was separate from the creator update! I had a screen telling me "Have a look at your new Office".

 

[Olaf Doschke]

I just changed the association of the RTF file extension back to Word and now both MODIFY GENERAL and the report work again for me.

To summarize: I didn't have the problem after the creator update, but after a later Office update (it seems) as there was a nag screen wanting me to try the newest Office. Seems like that trial version update is changing file associations, even though it's just in the mode to offer demo installation. In my case, the file association changed from Word to Word Viewer, which I had installed a long time ago, too, before installing Office.

So, all in all, I can reproduce at least some similar problem you are facing, perhaps. Perhaps your mileage varies, but it was rather the trial Office update than the Windows update causing this.

Bye, Olaf.

 

[kiyo]

Thank you for your test.

I ran your program.
Copied to dbf at the end of the program.
Fpt created before and after creator update is different.
I am using office 2013.
Is this a file association problem or office 2013 issue?

LOCAL lcStr  && Declarer un variable local 
lcstr = "Note that there is a limit of 32 characters total for the sum of text"+;
"before and text after for simple numbering. Multilevel numbering has a limit"+;
"of 64 characters total for the sum of all levels.NOTE: The file must have a"+;
       ".RTF extension to work properly." && Remplir la variable de texte.

CREATE CURSOR crsGen (mText M, gRTF G)
INSERT INTO crsGen (mText) VALUES (lcStr)

_rtfFile = ADDBS(GETENV("TEMP"))+SYS(2015)+".rtf"  && Creer un instance d’un fichier RTF

SET TEXTMERGE TO (_rtfFile) NOSHOW
SET TEXTMERGE ON
\\{\rtf1 <<ALLT(crsGen.mText)>>}
SET TEXTMERGE TO

APPEND GENERAL gRTF FROM (_rtfFile) CLASS "RICHTEXT.RICHTEXTCTRL.1"
REPORT FORM Report1.frx PREVIEW
COPY TO rtft_a.dbf

Can you see both rtf_b.dbf and rtf_a.dbf?
I only see "grtf" in rtf_b.dbf.
Even if I made CLASS "Word.Document", it was the same result.

 

[Olaf Doschke]

This method intentionally only stores an RTF file temporary in a cursor just in the moment for printing with the OleBound control. Its field name is gRTF, whatever it is in your DBFs. But it pays to only append just in time before reporting. General fields are no good permanent storage of any file type, as associations can break, are different per computer and will thus often only work on one machine. It's the only good use of general fields to provide a temporary source of an ole object to reports, ole objects you can't display in the normal report control.

As I already said I think a trial office update broke file associations. I assume that happened in your case, too. Even if you have an Office installation (as I have, too) Windows 10 contains a pre-step to nag about installing Office 365 or 2016, latest office version. My guess is this trial software offer updates from time to time to be able to make the trial offer for the latest Office, even if you already have an Office version installed, and this corrupted file associations and thus also General field associations. But even more so, also influences the ability to make new General field contents work.

After repairing file association for RTF (associating which application opens RTF files), it again worked for me for newly created General field values. So I just could reproduce your error this day and until I fixed my issue. It worked before as I said in my earlier post and it works again in my last post.

Office reinstallation or repair installation could fix it, in my case just making the file extension association worked, I already said all this, so what is your remaining question? I can't speak for you, as I don't have Office 2013 here, but the point is, this is not a Windows issue, but an Office trial issue. It is related to Win10, as that trial Office offer is not part of earlier Windows versions, but for sure you have a problem anyway if you store files in general fields permanently. It's best practice to avoid general fields but for temporary use. Therefore I see no point in looking at the DBFs you attached anyway.

To make it clear chronological: Everything I said about my observations was true at the time of posting it. I also am talking about the same computer all the time, though I have 4 at hand.
1. At first, I was able to append and modify an RTF up to today. This reflects my computers state yesterday.
2. Today I was able to find some misbehavior, of which I still don't yet know if that also is your problem.
3. I found out a wrong RTF file association and fixing that brings me back to be able to modify and print RTF as yesterday

The only thing I did not try yesterday is printing, but since I could modify RTF within the general field yesterday and also can do so today after fixing file associations, I assume I also could have printed yesterday.

In parallel there is a history of Windows and Office trial offer updates, of which the creator update was already last week, so your assumption surely is wrong, but it has to do with updates silently coming from MS, I had a restart today and an update was reported. I can't know what's exactly wrong on your computer, I can only report what happened here. So perhaps simply check, what happens if you double click an RTF file. Is it opening up in your Office 2013 as it always was? If not, you might have the same problem, if not, the situation differs. But one thing is for sure: It's not the VFP code failing.

In my case candidates for the problem are in the following KB updates: KB3203441, KB3191837, KB3118304, KB4022405, KB3191828, KB3203436, KB3203438, KB3203484, and KB4022405. Most likely none of this will be shown in your update history. The update to the newest creators edition of Windows 10 was on 06/06/2017 for me, and RTF still worked yesterday.

Notice: I don't recommend deinstalling any of the KBs, latest news report MS again distributed updates even for XP to patch issues and again prevent upcoming Wannacry like threats.

I recommend testing your RTF file association is still correct. If that is not your problem a repair installation of Office 2013 might still find something to repair and make new rtf general fields work again.

Bye, Olaf.

 

[kiyo]

Hi Olaf.
I am thankful for your advice.

I confirmed file association before posting individually.
On my computer the rtf file is associated with word 2013.
I have a computer that is not running Creator Update.
This computer is the same model and word 2013 is installed.
Items in the GENERAL field created on this computer can be correctly viewed as rtf files on the computer that executed the creator update.
Therefore, we assume that the association of the computer that executed the creator update is correct.
I doubt that the result of executing append general on the computer that executed the creator update may be registered not in the rtf file.
Perhaps something wrong with file association?
I performed office 2013 repair, but the result did not change.
The program which I was able to print properly until I executed the creator update got wrong?

 

[Olaf Doschke]

Is the problem with data, which already preexisted? Then it's likely you can't fix that. General data is an OLE object, that is suited only for an ole server (viewer/editor) used to display and modify the OLE object. It's not just the binary file or such, so this only works as long as the association does not change during the lifetime of the general field value and therefore such fields are only good for temporary use. The association is not just about the "open", "print" and other DDE actions of a file type, but also about the OLE server class used for the general OLE object.

Most famous broken functionality was with BMP files with OS changes, which needed an ASSOC shell command to fix it. I don't know a similar fix for RTF, but you need to dig deeper than what the Windows Explorer knows as associated application of the file type.

Testing whether new general field values work is important, because it tests, whether you not only have a file association but an association also with the necessary ole server. Very few things (file types, object classes) work in that regime at all, because it's an OLE v1 technology having even less support than OLE automation in general.

Look into your windows update history on both computers and look out for Office KB updates only done on one of them.

Bye, Olaf.

 

[kiyo]

I could not find the difference in the office update.
However, I made a new discovery.
The append general command itself can properly capture the rtf file.
Although I did not display correctly in the preview of the modify general command, I found that the rtf file itself can be modified.
It is a conclusion that calculation of margin of rtf file of genaral field is incorrect.
I can now print "if source and frame are different sizes:" from "Clip contents" to "Scale contents, fill the frame".
thanks Olaf.