AGETFILEVERSION Fail

[Paul H. Tarver]

Has anyone ever had any problem with AGETFILEVERSION() failing to return
values after an ODBC connection is made?



I'm using the Oracle ODBC Driver and until the SQLCONNECT() command is
issued AGETFILEVERSION() works perfectly. After I issue the SQLCONNECT()
command and get a valid handle, AGETFILEVERSION() will not return any
values. I have to exit VFP and restart it, then, AGETFILEVERSION() works
again until I make another connection to Oracle via ODBC.



I've used the Oracle's ODBC driver previously with no ill affect. But
now.Grrrrrr!



Paul





--- StripMime Report -- processed MIME parts ---
multipart/alternative
text/plain (text body -- kept)
text/html
---

_______________________________________________
Post Messages to: ***@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/036b01d3df20$1be8b760$53ba2620$@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.

[Frank Cazabon]

Paul,

what's the code you are using?

Frank.

Frank Cazabon

Post by Paul H. Tarver
Has anyone ever had any problem with AGETFILEVERSION() failing to return
values after an ODBC connection is made?
I'm using the Oracle ODBC Driver and until the SQLCONNECT() command is
issued AGETFILEVERSION() works perfectly. After I issue the SQLCONNECT()
command and get a valid handle, AGETFILEVERSION() will not return any
values. I have to exit VFP and restart it, then, AGETFILEVERSION() works
again until I make another connection to Oracle via ODBC.
I've used the Oracle's ODBC driver previously with no ill affect. But
now.Grrrrrr!
Paul
--- StripMime Report -- processed MIME parts ---
multipart/alternative
text/plain (text body -- kept)
text/html
---

[excessive quoting removed by server]

_______________________________________________
Post Messages to: ***@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/f10e9575-9071-dc1b-817b-***@gmail.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.

[Paul H. Tarver]

Frank,

Sorry for the delay in responding. Here's the basic code I'm using:

m.plFileDesc = "MAIN PROGRAM"

lnExeNumber = ADIR(laPrograms, '*.EXE')
=ASORT(laPrograms,3,-1,1)

leRetVal = ''

IF m.lnExeNumber > 0

FOR lnLoopCnt = 1 TO m.lnExeNumber

lnElements = AGETFILEVERSION(laVersInfo,
laPrograms[m.lnLoopCnt,1])

IF m.lnElements > 0

IF UPPER(ALLTRIM(laVersInfo(3))) ==
ALLTRIM(m.plFileDesc)

leRetVal =
ALLTRIM(laPrograms[m.lnLoopCnt,1])
EXIT

ENDIF

ENDIF

ENDFOR

ENDIF

Here's the logical process:

1) Start Foxpro, run form, get connection handle to Oracle via ODBC and the
code above works perfectly.
2) Exit form (without closing Foxpro) and restart form and though we get a
valid array from ADIR() but AGETFILEVERSION() returns ''
3) Exit Foxpro, restart and GOTO back to step 1

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.

Paul

-----Original Message-----
From: ProfoxTech [mailto:profoxtech-***@leafe.com] On Behalf Of Frank
Cazabon
Sent: Sunday, April 29, 2018 4:26 PM
To: ***@leafe.com
Subject: Re: AGETFILEVERSION Fail

Paul,

what's the code you are using?

Frank.

Frank Cazabon

Post by Paul H. Tarver
Has anyone ever had any problem with AGETFILEVERSION() failing to return
values after an ODBC connection is made?
I'm using the Oracle ODBC Driver and until the SQLCONNECT() command is
issued AGETFILEVERSION() works perfectly. After I issue the SQLCONNECT()
command and get a valid handle, AGETFILEVERSION() will not return any
values. I have to exit VFP and restart it, then, AGETFILEVERSION() works
again until I make another connection to Oracle via ODBC.
I've used the Oracle's ODBC driver previously with no ill affect. But
now.Grrrrrr!
Paul
--- StripMime Report -- processed MIME parts ---
multipart/alternative
text/plain (text body -- kept)
text/html
---

[excessive quoting removed by server]

_______________________________________________
Post Messages to: ***@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/061901d3e181$d9a7cd00$8cf76700$@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.

[Ted Roche]

