incomplete VFP build 2

[Olaf Doschke]

A few weeks ago I had a build problem with VFP9, which I solved by a reinstall. I think I posted about it, but I don't find my post. It came back, now. Build process does not fail, debugout also does not stop somewhere in the middle of the pjx.

I have a suspicion some software update (today from adobe flash) causes an update of the C++ runtime in the SYSWow64 folder. To verify that suspicion I here embed the screenshot of the runtime files installed here:

It's already a bad sign the files differ in their version, I fear the VFP IDE build chokes at some point due to these runtimes not being the ones originally installed with VFP9. What are your versions of the above two files? (On 64 bit Windows look in SysWow64, on 32bit Windows in system32, to display the version right click on the header liine of the detail view of windows explorer and add "product code" as a furhter column).

TIA

Bye, Olaf.

 

[Olaf Doschke]

Griff, in retrospective you had the best ideas and steps to try and do. Kudos for that.

And also your last idea, keeping track of files changing during build, would be a good idea in general, to find the offending file. In case of the ole public classes these two files actually did change, so that would have pointed in the right direction, too.

Bye, Olaf.

 

[GriffMG]

Thank you, just trying to help you through a 'mindfield' (rather than a minefield)



Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[Olaf Doschke]

In this case both, perhaps. Thanks again.

Bye, Olaf.

 

[TamarGranor]

Olaf - just out of curiosity, does it work with the OLEPublics if you run VFP as Administrator?

Tamar

 

[Olaf Doschke]

Sorry Tamar, I can't answer that, as I don't have an admin account at the office, I would need to ask someone to grant me that, before I could try.

My experience so far (for years) was, that it won't matter, if VFP can't register an OLE public class, if you run VFP non admintrative, a build would still create a complete EXE, which contains the OLE class for registration, this class (or these classes) just won't be registered.

So it has either got to do with the fact, these classes were already registered (I saw references to them in the registry, at least I can read the registry even with normal privileges) and updating already existing registry entries does fail, or moe likely, my registry is kind of broken somehow.

I know it doesn't sound very plausible, because I also assumed so far, VFP would first create the EXE file completely and then register, because registration would read infos from inside the EXE (or DLL). Only some VFP team member can tell what really happens at build time and if my observations are plausible, at least you can le VFP also create a tlb file seperate and this could be done in advance. The registry entries won't point to a certain byte offset in an EXE anyway, so they could be written in advance to writing a part of the EXE file.

What I can say is that removing the data from memo field "Reserved2" of the first PJX record (type H) also solved the non "compilability" of the original PJX and this is, what I finally did as the only step in that original PJX. It can't be an effect of copied files striping off additional file streams or anything creepy in that direction. The only final difference between non working and working build was the editing of that Reserved2 memo in record 1, no more, no less.

Bye, Olaf.

 

[Olaf Doschke]

>no more, no less.

Wrong. Well, of course I also removed the OLEPUBLIC check from the involved classes so next build won't recreate the data in the Reserved2 memo.

Bye, Olaf.