Subject Re: silent failure of the compiler From Ken Mayer <dbase@nospam.goldenstag.net> Date Fri, 18 Sep 2020 14:22:57 -0700 Newsgroups dbase.getting-started On 9/18/2020 2:14 PM, Gaetano wrote: > > 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? The app would only be able to look in the DEO paths if they are defined in the .ini file.  It looks in the folder that the .exe is for the compiled object as a default, because many applications deploy things this way. It is a handy way to update code. > > 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... I didn't write the rules, just explaining them. The reason for doing it this way is: You build the executable and compile the objects into the .exe. Okay, what if you need to make a single change to a form, program, whatever, and you don't want to have to recompile and re-deploy the executable to fix that one issue? You copy the compiled object into the folder, and the executable sees that version and runs it, instead of the one built into the .exe. It really does make sense to do it that way. Ken -- *Ken Mayer* Ken's dBASE Page: http://www.goldenstag.net/dbase The dUFLP: http://www.goldenstag.net/dbase/index.htm#duflp dBASE Books: http://www.goldenstag.net/dbase/Books/dBASEBooks.htm dBASE Tutorial: http://www.goldenstag.net/dbase/Tutorial/00_Preface.htm