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.

 

[GriffMG]

Mine are the exact same as yours Olaf

Regards

Griff
Keep [Smile]ing

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

 

[Dan Freeman]

I wish I was at the office today so I could look at several different machines, but on my Win7 machine at home I don't have either of those files. Localization at work?

(But ... who'd ever imagine an Adobe update messing things up? <snark/>)

 

[Olaf Doschke]

At home I have the same C++ runtime files and versions. So that seems normal.
Must be something else, but it can't be any project files, because it compiles fine here at home.
Maybe it's the virus scanner. Avira in the office, MS Security Essentials at home.

I remember I used procmon in the same situation, but it didn't show what choked VFP9.exe at building the exe.

Bye, Olaf.

 

[GriffMG]

Are there any errors in the project erros thing.

I sometimes get a 'buffer overrun' on compilation, the errors point me at a form, I open it, edit the text of a method (any method
it really doesn't matter) and then save the form... after that the compile normally works ok (sometimes I have to open and modify a
number of forms - maybe the longest 'string' was ten).


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]

There's nothing wrong with the project, I took it home 1:1 and here it compiles fully.
office: 730 KB EXE - not working
home: 7.5 MB EXE - OK

It's not that VFP build stops after building the app, there is an EXE, and it's more than the typical stub EXE part loading the runtime, because that is only a few KB, not 730KB.

Bye, Olaf.

 

[GriffMG]

Oh, I see, the process finishes, but you get a duff .exe

Quite a small one too.

I would suspect something environmental then, are the time/dates the same (or similar) on both machines?

Perhaps one isn't compiling all the files?

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]

I also changed build to create APP instead of EXE and the APP is 7.2 MB, far from 730 KB

Now I take to the office with me:
1. The full EXE. Let's see, if Avira sees a virus in there.
2. The debugout log output from the build of the EXE, let's see how far VFP9 gets in the office in regard to the full build log.

Bye, Olaf.

 

[Olaf Doschke]

Interesting findings,

if I compile as APP here in the office, I get the exact same APP file as I took here from home, so that part of compiling works, it's just the EXE creation choking.

Avira is neither reporting a virus in the full EXE, nor in the "duff" exe, nice term, I have to memorize this.

All the debugout ouotput is the same, I also examined the debugout output is the same for the home EXE and home APP I built, so the log does not contain anything about wht's done when turning the APP into EXE (_{you should know, if you compile EXE, nevertheless an APP is first created and turned into the EXE as a last step, you can see that sometimes, a sure sign is, if you first build an APP and then an EXE, the APP will vanish, as it's recreated and then turned into the EXE}).

Bye, Olaf.

 

[GriffMG]

Olaf, use 'duff' anytime you like.

Have you tried deleting the existing .exe before you recompile?
Have you tried naming it differently, or perhaps writing it out to somewhere else?

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]

>Have you tried deleting the existing .exe before you recompile?

I did that anyway, because I need to keep the full EXE. So that also was not the problem.

I did compile with VFP9 installed on pen drive (I have this for years):
no difference (that means duff EXE).

I moved the project to a local drive and compiled with both the C:\Program Files VFP9 installation and the pen drive Foxpro:
no difference.

I compiled with the computer of a collegue and there I get the full EXE, no matter whether I put the project local or compile it located in a LAN drive, as usual.

That's also, why I try to locate the problem somewhere outside the VFP home folder in some system folder, the problem is isolated at my office computer and the easy solution will be to reinstall again, but I'll not want to reinstall every now and then I come across that problem, I would like to identify the root cause, of course.

Bye, Olaf.

 

[Olaf Doschke]

Now it get's awkward, because I can compile other projects with the VFP9 installation here in the office.

So if it's in the project after all, what could it be? Some reference to a project file missing on my computer or on all other computers, which hinders completing the EXE? I cannot imagine, that this wouldn't cause an error or warning or would go without further notice in creating the intermediate APP file fully and correctly, too.

checking file locations...

LOCAL loFile

CLEAR 
FOR EACH loFile IN _vfp.activeproject.Files
    If ADir(laDummy, loFile.name) = 0
       ? "File not Found:", loFile.name
    EndIf 
    
    If NOT (loFile.name = JustPath(_vfp.activeproject.Name))
       ? "File not within Project Home Folder:", loFile.name
    EndIf     
ENDFOR

No output from that, so all files of the pjx are present and there is no refrence to any location only available on my or other pcs, the project folder is self contained.

By the way, I didn't answer the question about system time: no it's normal on all involved machines, current time, I also checked the right time zone is set, there is no mismatch about that.

