Thanks to Gianni for giving me the idea which led to the solution.
Gianni had written this:
> that at the return from "report form ..." the curdir() was changed to
> something like C:\Windows\System32.
That got me to thinking perhaps the default folder was changing for some
unknown reason. It was not. The path remained the same. However, in testing,
I wondered what would happen if I explicitly defined the path & filename in
the AGETFILEVERSION() command. As the code was written, I got the filename
from the ADIR() command but the array of filenames returned does not include
the full path. I decided to try re-writing the line for AGETFILEVERSION()
like this:
lnElements = AGETFILEVERSION(laVersInfo, ADDBS(SYS(5) + SYS(2003)) +
laPrograms[m.lnLoopCnt,1])
And it worked perfectly even after getting a connection handle to the Oracle
database! I exited my form multiple times and it continued to work as
expected. However, when I issue the AGETFILEVERSION() without the full path
included, it starts to fail again.
So I've updated my class method to include the explicit full path which will
be backwardly compatible with all my previous code and I learned a valuable
lesson:
"When in doubt, get explicit!"
Thanks for everyone's help on this! It was definitely appreciated!
Paul H. Tarver
-----Original Message-----
From: ProfoxTech [mailto:[email protected]] On Behalf Of Paul H.
Tarver
Sent: Wednesday, May 02, 2018 11:41 AM
To: [email protected]
Subject: RE: AGETFILEVERSION Fail
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:[email protected]] On Behalf Of Paul H.
Tarver
Sent: Wednesday, May 02, 2018 11:28 AM
To: [email protected]
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:[email protected]] On Behalf Of Gianni
Turri
Sent: Wednesday, May 02, 2018 10:51 AM
To: [email protected]
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 <[email protected]>
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" <[email protected]> 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:[email protected]] On Behalf Of Ted
Roche
Sent: Tuesday, May 01, 2018 2:38 PM
To: [email protected]
Subject: Re: AGETFILEVERSION Fail
On Tue, May 1, 2018 at 3:23 PM, Paul H. Tarver <[email protected]> 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: [email protected]
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/[email protected]
** 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.