Post by Paul H. Tarver
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
--
Ted Roche
Ted Roche & Associates, LLC
http://www.tedroche.com

_______________________________________________
Post Messages to: ***@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/CACW6n4vzPbpYC++=1HR2sJgt_gWBw0BoXxWCYmFwoTMm-***@mail.gmail.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.

[Paul H. Tarver]

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-***@leafe.com] On Behalf Of Ted
Roche
Sent: Tuesday, May 01, 2018 2:38 PM
To: ***@leafe.com
Subject: Re: AGETFILEVERSION Fail

Post by Paul H. Tarver
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
--
Ted Roche
Ted Roche & Associates, LLC
http://www.tedroche.com

[excessive quoting removed by server]

_______________________________________________
Post Messages to: ***@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/067e01d3e18a$5445e6c0$fcd1b440$@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.

[Gianni Turri]

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" <***@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-***@leafe.com] On Behalf Of Ted
Roche
Sent: Tuesday, May 01, 2018 2:38 PM
To: ***@leafe.com
Subject: Re: AGETFILEVERSION Fail

Post by Paul H. Tarver
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

_______________________________________________
Post Messages to: ***@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/***@4ax.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.

[Gianni Turri]

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.

Post by Paul H. Tarver
lnExeNumber = ADIR(laPrograms, '*.EXE')

Gianni

-----Original Message-----
On Wed, 02 May 2018 02:47:00 +0200, Gianni Turri <***@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" <***@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-***@leafe.com] On Behalf Of Ted
Roche
Sent: Tuesday, May 01, 2018 2:38 PM
To: ***@leafe.com
Subject: Re: AGETFILEVERSION Fail

Post by Paul H. Tarver
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

_______________________________________________
Post Messages to: ***@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/***@4ax.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.

[Paul H. Tarver]

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-***@leafe.com] On Behalf Of Gianni
Turri
Sent: Wednesday, May 02, 2018 10:51 AM
To: ***@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.

Post by Paul H. Tarver
lnExeNumber = ADIR(laPrograms, '*.EXE')

Gianni

-----Original Message-----
On Wed, 02 May 2018 02:47:00 +0200, Gianni Turri <***@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" <***@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-***@leafe.com] On Behalf Of Ted
Roche
Sent: Tuesday, May 01, 2018 2:38 PM
To: ***@leafe.com
Subject: Re: AGETFILEVERSION Fail

Post by Paul H. Tarver
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: ***@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/03d301d3e232$922d7090$b68851b0$@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.

[Paul H. Tarver]

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-***@leafe.com] On Behalf Of Paul H.
Tarver
Sent: Wednesday, May 02, 2018 11:28 AM
To: ***@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-***@leafe.com] On Behalf Of Gianni
Turri
Sent: Wednesday, May 02, 2018 10:51 AM
To: ***@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.

Post by Paul H. Tarver
lnExeNumber = ADIR(laPrograms, '*.EXE')

Gianni

-----Original Message-----
On Wed, 02 May 2018 02:47:00 +0200, Gianni Turri <***@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" <***@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-***@leafe.com] On Behalf Of Ted
Roche
Sent: Tuesday, May 01, 2018 2:38 PM
To: ***@leafe.com
Subject: Re: AGETFILEVERSION Fail

Post by Paul H. Tarver
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: ***@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/042001d3e234$54251710$fc6f4530$@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.

[Frank Cazabon]

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

Post by Paul H. Tarver
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-----
Tarver
Sent: Wednesday, May 02, 2018 11:28 AM
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-----
Turri
Sent: Wednesday, May 02, 2018 10:51 AM
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.

Post by Paul H. Tarver
lnExeNumber = ADIR(laPrograms, '*.EXE')

Gianni
-----Original Message-----
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-----
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-----
Roche
Sent: Tuesday, May 01, 2018 2:38 PM
Subject: Re: AGETFILEVERSION Fail

Post by Paul H. Tarver
The reason for this code is to identify the application .EXE. Perhaps

there

Post by Paul H. Tarver
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: ***@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/edce3087-3fff-e38d-6baa-***@gmail.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.

[Paul H. Tarver]

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-***@leafe.com] On Behalf Of Frank
Cazabon
Sent: Wednesday, May 02, 2018 12:16 PM
To: ***@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

Post by Paul H. Tarver
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-----
Tarver
Sent: Wednesday, May 02, 2018 11:28 AM
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-----
Turri
Sent: Wednesday, May 02, 2018 10:51 AM
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.

Post by Paul H. Tarver
lnExeNumber = ADIR(laPrograms, '*.EXE')

Gianni
-----Original Message-----
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-----
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-----
Roche
Sent: Tuesday, May 01, 2018 2:38 PM
Subject: Re: AGETFILEVERSION Fail

Post by Paul H. Tarver
The reason for this code is to identify the application .EXE. Perhaps

there

Post by Paul H. Tarver
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: ***@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.

[Gianni Turri]

From VFP Help

AGETFILEVERSION( ) returns the number of elements in the array.

If the file you specify does not exist or does not contain Windows version resources,
AGETFILEVERSION( ) returns zero,
and the array, if already created, remains unchanged.

Try to pass the fully qualified pathname instead of the filename only.

Gianni

-----Original Message-----
On Wed, 2 May 2018 11:40:49 -0500, "Paul H. Tarver" <***@tpcqpc.com> 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-***@leafe.com] On Behalf Of Paul H.
Tarver
Sent: Wednesday, May 02, 2018 11:28 AM
To: ***@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-***@leafe.com] On Behalf Of Gianni
Turri
Sent: Wednesday, May 02, 2018 10:51 AM
To: ***@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.

Post by Paul H. Tarver
lnExeNumber = ADIR(laPrograms, '*.EXE')

Gianni

-----Original Message-----
On Wed, 02 May 2018 02:47:00 +0200, Gianni Turri <***@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" <***@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-***@leafe.com] On Behalf Of Ted
Roche
Sent: Tuesday, May 01, 2018 2:38 PM
To: ***@leafe.com
Subject: Re: AGETFILEVERSION Fail

Post by Paul H. Tarver
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: ***@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/***@4ax.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.

[Charlie-gm]

Maybe take a look at "_VFP.servername". That returns a character string
of the .exe (including path) that is being executed.

Example:
my_exe_file = _vfp.servername

I don't think this will work if you are running ".app" files - in that
case it may always return the path to the VFP9.exe executable. But if
you run that line of code within a compiled VFP .exe, you should always
get the path/name of the .exe (assuming that is what you're after here).

HTH,
-Charlie

Post by Paul H. Tarver
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

...

Post by Paul H. Tarver

Post by Paul H. Tarver
The reason for this code is to identify the application .EXE. Perhaps

_______________________________________________
Post Messages to: ***@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/083aca4a-8c54-2d34-52e0-***@gmail.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.

[Paul H. Tarver]

Thanks for the suggestion, but this method will require the EXE to be
running to return the correct value. My current method only requires an EXE
file to be in the development folder so my method will work even if in the
IDE.

Paul H. Tarver


-----Original Message-----
From: ProfoxTech [mailto:profoxtech-***@leafe.com] On Behalf Of
Charlie-gm
Sent: Wednesday, May 02, 2018 8:31 AM
To: ***@leafe.com
Subject: Re: AGETFILEVERSION Fail

Maybe take a look at "_VFP.servername". That returns a character string
of the .exe (including path) that is being executed.

Example:
my_exe_file = _vfp.servername

I don't think this will work if you are running ".app" files - in that
case it may always return the path to the VFP9.exe executable. But if
you run that line of code within a compiled VFP .exe, you should always
get the path/name of the .exe (assuming that is what you're after here).

HTH,
-Charlie

Post by Paul H. Tarver
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

...

Post by Paul H. Tarver

Post by Paul H. Tarver
The reason for this code is to identify the application .EXE. Perhaps

[excessive quoting removed by server]

_______________________________________________
Post Messages to: ***@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/038301d3e231$208e7c00$61ab7400$@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.

[Gene Wirchenko]

Post by Charlie-gm
Maybe take a look at "_VFP.servername". That returns a character
string of the .exe (including path) that is being executed.
my_exe_file = _vfp.servername
I don't think this will work if you are running ".app" files - in
that case it may always return the path to the VFP9.exe executable.
But if you run that line of code within a compiled VFP .exe, you
should always get the path/name of the .exe (assuming that is what
you're after here).

I need the name for using Adobe's print to PDF printer driver. My code:

* What is the name of executable that CBS2 is running under?
* This is needed by the PDF reporting code.
local sys16name, apptype, underruntime, vfpexename
sys16name=sys(16,1)
apptype=upper(right(sys16name,4))
underruntime=version(2)=0
vfpexename=_vfp.fullname
do case
case apptype=".FXP" && .FXP under VFP development
this.appexename=vfpexename
case apptype=".EXE" and !underruntime && .EXE under VFP development
this.appexename=vfpexename
case apptype=".EXE" and underruntime && .EXE under VFP runtime
this.appexename=sys16name
otherwise && unknown
this.appexename=vfpexename
endcase

[snip]

Sincerely,

Gene Wirchenko


_______________________________________________
Post Messages to: ***@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/***@mtlp000087
** 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.

[Frank Cazabon]

Maybe you could break it up into a little test program to narrow it down
and ensure it's the Oracle connection causing the problem. Cut out all
your code and do something like this:

AGETFILEVERSION("Your exe")

* test that correct values returned

* then connect to Oracle

* check AGETFILEVERSION()

* disconnect from Oracle

* check AGETFILEVERSION()

* then connect to Oracle

* check AGETFILEVERSION()

* disconnect from Oracle

* check AGETFILEVERSION()

FWIW I use NOT VERSION(2) = 0 to determine if I'm running in development
mode (I almost never run the exe in development mode, just start from
the main program or run the individual form). SYS(16,0) or PROGRAM(0)
may also help you out as an alternative.


Frank.

Frank Cazabon

Post by Paul H. Tarver
Frank,
m.plFileDesc = "MAIN PROGRAM"
lnExeNumber = ADIR(laPrograms, '*.EXE')
=ASORT(laPrograms,3,-1,1)
leRetVal = ''
IF m.lnExeNumber > 0
FOR lnLoopCnt = 1 TO m.lnExeNumber
lnElements = AGETFILEVERSION(laVersInfo,
laPrograms[m.lnLoopCnt,1])
IF m.lnElements > 0
IF UPPER(ALLTRIM(laVersInfo(3))) ==
ALLTRIM(m.plFileDesc)
leRetVal =
ALLTRIM(laPrograms[m.lnLoopCnt,1])
EXIT
ENDIF
ENDIF
ENDFOR
ENDIF
1) Start Foxpro, run form, get connection handle to Oracle via ODBC and the
code above works perfectly.
2) Exit form (without closing Foxpro) and restart form and though we get a
valid array from ADIR() but AGETFILEVERSION() returns ''
3) Exit Foxpro, restart and GOTO back to step 1
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.
Paul
-----Original Message-----
Cazabon
Sent: Sunday, April 29, 2018 4:26 PM
Subject: Re: AGETFILEVERSION Fail
Paul,
what's the code you are using?
Frank.
Frank Cazabon

Post by Paul H. Tarver
Has anyone ever had any problem with AGETFILEVERSION() failing to return
values after an ODBC connection is made?
I'm using the Oracle ODBC Driver and until the SQLCONNECT() command is
issued AGETFILEVERSION() works perfectly. After I issue the SQLCONNECT()
command and get a valid handle, AGETFILEVERSION() will not return any
values. I have to exit VFP and restart it, then, AGETFILEVERSION() works
again until I make another connection to Oracle via ODBC.
I've used the Oracle's ODBC driver previously with no ill affect. But
now.Grrrrrr!
Paul
--- StripMime Report -- processed MIME parts ---
multipart/alternative
text/plain (text body -- kept)
text/html
---

[excessive quoting removed by server]

_______________________________________________
Post Messages to: ***@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/9e29f7f8-10c5-40f9-c8a4-***@gmail.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.

[Paul H. Tarver]

I did testing similar to what you suggested before I posted to the group.
That's how I isolated the issue down to the AGETFILEVERSION() command.

I am storing my settings in an INI file which uses the same JUSTSTEM() path
and name as the EXE file for different projects where the EXE might be named
various ways. By identifying the primary EXE file, we know the settings file
that corresponds to the EXE for that project without having to hard code the
INI file name within any of our classes, forms or reports. It's just been an
easy way to do things for the past 20+ years. During that time our code
hasn't changed much for this particular class, but now when we are using the
Oracle ODBC Driver, AGETFILEVERSION() returns an empty string instead of the
normal array of data. No error, no stop, just an empty string and not an
empty array just an empty string. I have confirmed from the tests I've been
doing the reason it works the first time, is because we call
AGETFILEVERSION() prior to getting a connection handle to the Oracle ODBC
but once a connection is established, AGETFILEVERSION() will return only an
empty string until I restart Foxpro.

My code was useful because as long as I had even an old version of the main
EXE file in the development folder, running any program or form that needed
to get values from the INI could easily check for the EXE filename and know
which setting file to access. That is no longer the case and I'll have to
come up with either a solution to what is causing AGETFILEVERISON() to fail
or re-factor the class I use to find the EXE file name to use a different
method. So far, the suggestions have been good, but most require you to be
running the EXE to pull that information from the stack. My method didn't
require the EXE to be running in order to identify the INI file.

I'll keep testing, Thanks!

Paul H. Tarver


-----Original Message-----
From: ProfoxTech [mailto:profoxtech-***@leafe.com] On Behalf Of Frank
Cazabon
Sent: Wednesday, May 02, 2018 7:01 AM
To: ***@leafe.com
Subject: Re: AGETFILEVERSION Fail

Maybe you could break it up into a little test program to narrow it down
and ensure it's the Oracle connection causing the problem. Cut out all
your code and do something like this:

AGETFILEVERSION("Your exe")

* test that correct values returned

* then connect to Oracle

* check AGETFILEVERSION()

* disconnect from Oracle

* check AGETFILEVERSION()

* then connect to Oracle

* check AGETFILEVERSION()

* disconnect from Oracle

* check AGETFILEVERSION()

FWIW I use NOT VERSION(2) = 0 to determine if I'm running in development
mode (I almost never run the exe in development mode, just start from
the main program or run the individual form). SYS(16,0) or PROGRAM(0)
may also help you out as an alternative.


Frank.

Frank Cazabon

Post by Paul H. Tarver
Frank,
m.plFileDesc = "MAIN PROGRAM"
lnExeNumber = ADIR(laPrograms, '*.EXE')
=ASORT(laPrograms,3,-1,1)
leRetVal = ''
IF m.lnExeNumber > 0
FOR lnLoopCnt = 1 TO m.lnExeNumber
lnElements = AGETFILEVERSION(laVersInfo,
laPrograms[m.lnLoopCnt,1])
IF m.lnElements > 0
IF UPPER(ALLTRIM(laVersInfo(3))) ==
ALLTRIM(m.plFileDesc)
leRetVal =
ALLTRIM(laPrograms[m.lnLoopCnt,1])
EXIT
ENDIF
ENDIF
ENDFOR
ENDIF
1) Start Foxpro, run form, get connection handle to Oracle via ODBC and the
code above works perfectly.
2) Exit form (without closing Foxpro) and restart form and though we get a
valid array from ADIR() but AGETFILEVERSION() returns ''
3) Exit Foxpro, restart and GOTO back to step 1
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.
Paul
-----Original Message-----
Cazabon
Sent: Sunday, April 29, 2018 4:26 PM
Subject: Re: AGETFILEVERSION Fail
Paul,
what's the code you are using?
Frank.
Frank Cazabon

Post by Paul H. Tarver
Has anyone ever had any problem with AGETFILEVERSION() failing to return
values after an ODBC connection is made?
I'm using the Oracle ODBC Driver and until the SQLCONNECT() command is
issued AGETFILEVERSION() works perfectly. After I issue the SQLCONNECT()
command and get a valid handle, AGETFILEVERSION() will not return any
values. I have to exit VFP and restart it, then, AGETFILEVERSION() works
again until I make another connection to Oracle via ODBC.
I've used the Oracle's ODBC driver previously with no ill affect. But
now.Grrrrrr!
Paul
--- StripMime Report -- processed MIME parts ---
multipart/alternative
text/plain (text body -- kept)
text/html
---

[excessive quoting removed by server]

_______________________________________________
Post Messages to: ***@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/038401d3e231$209336f0$61b9a4d0$@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.