Windows 10 will Not Display General Field Content RRS feed

  • Question

  • We are staring to use Windows 10 in our company. I have a VFP application that uses the Append General command when using the Report Writer. The report field I have set up in the report to display a rtf file is not displaying. The rtf can be text only or image or combination. None of them will display.
    Monday, October 8, 2018 6:49 PM

All replies

  • General fields require you to have the right application installed, the one the data is linked to. You need to make sure you do that.

    Better is to never, never, never use General fields. This is why.


    Monday, October 8, 2018 8:11 PM
  • While Tama is right, this use of General Fields for OleBoundcontrols in Reports is one of the very scare valid reasons to use General fields I can think of.

    Still the basis for this will be the RTF control, it's not natively present in Win10, it will likely not even be installed with Word, so you need to bring it in. Just like a missing ActiveX control.

    redist.txt (in VFPs Home() directory) lists there related merge modules:


    They are insalled by VFP in your development machine in C:\Program Files (x86)\Common Files\Merge Modules

    Create a setup that uses them to be able to make use of the RTF control in reports.

    Bye, Olaf.

    • Proposed as answer by mplaza Wednesday, December 5, 2018 1:00 AM
    Monday, October 8, 2018 9:07 PM
  • Create a setup that uses them to be able to make use of the RTF control in reports.

    Thank you very much for your response. Can you explain what you mean here please? Do I put these files in the run time directory along with the rest of the files downloaded for each instance? Do these files go into the System32 folder of the machine that will be running the reports?

    Tuesday, October 9, 2018 12:39 PM
  •  Merge modules are used by installers to install some software, they themselves do nothing. You need to zse an installer using the MSI (MS Installer) system, so for example Installshield. Inno Setup does not do that.

    Read up on Merge Modules -

    Any computer needing the RTF control then needs this setup run once.

    It's not sufficient to put some files somewhere.

    And notice: The installation and registration of the RTF control is the minimum requirement for olebound rtf control of your report to appear and render correctly. It still could fail for any other reason and part of the puzzle missing.

    I can just confirm on my development Windows 10 PC I can use RTF Gen fields to feed an olebound report control, so Windows 10 is not the factor. At my PC the RTF control simply is installed because Foxpro is installed and that registers all the ActiveX controls you're allowed to use and redistribute via the merge modules I showed, VFP also installs them so you can create respective setups.

    RTF once was a very commonly available control but today not even if MS Office is installed. And it surely isn't coming with Windows itself, not even MS Common Controls are part of Windows since Vista.

    Besides, while tha major pain with Gen fields is to depend on a specific OLE server to exist at the computer using it, and not just any software associated with a file extension or this ole class, this makes Gen fields unstable against transfer to other computers or against time, against updates changing that even on the computer the Gen field value originated in. But usage in a report means using a temporary Gen field, that in itself will always either work or already fail at appending the OLE object. APPEND GENERAL genfield FILE rtffile works for me with an olebound report control with that field as controlsource. 

    So it's foable, it's viable, it doesn't break, unless you rely on standards like the RTF control, which were standrads on XP and worked longer for customers having their office, but aren't anymore.  You always will have to look into what dependencies you have and provide them in a setup able to do things like registering ActiveX.

    Bye, Olaf.

    Friday, October 12, 2018 6:01 PM
  • Could you help me to get started on this please?

    The VFP application I have created is an exe type. The exe resides on a network share. I have a launcher application also that the end users access. This launcher checks the version of the exe on the share against a copy of the exe on their computer. If the exe does not exist or is older than the share exe the launcher copies the exe along with necessary runtime files to their local computer.

    How would I incorporate the merge module installer into this scenario?

    Again where do I start to get this working?

    Thanks for your consideration. 

    I wanted to add: I created this application 15 years ago, we have used it on Windows 95, NT, XP, 7. But now 10 is giving us issues.
    • Edited by SLDyke Tuesday, December 4, 2018 4:45 PM Added info
    Tuesday, December 4, 2018 3:57 PM
  • What hasn't become clear? An OCX has to be registered. That needs adminstrative permission. You can't use this loader meachnism to add RICHTX32.OCX and dependencies. You relied on things being available from the OS, which now are not. VFP comes with the royalty free usage of some OCXes, but you have to install them, they shouldn't go into your app folder but into syswow64, to which you can't just xcopy things anyway, you need an installer.

    There is a thing called regfree com, that would "just" need a your.exe.manifest file with XML pointing out dependencies to some OCX file, but this isn't a solution for all OCX or COM servers, dependencies are often more complicated. I'd go with an installer.

    Bye, Olaf.

    Wednesday, December 5, 2018 8:10 AM
  • Hello,

    as Olaf mentioned you will need an installer.

    There is also Innosetup, which is not so hard to use, in the paper from dough (see link) you find explanation and a sample including installing richt32.ocx.

    Maybe you can change it to install only the richt32.ocx (or do it with a "dummy.exe"). There is a lot of help on innosetup and vvp , for example on

    Best regards


    Wednesday, December 5, 2018 9:00 AM