KB968409 lattes hotfix for vfp 9.0 sp2 4

[Ernesto_Paez]

Hi everyone,
Does anyone has a way to allow me to get he lattes hotfix for vfp 9.0 sp2, i found a link but it it advising me the page is dangerous.

i am including FoxyPreviewer in my application to print, under the IDE i can select from the FoxyPreviewer menu the options as save, setting etc but once the EXE file is created, these options are like not enabled, so for what i found, that is probably what i need to apply, this KB968409 lattes hotfix for vfp 9.0 sp2 .

i am not able to find a link, does any here please have that file, so can allow me to download it or you have a valid link to allow me to download it
Thanks a lot

 

[atlopes]

Ernesto,

Check the VFPX repository at

https://github.com/VFPX/VFP9SP2Hotfix3.

 

[Ernesto_Paez]

Hi Atlopes
my vfp 9.0 sp2 is version 09.00.0000.7423, will this hotfix will change that version ?
Thanks in advance

 

[Mike Lewis]

I just tried to check the FoxyPreviewer site. But Firefox told me that the site (the entire site) was dangerous. I chose to ignore the warning, and reached the FoxyPreviewer site as usual.

Is that what you saw, Ernesto? I would hesitate to advise anyone to visit a "dangerous" site, but we all know FoxyPreviewer, and as far as I know there have never been any reports of anything untoward about it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Ernesto_Paez]

Hi Mike,
Thanks for the suggestion but one more thing, actually if i get the 968409kb lattes hotfix, that will make vfp 9.0 sp verion 09.00.0000.7423 ? correct ?
and that is exactly my current version
question: so if i already been using vfp 9.0 under that version, if i have to go throughout the readme file instruction, that already did when i installed VFP, is that going to fix the issue i have with the "FoxyPreviewer" not allowing the toolbar options to work?
as i mentioned in my post FoxyPreviewer toolbar are enabled when i test under the IDE environment but once i created the exe, then i use to preview my report, if i try to access the toolbar options that FoxyPreviewer has i am not able to select them.
do you think that could be another issue or could be VFP itself corrupted ?
Thanks

 

[atlopes]

my vfp 9.0 sp2 is version 09.00.0000.7423, will this hotfix will change that version ?

No. Check here for a list of VFP versions:

https://www.berezniker.com/content/pages/visual-foxpro/vfp-90-versions

 

[Ernesto_Paez]

atlopes,
Thanks i was able to download it and reapply it, issued solved thanks a lot

 

[Ernesto_Paez]

Hi Guys,
Again me
after recompiling the exe it runs in the c:\folder but if i recompile the exe and put it on a network drive where only the exe and config and dll files should be, then i get these errorr and not exe run at all .
"Resource file version mistmach" (and i put in the folder network where the exe resides the new VFP9R.DLL and VFP9T.DLL from the download), what else i can be missing ?
i can see also in the same (network folder) where i have the exe, config and new dll files the following "vfp9enu.dll" and vfp9renu.dll but those files where not included in the download.
so what i am missing here or what could be wrong ?
Thanks

 

[Ernesto_Paez]

Sorry, i was missing some dll problem solved.
Thanks

 

[Olaf Doschke]

Atlopes, I don't know to which part of Ernesto's question you said no, but SP2 alone makes VFP9.ee version 9.0.0.5815, only the latest Hotfix makes it 09.00.0000.7423.

It's no sure sign you applied all things in the Hotfix, but you can easily check all file versions and see, whether you forgot to update some. Notice it's again easier to upgrade files of an intallation not done into the program files folder, because that requires write permission and you don't want the DLL and EXE files you replace end up in VirtualStore instead of the real installation folder. It will not be important for your development system to replace files in Microsoft Shared, Installshield Express will default to find the Merge modules in C:\Program Files (x86)\Common Files\Merge Modules, but you could take the fixed one anywhere, if you use it at all. As far as I see you copy the DLLs into the application folder, which is also fine.

When you do Messagebox(_vfp.FullName) this will show the vfp9.exe name when run in the EXE and the path and name of the vfp9r.dll file used at runtime when you run your build exe, so you also see which DLL you're actually using and see whther that's the right one.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[atlopes]

Olaf, Ernesto told us that he was already running version 7423. The hotfix wouldn't change that. So, the answer to his question would be "No.

 

[Olaf Doschke]

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:

http://www.foxypreviewer.com/p/foxypreviewer-documentation.html

DO FOXYPREVIEWER.APP

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

https://www.doschke.name

 

[Ernesto_Paez]

Olaf,
Thanks a lot for taking the time to explain all of that great inside of what is going on that actually the readme file of the hotfix never explained thanks a lot
Ernesto