Subject Re: silent failure of the compiler From Gaetano <gaetanodd@hotmail.com> Date Sat, 19 Sep 2020 07:14:09 +1000 Newsgroups dbase.getting-started Hi Ken, Thanks. So essentially you are saying that every compiled app is a DEO app even if you didn't compile it as a DEO through a project with the Object Paths defined? If that is the case, it may not be a bug, but in my opinion if a user doesn't positively decide to use DEO (i.e. no Object path defined in the "active" INI file), the compiled app should look in the executable first. This is because DEO is a specific architecture and when you use DEO, you know that this is how it works, and if you don't know about DEO and you are not aware that your are using it by default, well, the avenue of checking for objects in DEO default paths for troubleshooting is simply not in your mind... Just my non-professional opinion of course, so take it for what it's worth :) Cheers, Gaetano. On 18/09/2020 23:12, Ken Mayer wrote: > On 9/17/2020 10:13 PM, Gaetano wrote: >> >> OK, so deleting the PRO forced recompilation of the PRG, but I still >> had the same error ( I thought I had landed in virus territory), so I >> checked the target folder of the executable and there was a >> DATAINTEGRITY.PRO file in that folder and it seems that dBase was >> using that external PRO file instead of what was included in the >> executable. Once I deleted that obsolete PRO, the one in the >> executable got used and the program completed successfully. >> >> Does the EXE first look externally for required objects? Has this >> always been the case or is it something introduced with DEO? > > In Chapter 26 of The dBASE Book, I put together the sequence (based on > conversations with the folk at dBASE) that dBASE itself looks for the > necessary files. > > 1) It looks in the folder with the .exe (the home folder) for the object > (.pro, etc.), if found it executes the object file and stops looking. > 2) If it does not find it in the home folder, it looks in the .ini file > for the DEO object path entries -- if found, it executes the object file > and stops looking. > 3) It looks internally -- in the .exe to find the compiled object and if > found, executes it. If not found, an error occurs, telling you (or your > user) that the object file cannot be found. > > It helps to understand how this works ... > > Ken > > >