Frank, you were on the right track and I really appreciated your suggestions! Gianni just pointed me in that direction a little sooner.
I don't know what the connection changes once you get a handle, but apparently AGETFILEVERSION() requires the full path & filename in order to return the proper information in ALL scenarios. Even though the Foxpro documentation says that the path is optional, that is clearly not the case in every situation. Thanks again! Paul H. Tarver -----Original Message----- From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Frank Cazabon Sent: Wednesday, May 02, 2018 12:16 PM To: profoxt...@leafe.com Subject: Re: AGETFILEVERSION Fail What is the file name being passed to AGETFILEVERSION() when it fails to return anything? What is the current directory at this point in time? I believe there was a WinAPI version of this function, can you use that instead of AGETFILEVERSION() and see if it makes a difference? Frank. Frank Cazabon On 02/05/2018 12:40 PM, Paul H. Tarver wrote: > After some further testing, I determined that mis-spoke when I said that > AGETFILEVERSION() was returning an empty string and not an array. > > What it is actually doing is returning NOTHING. If I remove the LOCAL ARRAY > line from the routine, I found that the once the connection is made, > AGETFILEVERSION() does not even create the array once a connection handle to > the Oracle ODBC driver is obtained, AGETFILEVERSION() simply fails without > error, without creating an array, but it does return a 0 as the number of > elements. > > Paul H. Tarver > > > > -----Original Message----- > From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Paul H. > Tarver > Sent: Wednesday, May 02, 2018 11:28 AM > To: profoxt...@leafe.com > Subject: RE: AGETFILEVERSION Fail > > I checked the array generated from ADIR() in my code and it is returning the > proper list of EXE files found in the folder. But I'm thinking I want to do > some more testing with your idea about the directory or path changing after > we get a connection to the ODBC driver or something like that. I'll post > more once I chase that rabbit. > > As I mentioned in another response the weird thing is AGETFILEVERSION() is > supposed to always return an Array, but once we make a connection to the > Oracle ODBC driver, AGETFILEVERSION() simply returns an empty string. Not an > empty array, an empty string. > > On top of that, I cannot for the life of me figure out what would > AGETFILEVERSION() have in common with and ODBC connection. I'm sure that > where they overlap will be where the problem lies, but I can't figure out > where those two functions would overlap. > > Thanks for the idea though! > > Paul H. Tarver > > > > -----Original Message----- > From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Gianni > Turri > Sent: Wednesday, May 02, 2018 10:51 AM > To: profoxt...@leafe.com > Subject: Re: AGETFILEVERSION Fail > > Hi Paul! > > If the current directory ( curdir() ) changes to something like > C:\Windows\System32 > your array gets populated by many exe's but not the exe's you expect from > your application directory, > because in you code you load adir() with exe's from the "current" directory. > >> lnExeNumber = ADIR(laPrograms, '*.EXE') > Gianni > > -----Original Message----- > On Wed, 02 May 2018 02:47:00 +0200, Gianni Turri <gianni...@gmail.com> > wrote: > > Hi Paul! > > I remember many years ago when printing to pdf using the Adobe Acrobat > printer driver > that at the return from "report form ..." the curdir() was changed to > something like C:\Windows\System32. > > Are you sure it is not happening something similar? > > Gianni > > -----Original Message----- > On Tue, 1 May 2018 15:23:55 -0500, "Paul H. Tarver" <p...@tpcqpc.com> wrote: > > Thanks Ted. > > The code I'm using now is how I determine the name of the compiled > application and once it returns the correct .EXE name, we then look for an > .INI file with the same JUSTSTEM() where our settings are. The code works > whether compiled or in the IDE and the only requirement is that I have at > least one copy of the compiled .exe file in the development folder. > > I know I can hard code that easily enough, but because I have so many > projects and they often have different compiled names, so the logic of > looking in the app folder for an .EXE with 'MAIN PROGRAM' in the file > version information makes the method to retrieve the JUSTSTEM('exe name') a > simple prospect and has worked since version 6. > > First time I've ever had a problem with it and that's only after the second > time I get a handle to the Oracle database via the Oracle ODBC driver. Weird > stuff. > > Thanks for the suggestions though. I may end up refactoring this whole > process anyway because of this weirdness. > > Paul H. Tarver > > > -----Original Message----- > From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Ted > Roche > Sent: Tuesday, May 01, 2018 2:38 PM > To: profoxt...@leafe.com > Subject: Re: AGETFILEVERSION Fail > > On Tue, May 1, 2018 at 3:23 PM, Paul H. Tarver <p...@tpcqpc.com> wrote: >> The reason for this code is to identify the application .EXE. Perhaps > there >> is a better way to identify the application name that will eliminate the >> need to use AGETFILEVERSION() to identify the main .exe file for the >> application. >> > You might consider PROGRAM(), the venerable SYS(16) or the (new to > VFP7) AStackInfo(). > > https://www.tedroche.com/hackfox7/s4g120.html > [excessive quoting removed by server] _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/046e01d3e23b$0868f380$193ada80$@tpcqpc.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