I have no clues anymore. I'll try rebuilding the pjx, keeping the current one safe.

Bye, Olaf.

 

[GriffMG]

Have you tried 'cleaning' the project - or just opening the .pjx and packing it?

Alternatively, you could open a new project and copy the contents across?

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]

Of course, yes. I packed the pjx, and rebilding a project means copying contents across. It's a rather complicated folder schema, so it's not that simple, but I'll see where it ends later.

Bye, Olaf.

 

[TamarGranor]

Is there a projecthook class involved? Could that be playing into this somehow?

Tamar

 

[Olaf Doschke]

Projecthook: Not yet, but there was one.

I have rebuilt the pjx half automatic and half manually by adding whole folders, but as said the folder structure is a bit complicated.
Nevertheless I now have more files included than originally and still the pjt file is smaller, that shouldn't be the case, even considering memo bloat, clear/pack of the project should remove that.

What I didn't yet test is foxuser, of course a thing differing only at other PCs. I'll let you know later, if that was it.

Bye, Olaf.

 

[Olaf Doschke]

Deleting Foxuser.dbf didn't solve it. It would have been too easy...

Now the fun reall begins for those, who like puzzles:

What I did now is rebuild the pjx programmatically (in this complex project it's insufficient to add main.prg and compile to let VFP add files at build):

Local loPJX, loSrcPJX, loDestPJX, loFile, lcNewFile

If _VFP.Projects.Count<>2
   ? "Please open source project and a new, empty project"
   Return .F.
EndIf

For Each loPJX In _vfp.Projects
   If loPJX.Files.Count=0
      loDestPJX = loPJX 
   Else   
      loSrcPJX  = loPJX 
   EndIf
EndFor       

If (Vartype(loSrcPJX) + Vartype(loDestPJX) == "OO")
   If MessageBox("Source:"+loSrcPJX.Name+Chr(13)+;
   "Destination:"+loDestPJX.Name+Chr(13)+;
   "Is that correct?",4+256,"Question")<>6
      Return .F.
   Else
      ? "OK, let's move."
   EndIf 
Else
   ? "The source Project should not be empty AND the destination Proejct should be" 
   Return .F.
EndIf

For Each loFile in loSrcPJX.Files
   lcNewFile = Strtran(Strtran(loFile.Name,"e:\","d:\"),"E:\","d:\")
   loNewFile = loDestPJX.Files.Add(lcNewFile)
   loNewFile.Exclude = loFile.Exclude
Endfor

For sake of simplicity I moved the whole project folder to another drive manually in advance, copied from drive E:\ to drive D:\, so all new file names would only differ in their drive letter.

So the only files I did not move where the pjx/pjt and rebuilt them by using Project.Add() method to add file and also set the Exclude state of files of the new PJX as needed.

There are some minor changes, which need to be done manually in project info, afterwards, eg attach the application icon file.

I compiled the new project and voila, it worked. And now the puzzle: Only once.
I did recompile again, because I forgot to uncheck debug info and the size of the EXE was about double the normal size. After I unchecked and recompiled, size waas back to the faulty 730KB and now even setting debug info on does not resurrect the project.

What's happening here?

Bye, Olaf.

 

[GriffMG]

Did you copy your new project before you compiled it?

Quite a conundrum you have there.

Regards

Griff
Keep [Smile]ing

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

 

[GriffMG]

I would be tempted to repeat the process, copying the 'ready to go' version before compiling
and then look and see what files get changed by the build process.

Perhaps that will give you a clue, or at least a 'quick restore' (copying the files that are changed
by the build from the copy of the 'ready to go' version).

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]

Solved!

You couldn't have guessed it, it was the OLEPUBLIC classes of the project making the build fail.
That explains everything!

First compilation works, because then the Servers Tab in the project info is empty and ole server classes info is added during first build. Second build tries to put olepublic clases into the ffinal EXE and register them, that must stop the process.

That also explains, why an APP file works, there is no handling of OLE Servers, when you compile an APP.

That does not explains why reinstalling VFP worked, but in fact I asked admin, and he didn't reinstall, he refreshed my PC from an image, so registry was also reset, not only VFP9 itself.

That's it!

So if you encounter the same problem of a EXE build failing, look out for OLEPUBLIC classes. I had two in my project, one I don't use, one I added myself experimentally added for OLE automation of my own app.

I now unchecked olepublic in the two involved classes and can compile again, as many times as I need.
I'll star some of your suggestions anyway, thanks you for your attention!

Bye, Olaf.