I have understood problems are solved all is good and done and said. Still, let me point this out, as it's very generally true.
First, atlopes,
OK, then you're relying on Ernesto having done all the steps. That in itself is not too laissez-faire, ie it would even be inappropriate to assume Ernesto forgot a step. But as the overall problem is at runtime, you know even if that's fine that's not all there is to it And once you have a problem, why not recheck?
To take that question very strictly, Ernesto wanted to be ensured when the Version() function or the Version number the info splash window "About Microsoft Visual Foxpro" or the vfp9.exe file version are saying 09.00.0000.7423, then he has that version. No, this only proves the vfp9.exe file was upgraded, no more, no less. All three things are only about the vfp9.exe, not what vfp9r.dll you still have in the VFP folder within Microsoft Shared. Or in the merge module. Doug Hennig (or was it Rick Schummer) reported relatively early after a Hotfix release, that the first release of it didnÄt contain an upgraded merge module. Using that you would provide the wrong runtime version. The list on Bereznikers website sill points out for a short time such a wrong Hotfix existed.
All in all, only checking Version(), Splash screen or file version is relying on other things done correctly, especially also in the release of the EXE and DLLs provided with it and then, last not least, it relies on FoxyPreviewer initialization being done, though that is separate from a wrong DLL version.
-------------------
Ernesto,
If you expect the info you see to be relevant to IDE and your runtime you must think Version is checking all files on your system. No, it does not. So for future reference and to be absolutely sure, check the version of the DLL file your own EXE tells you it uses with _vfp.Fullname, then you know with which version you run at runtime. It's not automatic or built into your EXE. This is nothing new in VFP9, this was always true for Visual FoxPro, any EXE you build still needs a runtime as a separate DLL file, it's not standalone. The IDE runtime just ensures the compiled object code has the opcodes of that VFP version, it is not building a complete and independent EXE, no programming IDE does. Dotnet needs a Dotnet Framework, Even C++ exes need their C runtime DLL.
Any complication you have with any EXE you build, no matter whether report related or otherwise, could be a wrong runtime DLL version, still. And both the runtime and the IDE can play into the problem, as it can come in at compilation and at execution. But even reassuring you did all steps the Hotfix instructions asked you to do, you also need to provide the upgraded runtimes with the final build and do initialization óf components you use.
So, the complication could still have been an outdated DLL. Your EXE will not check which exact version that runtime DLL is, it's only required to be any vfp9r.dll version, be it 9.0.0.7423, too or any version down to the original (SP0) version 9.0.0.2412. So VFP executables only ensure they have the right main runtime version (besides all related DLLs necessary, but that's not the point here). The FoxyPreviewer.APP will use that exact same DLL as its an app and not a separate process, it runs in your process. On several occasions, I reported I got C5 exceptions from using a non-matching vfp9r.dll at runtime, so this is a delicate issue not handled rigorously if you don't do so. You might not get problems with any of your own code, but the SPs and Hotfixes fixed reporting issues, of course, so it becomes important using FoxyPreviewer.APP in a project your own project also is upgraded to that VFP9 version.
When that is out of the way and we rely on the fact you applied the Hotfix correctly and you didn't forget to also put the upgraded runtime files into your released EXE installation folder AND they are actually used (indeed a local DLL file is prioritized). Then there still remains what is very FoxyPreviewer specific. But it's not very much, I mean, the documentation is really very simple on this topic:
It could not be much simpler, it could only be automatic, but even when FoxyPreviewer would be three APP files as the usual 90 report engine is, ReportPreview.APP, ReportOutput.APP, and ReportBuilder.APP, this wouldn't mean the runtime would automatically use them. Early versions of FoxyPreviewer were and still needed initialization.
Even native reporting with the 90 report engine requires more than SET REPORTBEHAVIOR 90, APP files of the IDE s are not included in your EXE or the vfp9r.dll, so that's even true without FoxyPreviewer. That's not special knowledge you miss about it if you don't know, then that's knowledge you miss since VFP9 came out. The only thing also true is, you can report without any APP, the vfp9r.dll contains a reporting engine, but only the legacy reporting Mode 80.
And while we're at that: Even before both FoxyPreviewer and the 90 engine existed, you could modify the report preview toolbar in the legacy report engine. There were things you could do with the FoxUser.dbf, but that had to be released with the EXE, too, then, you would get a new fresh default foxuser.dbf from your application.exe (actually the vfp9r.dll runtime would create that file unless a config.fpw didn't specify resource=off). So that's also not automatic. OK, here I can unbind you from this old knowledge you should have, that's the past about reporting, the FoxyPreviewer engine uses a completely own toolbar class, it does not extend or modify the original report preview toolbar.
In the EXE the FoxyPreviewer.APP file has to be in your application folder on top of everything you need for any vfp9 built EXE. Foxypreviewr.APP is not working with older runtimes, if you'd want to use older VFP9 SP0 or SP1 you could, but then you'd also better recompile the foxypreviewer.pjx. No, don't do so. It's fine you're on the SP2 with the latest Hotfix level. That's also what the FoxyPreviewer team uses to build its APP. If you're bound to use no Hotfix (some companies have such policies, for example, you could still use the precompiled APP, but to technically assure it's in sync with that, you would technically be able to recompile the source.
And then, last not least the initialization of it also has to be done. And so, in the end, indeed your version display in the IDE will not guarantee you have everything at hand and in the right place and initialized correctly at runtime. If there's something not running as expected it's a sign to recheck you did every step and also have the upgraded files in the setup and do the necessary initialization code. That's nothing special, that's advice always valid.
------------------
Just by the way: If you run APP code you can even run VFP9 compiled code with a VFP7 runtime, I did allow that intentionally for a shared library used as APP instead of EXE or DLL and limited it to using VFP7 runtime compatible code, as it was shared in a landscape of multiple applications partly dating back to VFP7 (That was about 2006, VFP9 was relatively young).
So once more: VFP is not very rigorous with the exact version used and even with the info, it shows in the IDE. You have to be rigorous. Especially as a Hotfix is not simply a setup you run, but just un extracting archive of files and instructions about manually upgrading them. And that in itself has its pitfalls in UAC. The instructions also don't point out you also need to forward this to your released EXE, because it is natural, the instructions are not addressing an end-user, they address you, a developer.
Bye, Olaf.
Olaf Doschke Software Engineering
