Re: GETFILE() Returns Empty String in Some Cases

[Peter Cushing]

On 31/07/2017 21:04, Ken Dibble wrote:


Are you declaring your variable as PRIVATE right before you run the 
GETFILE() command?


PRIVATE mypath

mypath = GETFILE("csv","Spreadsheet","Open",0,"Open Spreadsheet")

Just curious if that is affecting it.


GAHHH!!! That's it!!

Not a PRIVATE declaration, the variable is declared LOCAL.

I got bit the other week with a different problem with a user using 
GETPICT, which is essentially the same function, but just matches 
pictures.  Tried this use with GETFILE and works the same.


cFile = GETFILE('','Get me a file')

If you start typing something in the box to match entries in the folder 
it will show available matches and you can click on one and it puts this 
name in the box and click ok.  This works fine.  If you just press enter 
after entering some text but not clicking on the matches it will return 
this name even though the file does not exist.  I now have to have an 
extra check that the file actually exists when GETFILE returns a value.  
I used to assume the name existed if they returned a value, then my 
program would fall over. I had assumed they were renaming or moving 
files before saving.


Peter



This communication is intended for the person or organisation to whom it is addressed. The contents are confidential and may be protected in law. Unauthorised use, copying or disclosure of any of it may be unlawful. If you have received this message in error, please notify us immediately by telephone or email. 


www.whisperingsmith.com

Whispering Smith Ltd Head Office:61 Great Ducie Street, Manchester M3 1RR. 
Tel:0161 831 3700 
Fax:0161 831 3715 


London Office:17-19 Foley Street, London W1W 6DW Tel:0207 299 7960




___
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/fbf939e8-b839-b502-8c45-b900220c7...@whisperingsmith.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.

RE: GETFILE() Returns Empty String in Some Cases

[Paul H. Tarver]

If a convention is not being used for its intended purpose and is, in fact,
optional, then it seems to me the unintended benefits may be the only things
which matter to someone considering whether to start using the convention
even in a limited way. Besides if you use variable naming conversions for
memory variables and do not use the same naming convention for tables and
fields and you always reference fields with table.field, then the intended
purpose may be a weak argument in favor of its use. 

Paul H. Tarver
Tarver Program Consultants, Inc.
Email: p...@tpcqpc.com 


-Original Message-
From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Koen
Piller
Sent: Monday, August 07, 2017 3:21 PM
To: profoxt...@leafe.com
Subject: Re: GETFILE() Returns Empty String in Some Cases

Hi,
It is a well known mistake that m.Dot is a speed improvement. Speed
improvement is collotaral advantace.
m.Dot is designed to make a string a true variable and not a field name. If
you have a table with a field number and you contruct a function like:
local number
if number = 12
do something
endif
and you have a local variable number in this function, VFP ist looks for the
value of the field number and not for the variabler number.
Regards,
Koen

2017-08-07 21:37 GMT+02:00 Paul H. Tarver <p...@tpcqpc.com>:

> Based on results posted, I decided to do some real world testing with 
> a customer file with real data to see what kind of results I would get.
>
> BACKGROUND:
> Instead of using val() to convert text numbers to values, I have my 
> own library function called txt2num which performs the conversion but 
> it also strips out punctuation such as dollar signs and commas as well 
> as handles signs whether in front or behind and it deals with decimals 
> that go beyond two places all on the fly.
>
> FIRST TEST:
> Importing a small text file of 25 columns, 350 rows and 12
> thisform.library.txt2num() conversion procedures per row that's 4,200 
> calls to the function.
>
> 1) Base run - No mdot references: 1.529 seconds
> 2) After mdot added - mdot references added to function: 1.436 
> seconds.
>
> That works out to about a 6% improvement in speed. Not a huge 
> improvement but it was small file.
>
> SECOND TEST:
> Importing a larger text file of 50 columns, 10261 rows and 12
> thisform.library.txt2num() conversion procedures per row or about 
> 123,132 calls to the function.
>
> 1) Base run - No mdot references: 5.101 seconds
> 2) After mdot added - mdot references added to function: 4.399 
> seconds.
>
> That works out to about a 13.7% improvement in speed.
>
> Not sure if the improvement scales consistently as file sizes increase.
> However, it seems to me perhaps the most effective use of the mdot 
> notation may be in refactoring it into libraries or classes. That way 
> you will get the most advantage from functions you call repeatedly. 
> Plus as soon as you re-compile an existing program you can gain the 
> speed advantages immediately without refactoring ALL your code.
>
> As always, your mileage may vary.
>
> Paul H. Tarver
> Tarver Program Consultants, Inc.
> Email: p...@tpcqpc.com
>
>
> -Original Message-
> From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of 
> Darren
> Sent: Thursday, August 03, 2017 5:24 PM
> To: profoxt...@leafe.com
> Subject: RE: GETFILE() Returns Empty String in Some Cases
>
> Personally I use this approach ...
>
> STORE m.variable|obj.property|table.fieldname to variable.   Fully qualify
> everything / always. Easier to debug as well.
>
> Additional to results below ... STORE/ = | with/without m. |  with/ 
> without table open.
>
> No Table Open   x=y 0.1320
> No Table Open   STORE y to x0.0870
> No Table Open   x=m.y   0.1328
> No Table Open   STORE m.y to x  0.0879
> Table Open  x=y 0.2081
> Table Open  STORE y to x0.1644
> Table Open  x=m.y   0.1326
> Table Open  STORE m.y to x  0.0879
>
> No Table Open   STORE y to x0.0870
> No Table Open   STORE m.y to x  0.0879
> Table Open  STORE m.y to x  0.0879
> No Table Open   x=y 0.1320
> Table Open  x=m.y   0.1326
> No Table Open   x=m.y   0.1328
> Table Open  STORE y to x0.1644
> Table Open          x=y     0.2081
>
>
>
> -Original Message-
> From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of 
> Paul H.
> Tarver
> Sent: Wednesday, 2 August 2017 6:32 AM
> To: profoxt...@leafe.com
> Subject: RE: GETFILE() Returns Empty String in Some Cases
>
> That was a really interesting article so I too

Re: GETFILE() Returns Empty String in Some Cases

[Koen Piller]

Hi,
It is a well known mistake that m.Dot is a speed improvement. Speed
improvement is collotaral advantace.
m.Dot is designed to make a string a true variable and not a field name. If
you have a table with a field number and you contruct a function like:
local number
if number = 12
do something
endif
and you have a local variable number in this function, VFP ist looks for
the value of the field number and not for the variabler number.
Regards,
Koen

2017-08-07 21:37 GMT+02:00 Paul H. Tarver <p...@tpcqpc.com>:

> Based on results posted, I decided to do some real world testing with a
> customer file with real data to see what kind of results I would get.
>
> BACKGROUND:
> Instead of using val() to convert text numbers to values, I have my own
> library function called txt2num which performs the conversion but it also
> strips out punctuation such as dollar signs and commas as well as handles
> signs whether in front or behind and it deals with decimals that go beyond
> two places all on the fly.
>
> FIRST TEST:
> Importing a small text file of 25 columns, 350 rows and 12
> thisform.library.txt2num() conversion procedures per row that's 4,200 calls
> to the function.
>
> 1) Base run - No mdot references: 1.529 seconds
> 2) After mdot added - mdot references added to function: 1.436
> seconds.
>
> That works out to about a 6% improvement in speed. Not a huge improvement
> but it was small file.
>
> SECOND TEST:
> Importing a larger text file of 50 columns, 10261 rows and 12
> thisform.library.txt2num() conversion procedures per row or about 123,132
> calls to the function.
>
> 1) Base run - No mdot references: 5.101 seconds
> 2) After mdot added - mdot references added to function: 4.399
> seconds.
>
> That works out to about a 13.7% improvement in speed.
>
> Not sure if the improvement scales consistently as file sizes increase.
> However, it seems to me perhaps the most effective use of the mdot notation
> may be in refactoring it into libraries or classes. That way you will get
> the most advantage from functions you call repeatedly. Plus as soon as you
> re-compile an existing program you can gain the speed advantages
> immediately
> without refactoring ALL your code.
>
> As always, your mileage may vary.
>
> Paul H. Tarver
> Tarver Program Consultants, Inc.
> Email: p...@tpcqpc.com
>
>
> -Original Message-
> From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Darren
> Sent: Thursday, August 03, 2017 5:24 PM
> To: profoxt...@leafe.com
> Subject: RE: GETFILE() Returns Empty String in Some Cases
>
> Personally I use this approach ...
>
> STORE m.variable|obj.property|table.fieldname to variable.   Fully qualify
> everything / always. Easier to debug as well.
>
> Additional to results below ... STORE/ = | with/without m. |  with/ without
> table open.
>
> No Table Open   x=y 0.1320
> No Table Open   STORE y to x0.0870
> No Table Open   x=m.y   0.1328
> No Table Open   STORE m.y to x  0.0879
> Table Open  x=y 0.2081
> Table Open  STORE y to x0.1644
> Table Open  x=m.y   0.1326
> Table Open  STORE m.y to x  0.0879
>
> No Table Open   STORE y to x0.0870
> No Table Open   STORE m.y to x  0.0879
> Table Open  STORE m.y to x  0.0879
> No Table Open   x=y 0.1320
> Table Open  x=m.y   0.1326
> No Table Open   x=m.y   0.1328
> Table Open  STORE y to x0.1644
> Table Open          x=y     0.2081
>
>
>
> -Original Message-
> From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Paul
> H.
> Tarver
> Sent: Wednesday, 2 August 2017 6:32 AM
> To: profoxt...@leafe.com
> Subject: RE: GETFILE() Returns Empty String in Some Cases
>
> That was a really interesting article so I took the example, expanded it to
> include an object property and ran the test on my system.
>
> Here are my results:
> -
> y=1
> nsec=SECONDS()
> FOR i = 1 to 100
> * x=y   && Results: 0.377
> * x=m.y && Results: 0.151
> * x=fld255  && Results: 0.328
> * x=test.fld255 && Results: 0.201
> * x=objSession.nValue   && Results: 0.377
> ENDFOR
> ?SECONDS()-nsec
> -
>
> Most of my work is done moving data through temporary cursors and I ALWAYS
> reference fields with the table.field method shown in the fourth test. I
> also often use object

RE: GETFILE() Returns Empty String in Some Cases

[Paul H. Tarver]

Based on results posted, I decided to do some real world testing with a
customer file with real data to see what kind of results I would get. 

BACKGROUND: 
Instead of using val() to convert text numbers to values, I have my own
library function called txt2num which performs the conversion but it also
strips out punctuation such as dollar signs and commas as well as handles
signs whether in front or behind and it deals with decimals that go beyond
two places all on the fly. 

FIRST TEST:
Importing a small text file of 25 columns, 350 rows and 12
thisform.library.txt2num() conversion procedures per row that's 4,200 calls
to the function. 

1) Base run - No mdot references: 1.529 seconds
2) After mdot added - mdot references added to function: 1.436
seconds. 

That works out to about a 6% improvement in speed. Not a huge improvement
but it was small file. 

SECOND TEST:
Importing a larger text file of 50 columns, 10261 rows and 12
thisform.library.txt2num() conversion procedures per row or about 123,132
calls to the function. 

1) Base run - No mdot references: 5.101 seconds
2) After mdot added - mdot references added to function: 4.399
seconds. 

That works out to about a 13.7% improvement in speed. 

Not sure if the improvement scales consistently as file sizes increase.
However, it seems to me perhaps the most effective use of the mdot notation
may be in refactoring it into libraries or classes. That way you will get
the most advantage from functions you call repeatedly. Plus as soon as you
re-compile an existing program you can gain the speed advantages immediately
without refactoring ALL your code. 

As always, your mileage may vary. 

Paul H. Tarver
Tarver Program Consultants, Inc.
Email: p...@tpcqpc.com 


-Original Message-
From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Darren
Sent: Thursday, August 03, 2017 5:24 PM
To: profoxt...@leafe.com
Subject: RE: GETFILE() Returns Empty String in Some Cases

Personally I use this approach ...

STORE m.variable|obj.property|table.fieldname to variable.   Fully qualify
everything / always. Easier to debug as well.

Additional to results below ... STORE/ = | with/without m. |  with/ without
table open.

No Table Open   x=y 0.1320
No Table Open   STORE y to x0.0870
No Table Open   x=m.y   0.1328
No Table Open   STORE m.y to x  0.0879
Table Open  x=y 0.2081
Table Open  STORE y to x0.1644
Table Open  x=m.y   0.1326
Table Open  STORE m.y to x  0.0879

No Table Open   STORE y to x0.0870
No Table Open   STORE m.y to x  0.0879
Table Open  STORE m.y to x  0.0879
No Table Open   x=y 0.1320
Table Open  x=m.y   0.1326
No Table Open   x=m.y   0.1328
Table Open  STORE y to x0.1644
Table Open  x=y 0.2081



-Original Message-
From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Paul H.
Tarver
Sent: Wednesday, 2 August 2017 6:32 AM
To: profoxt...@leafe.com
Subject: RE: GETFILE() Returns Empty String in Some Cases

That was a really interesting article so I took the example, expanded it to
include an object property and ran the test on my system. 

Here are my results:
-
y=1
nsec=SECONDS()
FOR i = 1 to 100
* x=y   && Results: 0.377
* x=m.y && Results: 0.151
* x=fld255  && Results: 0.328
* x=test.fld255 && Results: 0.201
* x=objSession.nValue   && Results: 0.377
ENDFOR
?SECONDS()-nsec
-

Most of my work is done moving data through temporary cursors and I ALWAYS
reference fields with the table.field method shown in the fourth test. I
also often use object properties to store static variables. While it looks
like I'm getting the best results using table.field access; I'm not getting
any performance advantage using object properties or by not using the m.
prefix. The good news is now I know if I'm going to do a LOT of iterations
with memory variables, there are  some performance gains to be picked up by
simply using the m. notation. I think I may keep these results in mind when
I'm doing refactoring on my function library!

This has been quite the learning experience and I really appreciate Ken for
sharing that article! It also proves that no matter how long you've been
programming in ANY language there is always something new you can pick up.
Thanks!

Paul H. Tarver
Tarver Program Consultants, Inc.
Email: p...@tpcqpc.com 



-Original Message-
From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Ken
Dibble
Sent: Tuesday, August 01, 2017 1:30 PM
To: profoxt...@leafe.com
Subject: RE: GETFILE() Returns Empty String in Some Cases

I rememb

Re: Performance with qualifier/scope (was RE: GETFILE() Returns Empty String in Some Cases)

[Laurie Alvey]

A few thoughts:
STORE can only refer to variables.
FOR...ENDFOR loops only use variables..
The assignment x = y implies that x must be a variable (you cannot assign
to a field using that  syntax).
The assignment x = m.y would remove any ambiguity.

There are a load more examples on the FoxWiki
http://fox.wikis.com/wc.dll?Wiki~EssentialMDot~Wiki.

Laurie

On 4 August 2017 at 22:02, Alan Bourke  wrote:

> More typing, never seen the point.
>
> --
>   Alan Bourke
>   alanpbourke (at) fastmail (dot) fm
>
> On Fri, 4 Aug 2017, at 10:49 AM,
> mbsoftwaresoluti...@mbsoftwaresolutions.com wrote:
> > On 2017-08-03 18:23, Darren wrote:
> > > Personally I use this approach ...
> > >
> > > STORE m.variable|obj.property|table.fieldname to variable.   Fully
> > > qualify
> > > everything / always. Easier to debug as well.
> > >
> > > Additional to results below ... STORE/ = | with/without m. |  with/
> > > without
> > > table open.
> > >
> > > No Table Open   x=y 0.1320
> > > No Table Open   STORE y to x0.0870
> > > No Table Open   x=m.y   0.1328
> > > No Table Open   STORE m.y to x  0.0879
> > > Table Open  x=y 0.2081
> > > Table Open  STORE y to x0.1644
> > > Table Open  x=m.y   0.1326
> > > Table Open  STORE m.y to x  0.0879
> > >
> > > No Table Open   STORE y to x0.0870
> > > No Table Open   STORE m.y to x  0.0879
> > > Table Open  STORE m.y to x  0.0879
> > > No Table Open   x=y 0.1320
> > > Table Open  x=m.y   0.1326
> > > No Table Open   x=m.y   0.1328
> > > Table Open  STORE y to x0.1644
> > > Table Open  x=y 0.2081
> >
> >
> > Can't argue with the numbers, but personally I've never liked STORE.  No
> > good reason I guess except it never felt normal (but hey, that's
> > ok...use the Fox at its best, however that is!).
> >
> >
[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/CAMvTR9d3F9m__j-jB_cQzRah805OuasniaUms-XH-51Je8=w...@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.

Re: Performance with qualifier/scope (was RE: GETFILE() Returns Empty String in Some Cases)

[Alan Bourke]

More typing, never seen the point.

-- 
  Alan Bourke
  alanpbourke (at) fastmail (dot) fm

On Fri, 4 Aug 2017, at 10:49 AM,
mbsoftwaresoluti...@mbsoftwaresolutions.com wrote:
> On 2017-08-03 18:23, Darren wrote:
> > Personally I use this approach ...
> > 
> > STORE m.variable|obj.property|table.fieldname to variable.   Fully 
> > qualify
> > everything / always. Easier to debug as well.
> > 
> > Additional to results below ... STORE/ = | with/without m. |  with/ 
> > without
> > table open.
> > 
> > No Table Open   x=y 0.1320
> > No Table Open   STORE y to x0.0870
> > No Table Open   x=m.y   0.1328
> > No Table Open   STORE m.y to x  0.0879
> > Table Open  x=y 0.2081
> > Table Open  STORE y to x0.1644
> > Table Open  x=m.y   0.1326
> > Table Open  STORE m.y to x  0.0879
> > 
> > No Table Open   STORE y to x0.0870
> > No Table Open   STORE m.y to x  0.0879
> > Table Open  STORE m.y to x  0.0879
> > No Table Open   x=y 0.1320
> > Table Open  x=m.y   0.1326
> > No Table Open   x=m.y   0.1328
> > Table Open  STORE y to x0.1644
> > Table Open  x=y 0.2081
> 
> 
> Can't argue with the numbers, but personally I've never liked STORE.  No 
> good reason I guess except it never felt normal (but hey, that's 
> ok...use the Fox at its best, however that is!).
> 
> 
[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/1501880557.3304411.1063593704.604bc...@webmail.messagingengine.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.

Performance with qualifier/scope (was RE: GETFILE() Returns Empty String in Some Cases)

[mbsoftwaresolutions]

On 2017-08-03 18:23, Darren wrote:

Personally I use this approach ...

STORE m.variable|obj.property|table.fieldname to variable.   Fully 
qualify

everything / always. Easier to debug as well.

Additional to results below ... STORE/ = | with/without m. |  with/ 
without

table open.

No Table Open   x=y 0.1320
No Table Open   STORE y to x0.0870
No Table Open   x=m.y   0.1328
No Table Open   STORE m.y to x  0.0879
Table Open  x=y 0.2081
Table Open  STORE y to x0.1644
Table Open  x=m.y   0.1326
Table Open  STORE m.y to x  0.0879

No Table Open   STORE y to x0.0870
No Table Open   STORE m.y to x  0.0879
Table Open  STORE m.y to x  0.0879
No Table Open   x=y 0.1320
Table Open  x=m.y   0.1326
No Table Open   x=m.y   0.1328
Table Open  STORE y to x0.1644
Table Open  x=y 0.2081



Can't argue with the numbers, but personally I've never liked STORE.  No 
good reason I guess except it never felt normal (but hey, that's 
ok...use the Fox at its best, however that is!).



___
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/153adb6149f9e8fdaf249d24a5667...@mbsoftwaresolutions.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.

RE: GETFILE() Returns Empty String in Some Cases

[Darren]

Personally I use this approach ...

STORE m.variable|obj.property|table.fieldname to variable.   Fully qualify
everything / always. Easier to debug as well.

Additional to results below ... STORE/ = | with/without m. |  with/ without
table open.

No Table Open   x=y 0.1320
No Table Open   STORE y to x0.0870
No Table Open   x=m.y   0.1328
No Table Open   STORE m.y to x  0.0879
Table Open  x=y 0.2081
Table Open  STORE y to x0.1644
Table Open  x=m.y   0.1326
Table Open  STORE m.y to x  0.0879

No Table Open   STORE y to x0.0870
No Table Open   STORE m.y to x  0.0879
Table Open  STORE m.y to x  0.0879
No Table Open   x=y 0.1320
Table Open  x=m.y   0.1326
No Table Open   x=m.y   0.1328
Table Open  STORE y to x0.1644
Table Open  x=y 0.2081



-Original Message-
From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Paul H.
Tarver
Sent: Wednesday, 2 August 2017 6:32 AM
To: profoxt...@leafe.com
Subject: RE: GETFILE() Returns Empty String in Some Cases

That was a really interesting article so I took the example, expanded it to
include an object property and ran the test on my system. 

Here are my results:
-
y=1
nsec=SECONDS()
FOR i = 1 to 100
* x=y   && Results: 0.377
* x=m.y && Results: 0.151
* x=fld255  && Results: 0.328
* x=test.fld255 && Results: 0.201
* x=objSession.nValue   && Results: 0.377
ENDFOR
?SECONDS()-nsec
-

Most of my work is done moving data through temporary cursors and I ALWAYS
reference fields with the table.field method shown in the fourth test. I
also often use object properties to store static variables. While it looks
like I'm getting the best results using table.field access; I'm not getting
any performance advantage using object properties or by not using the m.
prefix. The good news is now I know if I'm going to do a LOT of iterations
with memory variables, there are  some performance gains to be picked up by
simply using the m. notation. I think I may keep these results in mind when
I'm doing refactoring on my function library!

This has been quite the learning experience and I really appreciate Ken for
sharing that article! It also proves that no matter how long you've been
programming in ANY language there is always something new you can pick up.
Thanks!

Paul H. Tarver
Tarver Program Consultants, Inc.
Email: p...@tpcqpc.com 



-Original Message-
From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Ken
Dibble
Sent: Tuesday, August 01, 2017 1:30 PM
To: profoxt...@leafe.com
Subject: RE: GETFILE() Returns Empty String in Some Cases

I remember!! It was Calvin Hsia! Here's the blog article:

https://blogs.msdn.microsoft.com/calvin_hsia/2004/12/14/foxpro-performance-t
ip-field-name-lookup-for-tables/

Ken

>On 2017-08-01 10:00, Ken Dibble wrote:
>>A member of the VFP Team (I can't remember his name; he was the guy 
>>who "took out the slow parts" from various subsystems for VFP 8 and 9) 
>>wrote a blog article explaining that without the M. prefix, the system 
>>MUST compare every variable referenced to every field in the current 
>>work area every time the variable is accessed to determine whether the 
>>variable is a field name. He said that if the current work area 
>>contains a large number of fields, and the same variable is used over 
>>a large number of iterations in a tight loop, using the M. prefix 
>>makes a considerable difference in speed. He showed test results to 
>>demonstrate this.
>>I do a LOT of array iteration. So I began using the M. prefix for 
>>variables inside high-iteration tight loops. I noticed a slight speed 
>>increase.
>>However, I find the M. prefix ugly and distracting. I used it 
>>yesterday as a quick fix to demonstrate what the problem was. I will 
>>probably eventually rename the variable.
>>Ken
>
>
>Very interesting...thanks for sharing that!
>
[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/003401d30ca7$333d6650$99b832f0$@ozemail.com.au
** 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.

Re: GETFILE() Returns Empty String in Some Cases

[AndyHC]

On 01-Aug-17 7:30 PM, Ken Dibble wrote:

I remember!! It was Calvin Hsia!


It so often was .



___
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/d0897677-fb51-083c-cb78-af3733ab5...@hawthorncottage.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.

RE: GETFILE() Returns Empty String in Some Cases

[Paul H. Tarver]

That was a really interesting article so I took the example, expanded it to
include an object property and ran the test on my system. 

Here are my results:
-
y=1
nsec=SECONDS()
FOR i = 1 to 100
* x=y   && Results: 0.377
* x=m.y && Results: 0.151
* x=fld255  && Results: 0.328
* x=test.fld255 && Results: 0.201
* x=objSession.nValue   && Results: 0.377
ENDFOR
?SECONDS()-nsec
-

Most of my work is done moving data through temporary cursors and I ALWAYS
reference fields with the table.field method shown in the fourth test. I
also often use object properties to store static variables. While it looks
like I'm getting the best results using table.field access; I'm not getting
any performance advantage using object properties or by not using the m.
prefix. The good news is now I know if I'm going to do a LOT of iterations
with memory variables, there are  some performance gains to be picked up by
simply using the m. notation. I think I may keep these results in mind when
I'm doing refactoring on my function library!

This has been quite the learning experience and I really appreciate Ken for
sharing that article! It also proves that no matter how long you've been
programming in ANY language there is always something new you can pick up.
Thanks!

Paul H. Tarver
Tarver Program Consultants, Inc.
Email: p...@tpcqpc.com 



-Original Message-
From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Ken
Dibble
Sent: Tuesday, August 01, 2017 1:30 PM
To: profoxt...@leafe.com
Subject: RE: GETFILE() Returns Empty String in Some Cases

I remember!! It was Calvin Hsia! Here's the blog article:

https://blogs.msdn.microsoft.com/calvin_hsia/2004/12/14/foxpro-performance-t
ip-field-name-lookup-for-tables/

Ken

>On 2017-08-01 10:00, Ken Dibble wrote:
>>A member of the VFP Team (I can't remember his name; he was the guy 
>>who "took out the slow parts" from various subsystems for VFP 8 and 9) 
>>wrote a blog article explaining that without the M. prefix, the system 
>>MUST compare every variable referenced to every field in the current 
>>work area every time the variable is accessed to determine whether the 
>>variable is a field name. He said that if the current work area 
>>contains a large number of fields, and the same variable is used over 
>>a large number of iterations in a tight loop, using the M. prefix 
>>makes a considerable difference in speed. He showed test results to 
>>demonstrate this.
>>I do a LOT of array iteration. So I began using the M. prefix for 
>>variables inside high-iteration tight loops. I noticed a slight speed 
>>increase.
>>However, I find the M. prefix ugly and distracting. I used it 
>>yesterday as a quick fix to demonstrate what the problem was. I will 
>>probably eventually rename the variable.
>>Ken
>
>
>Very interesting...thanks for sharing that!
>
[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/0ca201d30b05$317bdf20$94739d60$@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.

RE: GETFILE() Returns Empty String in Some Cases

[Richard Kaye]

That's when I joined the m dot team. If Calvin recommended it, it seemed like 
good advice. 

--

rk

-Original Message-
From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Ken Dibble
Sent: Tuesday, August 01, 2017 2:30 PM
To: profoxt...@leafe.com
Subject: RE: GETFILE() Returns Empty String in Some Cases

I remember!! It was Calvin Hsia! Here's the blog article:

https://blogs.msdn.microsoft.com/calvin_hsia/2004/12/14/foxpro-performance-tip-field-name-lookup-for-tables/

Ken

___
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/mwhpr10mb17746c856c13cffa5f35a3c2d2...@mwhpr10mb1774.namprd10.prod.outlook.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.

RE: GETFILE() Returns Empty String in Some Cases

[Ken Dibble]

I remember!! It was Calvin Hsia! Here's the blog article:

https://blogs.msdn.microsoft.com/calvin_hsia/2004/12/14/foxpro-performance-tip-field-name-lookup-for-tables/

Ken


On 2017-08-01 10:00, Ken Dibble wrote:

A member of the VFP Team (I can't remember his name; he was the guy
who "took out the slow parts" from various subsystems for VFP 8 and 9)
wrote a blog article explaining that without the M. prefix, the system
MUST compare every variable referenced to every field in the current
work area every time the variable is accessed to determine whether the
variable is a field name. He said that if the current work area
contains a large number of fields, and the same variable is used over
a large number of iterations in a tight loop, using the M. prefix
makes a considerable difference in speed. He showed test results to
demonstrate this.
I do a LOT of array iteration. So I began using the M. prefix for
variables inside high-iteration tight loops. I noticed a slight speed
increase.
However, I find the M. prefix ugly and distracting. I used it
yesterday as a quick fix to demonstrate what the problem was. I will
probably eventually rename the variable.
Ken



Very interesting...thanks for sharing that!


[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/2A.4B.21563.4C8C0895@cdptpa-omsmta03
** 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.

RE: GETFILE() Returns Empty String in Some Cases

[mbsoftwaresolutions]

On 2017-08-01 10:00, Ken Dibble wrote:

A member of the VFP Team (I can't remember his name; he was the guy
who "took out the slow parts" from various subsystems for VFP 8 and 9)
wrote a blog article explaining that without the M. prefix, the system
MUST compare every variable referenced to every field in the current
work area every time the variable is accessed to determine whether the
variable is a field name. He said that if the current work area
contains a large number of fields, and the same variable is used over
a large number of iterations in a tight loop, using the M. prefix
makes a considerable difference in speed. He showed test results to
demonstrate this.

I do a LOT of array iteration. So I began using the M. prefix for
variables inside high-iteration tight loops. I noticed a slight speed
increase.

However, I find the M. prefix ugly and distracting. I used it
yesterday as a quick fix to demonstrate what the problem was. I will
probably eventually rename the variable.

Ken



Very interesting...thanks for sharing that!

___
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/66df2f5bbb550875e31e29e9c3e0a...@mbsoftwaresolutions.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.

RE: GETFILE() Returns Empty String in Some Cases

[Paul H. Tarver]

+1

Although I generally only apply HN naming convention to variables only and
skip the convention on tables and fields. At most on fields, I'll use a
prefix to designate the type of table such as "xref_" for cross reference
lookup tables, etc. 

Paul H. Tarver
Tarver Program Consultants, Inc.
Email: p...@tpcqpc.com 


-Original Message-
From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of
mbsoftwaresoluti...@mbsoftwaresolutions.com
Sent: Monday, July 31, 2017 7:16 PM
To: profoxt...@leafe.com
Subject: Re: GETFILE() Returns Empty String in Some Cases

On 2017-07-31 16:04, Ken Dibble wrote:
> GAHHH!!! That's it!!
> 
> Not a PRIVATE declaration, the variable is declared LOCAL.
> 
> But in application mode there is a field in an open table with the 
> same name as the variable. I applied the "essential m-dot" to the 
> variable, and that fixed it.


That "variable with same name as a field name" has screwed me in the past
more than once.  That's why I like my "outdated" variable declarations as
pcFilename because I definitely don't conflict with MyTable.cFilename.  That
works for me.  Sorry for the purists who see that as horrible.  lol

[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/074601d30ae0$3f0e2500$bd2a6f00$@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.

RE: GETFILE() Returns Empty String in Some Cases

[Paul H. Tarver]

+1, what John said!

Paul H. Tarver
Tarver Program Consultants, Inc.
Email: p...@tpcqpc.com 



-Original Message-
From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of John
Weller
Sent: Tuesday, August 01, 2017 3:25 AM
To: profoxt...@leafe.com
Subject: Re: GETFILE() Returns Empty String in Some Cases

+1

It's always good to know I use the same methodology as a master. :-)

John Weller
07976 393631
01380 723235
Sent from my iPhone

> On 1 Aug 2017, at 08:44, Dave Crozier <da...@flexipol.co.uk> wrote:
> 
> Mike, 
> I agree with reasoning, but I have a slightly different methodology in
that all table/database variables AREN'T designated with a type prefix but
all programming variables are. This way there is never any confusion as I
reckon that the name in a table should only reflect the contents not the
data type. If you need to make the data type more obvious then include it in
the name i.e:
> 
>Start_DateD
>Is_LiveL
>Customer_IdC(20)
> 
> Addressing any of these field in mainline programming then becomes trivial
and you can easily do:
> 
> Scatter  name oData
> 
> dStart_Date = oData.Start_Date
> 
> or declare a local/private variable lIs_Live with no fear of messing
things up with no confusion.
> 
> Personally I am not a fan of the "M." prefix and find it unnecessary.
> 
> Just a FWIW.
> 
> Dave
> 
> 


[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/074501d30ae0$3f0a5470$bd1efd50$@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.

Re: GETFILE() Returns Empty String in Some Cases

[Alan Bourke]

On Tue, 1 Aug 2017, at 04:01 PM, Koen Piller wrote:
 
> without the m.Prefix it is impossible to build a generic procedure /
> application.
>

Could you elaborate? I haven't used m. since FoxPro 2.6 days and don't
seem to have an issue creating generic functionality.

-- 
  Alan Bourke
  alanpbourke (at) fastmail (dot) fm

___
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/1501603635.2390932.1059750352.6877f...@webmail.messagingengine.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.

RE: GETFILE() Returns Empty String in Some Cases

[Richard Kaye]

To contribute to the topic drift, maybe we can talk about TABs vs SPACES 
next...  (I'm an m dot guy. Ambiguity only contributes in horseshoes and hand 
grenades... ;-)

--

rk

-Original Message-
From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Koen Piller
Sent: Tuesday, August 01, 2017 11:01 AM
To: profoxt...@leafe.com
Subject: Re: GETFILE() Returns Empty String in Some Cases

Dave,

> Personally I am not a fan of the "M." prefix and find it unnecessary.

without the m.Prefix it is impossible to build a generic procedure /
application.

Regards,

Koen


___
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/mwhpr10mb177499b4a6d0453eea78aaf2d2...@mwhpr10mb1774.namprd10.prod.outlook.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.

Re: GETFILE() Returns Empty String in Some Cases

[Koen Piller]

Dave,

> Personally I am not a fan of the "M." prefix and find it unnecessary.

without the m.Prefix it is impossible to build a generic procedure /
application.

Regards,

Koen


2017-08-01 10:25 GMT+02:00 John Weller :

> +1
>
> It's always good to know I use the same methodology as a master. :-)
>
> John Weller
> 07976 393631
> 01380 723235
> Sent from my iPhone
>
> > On 1 Aug 2017, at 08:44, Dave Crozier  wrote:
> >
> > Mike,
> > I agree with reasoning, but I have a slightly different methodology in
> that all table/database variables AREN'T designated with a type prefix but
> all programming variables are. This way there is never any confusion as I
> reckon that the name in a table should only reflect the contents not the
> data type. If you need to make the data type more obvious then include it
> in the name i.e:
> >
> >Start_DateD
> >Is_LiveL
> >Customer_IdC(20)
> >
> > Addressing any of these field in mainline programming then becomes
> trivial and you can easily do:
> >
> > Scatter  name oData
> >
> > dStart_Date = oData.Start_Date
> >
> > or declare a local/private variable lIs_Live with no fear of messing
> things up with no confusion.
> >
> > Personally I am not a fan of the "M." prefix and find it unnecessary.
> >
> > Just a FWIW.
> >
> > Dave
> >
> >
>
>
[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/cacuu1sttw9fqvny-ha4xfvrmikc_m5wpxoraq_vbg0jyomz...@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.

RE: GETFILE() Returns Empty String in Some Cases

[Ken Dibble]

I agree with reasoning, but I have a slightly different methodology


I actually have my own methodology; I just failed to follow it. I 
personally find type abbreviations to be difficult to read and 
interpret quickly. For generic variables I usually just prefix "the", 
ie. thefile, thefolder, thename, etc. I never use "the" for a table 
or cursor field, so this ordinarily prevents the kind of problem I 
experienced yesterday.


Unfortunately, I had copied some old one-off code for this project in 
order to try to save some time. I need to remember that a lack of 
rigor will always eventually bite me.



Personally I am not a fan of the "M." prefix and find it unnecessary.


A member of the VFP Team (I can't remember his name; he was the guy 
who "took out the slow parts" from various subsystems for VFP 8 and 
9) wrote a blog article explaining that without the M. prefix, the 
system MUST compare every variable referenced to every field in the 
current work area every time the variable is accessed to determine 
whether the variable is a field name. He said that if the current 
work area contains a large number of fields, and the same variable is 
used over a large number of iterations in a tight loop, using the M. 
prefix makes a considerable difference in speed. He showed test 
results to demonstrate this.


I do a LOT of array iteration. So I began using the M. prefix for 
variables inside high-iteration tight loops. I noticed a slight speed increase.


However, I find the M. prefix ugly and distracting. I used it 
yesterday as a quick fix to demonstrate what the problem was. I will 
probably eventually rename the variable.


Ken  



___
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/AC.81.20123.36980895@cdptpa-omsmta02
** 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.

Re: GETFILE() Returns Empty String in Some Cases

[Laurie Alvey]

There was a big discussion on FoxWiki about using m dot. I think the
community was pretty polarised.

Laurie

On 1 August 2017 at 14:19, 
wrote:

> On 2017-08-01 03:44, Dave Crozier wrote:
>
>> Mike,
>> I agree with reasoning, but I have a slightly different methodology in
>> that all table/database variables AREN'T designated with a type prefix
>> but all programming variables are. This way there is never any
>> confusion as I reckon that the name in a table should only reflect the
>> contents not the data type. If you need to make the data type more
>> obvious then include it in the name i.e:
>>
>> Start_Date  D
>> Is_Live L
>> Customer_Id C(20)
>>
>> Addressing any of these field in mainline programming then becomes
>> trivial and you can easily do:
>>
>> Scatter  name oData
>>
>> dStart_Date = oData.Start_Date
>>
>> or declare a local/private variable lIs_Live with no fear of messing
>> things up with no confusion.
>>
>> Personally I am not a fan of the "M." prefix and find it unnecessary.
>>
>> Just a FWIW.
>>
>> Dave
>>
>
>
>
> Agree with you again!  I could see myself embracing the "no prefix in the
> table" concept.
> --Mike
>
>
[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/CAMvTR9fJHCtn+38Pt=__acth6bueesrqzj6zxpaezdaovcn...@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.

RE: GETFILE() Returns Empty String in Some Cases

[mbsoftwaresolutions]

On 2017-08-01 03:44, Dave Crozier wrote:

Mike,
I agree with reasoning, but I have a slightly different methodology in
that all table/database variables AREN'T designated with a type prefix
but all programming variables are. This way there is never any
confusion as I reckon that the name in a table should only reflect the
contents not the data type. If you need to make the data type more
obvious then include it in the name i.e:

Start_Date  D
Is_Live L
Customer_Id C(20)

Addressing any of these field in mainline programming then becomes
trivial and you can easily do:

Scatter  name oData

dStart_Date = oData.Start_Date

or declare a local/private variable lIs_Live with no fear of messing
things up with no confusion.

Personally I am not a fan of the "M." prefix and find it unnecessary.

Just a FWIW.

Dave




Agree with you again!  I could see myself embracing the "no prefix in 
the table" concept.

--Mike


___
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/8ba09a73ae71f14ab7655735d710b...@mbsoftwaresolutions.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.

Re: GETFILE() Returns Empty String in Some Cases

[John Weller]

+1

It's always good to know I use the same methodology as a master. :-)

John Weller
07976 393631
01380 723235
Sent from my iPhone

> On 1 Aug 2017, at 08:44, Dave Crozier  wrote:
> 
> Mike, 
> I agree with reasoning, but I have a slightly different methodology in that 
> all table/database variables AREN'T designated with a type prefix but all 
> programming variables are. This way there is never any confusion as I reckon 
> that the name in a table should only reflect the contents not the data type. 
> If you need to make the data type more obvious then include it in the name 
> i.e:
> 
>Start_DateD
>Is_LiveL
>Customer_IdC(20)
> 
> Addressing any of these field in mainline programming then becomes trivial 
> and you can easily do:
> 
> Scatter  name oData
> 
> dStart_Date = oData.Start_Date
> 
> or declare a local/private variable lIs_Live with no fear of messing things 
> up with no confusion.
> 
> Personally I am not a fan of the "M." prefix and find it unnecessary.
> 
> Just a FWIW.
> 
> Dave
> 
> 


___
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/e19c5963-3481-47e2-a841-f62352c40...@jbweller.force9.co.uk
** 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.

RE: GETFILE() Returns Empty String in Some Cases

[Dave Crozier]

Mike, 
I agree with reasoning, but I have a slightly different methodology in that all 
table/database variables AREN'T designated with a type prefix but all 
programming variables are. This way there is never any confusion as I reckon 
that the name in a table should only reflect the contents not the data type. If 
you need to make the data type more obvious then include it in the name i.e:

Start_Date  D
Is_Live L
Customer_Id C(20)

Addressing any of these field in mainline programming then becomes trivial and 
you can easily do:

Scatter  name oData

dStart_Date = oData.Start_Date

or declare a local/private variable lIs_Live with no fear of messing things up 
with no confusion.

Personally I am not a fan of the "M." prefix and find it unnecessary.

Just a FWIW.

Dave



-Original Message-
From: ProFox [mailto:profox-boun...@leafe.com] On Behalf Of 
mbsoftwaresoluti...@mbsoftwaresolutions.com
Sent: 01 August 2017 01:17
To: ProFox Email List <profox@leafe.com>
Subject: Re: GETFILE() Returns Empty String in Some Cases

On 2017-07-31 16:04, Ken Dibble wrote:
> GAHHH!!! That's it!!
> 
> Not a PRIVATE declaration, the variable is declared LOCAL.
> 
> But in application mode there is a field in an open table with the 
> same name as the variable. I applied the "essential m-dot" to the 
> variable, and that fixed it.


That "variable with same name as a field name" has screwed me in the past more 
than once.  That's why I like my "outdated" variable declarations as pcFilename 
because I definitely don't conflict with MyTable.cFilename.  That works for me. 
 Sorry for the purists who see that as horrible.  lol

[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/18725b8cd2d5d247873a2baf401d4ab2b477c...@ex2010-a-fpl.fpl.LOCAL
** 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.

Re: GETFILE() Returns Empty String in Some Cases

[mbsoftwaresolutions]

On 2017-07-31 16:04, Ken Dibble wrote:

GAHHH!!! That's it!!

Not a PRIVATE declaration, the variable is declared LOCAL.

But in application mode there is a field in an open table with the
same name as the variable. I applied the "essential m-dot" to the
variable, and that fixed it.



That "variable with same name as a field name" has screwed me in the 
past more than once.  That's why I like my "outdated" variable 
declarations as pcFilename because I definitely don't conflict with 
MyTable.cFilename.  That works for me.  Sorry for the purists who see 
that as horrible.  lol


___
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/f47313761596249aa48cc8929c7e7...@mbsoftwaresolutions.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.

Re: GETFILE() Returns Empty String in Some Cases

[Brant E. Layton]

Hi All,

I think that mypath (or whatever variable you are expecting to contain the 
returned path) needs to be initialized prior to the GETFILE call...


In the code below, make it look like:

private mypath

mypath= ''

mypath = GETFILE(...)

Perhaps your standalone application initializes mypath, and the application 
doesn't?||

||

|Brant Layton|
|480.964.1316|
On 7/31/2017 12:24 PM, profoxtech-requ...@leafe.com wrote:


--
Message: 10
Date: Mon, 31 Jul 2017 15:23:06 -0400
From: Philip Borkholder <plbor...@netzero.net>
To: profoxt...@leafe.com
Subject: Re: GETFILE() Returns Empty String in Some Cases
Message-ID: <588017c0-9341-521a-b853-270a04a58...@netzero.net>
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

Are you declaring your variable as PRIVATE right before you run the
GETFILE() command?

PRIVATE mypath

mypath = GETFILE("csv","Spreadsheet","Open",0,"Open Spreadsheet")

Just curious if that is affecting it.

-Philip


On 7/31/2017 2:19 PM, Ken Dibble wrote:

Permissions issue on the folder or on the selected file?

I don't see how. In both cases it's me doing the test, on the same
computer, with the same folder and file, with the same domain
administrator account.

Ken Dibble
www.stic-cil.org


[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/bf947607-10a5-a8c8-3e91-5c5687aaa...@futureone.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.

Re: GETFILE() Returns Empty String in Some Cases

[Philip Borkholder]

You are welcome Ken,

I had the same thing happen to me awhile back that had me stumped!

... sometimes it's the last thing we would consider being the problem. :-)


On 7/31/2017 4:04 PM, Ken Dibble wrote:


Are you declaring your variable as PRIVATE right before you run the 
GETFILE() command?


PRIVATE mypath

mypath = GETFILE("csv","Spreadsheet","Open",0,"Open Spreadsheet")

Just curious if that is affecting it.


GAHHH!!! That's it!!

Not a PRIVATE declaration, the variable is declared LOCAL.

But in application mode there is a field in an open table with the 
same name as the variable. I applied the "essential m-dot" to the 
variable, and that fixed it.


Thanks very much Philip!!

Ken Dibble
www.stic-cil.org


[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/5d7ce745-1a70-880b-f621-fb14da530...@netzero.net
** 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.

Re: GETFILE() Returns Empty String in Some Cases

[Ken Dibble]

Are you declaring your variable as PRIVATE right before you run the 
GETFILE() command?


PRIVATE mypath

mypath = GETFILE("csv","Spreadsheet","Open",0,"Open Spreadsheet")

Just curious if that is affecting it.


GAHHH!!! That's it!!

Not a PRIVATE declaration, the variable is declared LOCAL.

But in application mode there is a field in an open table with the 
same name as the variable. I applied the "essential m-dot" to the 
variable, and that fixed it.


Thanks very much Philip!!

Ken Dibble
www.stic-cil.org 



___
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/B0.1B.21563.D4D8F795@cdptpa-omsmta03
** 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.

Re: GETFILE() Returns Empty String in Some Cases

[Philip Borkholder]

Are you declaring your variable as PRIVATE right before you run the 
GETFILE() command?


PRIVATE mypath

mypath = GETFILE("csv","Spreadsheet","Open",0,"Open Spreadsheet")

Just curious if that is affecting it.

-Philip


On 7/31/2017 2:19 PM, Ken Dibble wrote:



Permissions issue on the folder or on the selected file?


I don't see how. In both cases it's me doing the test, on the same 
computer, with the same folder and file, with the same domain 
administrator account.


Ken Dibble
www.stic-cil.org


[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/588017c0-9341-521a-b853-270a04a58...@netzero.net
** 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.

Re: GETFILE() Returns Empty String in Some Cases

[Ken Dibble]

Permissions issue on the folder or on the selected file?


I don't see how. In both cases it's me doing the test, on the same 
computer, with the same folder and file, with the same domain 
administrator account.


Ken Dibble
www.stic-cil.org 



___
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/F8.C3.10880.EC47F795@cdptpa-omsmta01
** 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.

Re: GETFILE() Returns Empty String in Some Cases

[Fred Taylor]

Permissions issue on the folder or on the selected file?


Fred

On Mon, Jul 31, 2017 at 11:03 AM, Ken Dibble  wrote:

>
> What kind of value does "parms" contain?
>>
>
> The actual code is:
>
> mypath = GETFILE("csv","Spreadsheet","Open",0,"Open Spreadsheet")
>
> In both stand-alone and application mode, this displays the file dialog
> correctly and pointing to the location that I expect.
>
> However, I have also tried it as:
>
> mypath = GETFILE("csv","File","Open",0,"Open Spreadsheet")
>
> because someone suggested that the dialog can't display more than 10
> characters to the left of the file name textbox. That didn't help.
>
> I have also tried it simply as:
>
> mypath = GETFILE()
>
> Then I manually navigate to the file location. But that doesn't make it
> work either.
>
> I'm sorry, I got sidetracked and failed to properly end the original
> message.
>
> I meant to conclude with:
>
> Thanks in advance.
>
> Ken Dibble
> www.stic-cil.org
>
>
[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/CAJCBksqDvhKjchU4Lvzzgr==sfgt-wfvpfzxyrdbbdupy+z...@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.

RE: GETFILE() Returns Empty String in Some Cases

[Ken Dibble]

What kind of value does "parms" contain?


The actual code is:

mypath = GETFILE("csv","Spreadsheet","Open",0,"Open Spreadsheet")

In both stand-alone and application mode, this displays the file 
dialog correctly and pointing to the location that I expect.


However, I have also tried it as:

mypath = GETFILE("csv","File","Open",0,"Open Spreadsheet")

because someone suggested that the dialog can't display more than 10 
characters to the left of the file name textbox. That didn't help.


I have also tried it simply as:

mypath = GETFILE()

Then I manually navigate to the file location. But that doesn't make 
it work either.


I'm sorry, I got sidetracked and failed to properly end the original message.

I meant to conclude with:

Thanks in advance.

Ken Dibble
www.stic-cil.org


___
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/6F.7D.20123.CE07F795@cdptpa-omsmta02
** 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.

RE: GETFILE() Returns Empty String in Some Cases

[Richard Kaye]

What kind of value does "parms" contain?

--

rk

-Original Message-
From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Ken Dibble
Sent: Monday, July 31, 2017 1:27 PM
To: profoxt...@leafe.com
Subject: GETFILE() Returns Empty String in Some Cases

Hi folks,

VFP 9 SP1 on Windows 7 Ultimate.

I have a process to let the user choose a file. The user opens a .scx 
form, presses a button to run some code that calls GETFILE(), and 
when the user has done so, the path and file name are displayed on the form.

When I run this form in stand-alone mode, this works fine. GETFILE() 
returns the path and file name to a string variable and I then 
display the variable contents on the form.

When I run this form from within the full application, GETFILE() 
displays the proper location and behaves perfectly fine, but when the 
user chooses a file, it always returns an empty string.

I've tracked this in the debugger. In both cases, I emphasize, from 
the point the user presses the button, the exact same code runs, at 
each point generating the exact same results, until we get past

myvariable = GETFILE(parms)

line, at which point myvariable is empty in application mode, but 
contains the full path and file name in stand-alone mode.

I am following the correct procedure to obtain an appropriate full 
path, and in both cases the GETFILE() dialog displays the correct 
location and is configured properly according to my parameters.

It simply won't return a value when run from inside the application.

I've read everything with "GETFILE" in the subject line in the 
leafe.com archives. I can't find anything that addresses this situation.

My application does not use the _SCREEN (SCREEN = OFF in the 
config.fpw file). Instead I have my own main window which is modeless 
and "2 - as top level". Normally the import window, which is modeless 
and  (1 - in top level), is called from a modal form that is opened 
from a menu item.

To eliminate the possibility that this modal/modeless business is 
interfering, I put the button that opens the import form directly on 
my main window, so that the only open windows are the modeless 
top-level form and the modeless in-top-level import form before the 
GETFILE() dialog is called. That's as close as I can get to running 
the import form in stand-alone mode. This did not help.

The stand-alone mode of my framework's forms actually creates the 
same environment that exists in the full application before opening 
the form, so I can't see how not actually running the full 
application can make a difference. I emphasize, again, in the 
debugger, from the point the user presses that button every single 
step runs exactly the same way, and returns the same results, up to 
the GETFILE() dialog, in both stand-alone and full-application modes.

My code stores the location that I want GETFILE() to display to a 
variable, mypath, so I do:

oldpath = FULLPATH(CURDIR())

CD (JUSTPATH(mypath))

myvariable = GETFILE(parms)

CD (JUSTPATH(oldpath))

Some people suggest using SET DEFAULT TO ..., so I also tried it like this:

oldpath = FULLPATH(CURDIR())

CD (JUSTPATH(mypath))

SET DEFAULT TO (mypath)

myvariable = GETFILE(parms)

CD (JUSTPATH(oldpath))

SET DEFAULT TO (oldpath)

That doesn't help either.

The default is for the file name and path to contain spaces, and this 
works just fine in stand-alone mode. But I renamed the test file to 
remove spaces, and put the file in C:\foo, so there are no spaces 
anywhere in the path or file name, and it still doesn't work full 
application mode. GETFILE() just returns an empty string.

I've also tried using PUTFILE() instead of GETFILE(), even though 
it's less elegant for my purpose. PUTFILE() also works as I expect in 
stand-alone mode but returns an empty string in full-application mode.

LOCFILE() is not an option because I can't mandate a file name for this.

This is driving me absolutely bonkers.

Possibly I could roll my own file dialog, but short of that, can 
anyone provide any suggestions to explain why this is happening?

Any suggestions 


[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/mwhpr10mb177459dcc17d3f5461cf49d1d2...@mwhpr10mb1774.namprd10.prod.outlook.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.

GETFILE() Returns Empty String in Some Cases

[Ken Dibble]

Hi folks,

VFP 9 SP1 on Windows 7 Ultimate.

I have a process to let the user choose a file. The user opens a .scx 
form, presses a button to run some code that calls GETFILE(), and 
when the user has done so, the path and file name are displayed on the form.


When I run this form in stand-alone mode, this works fine. GETFILE() 
returns the path and file name to a string variable and I then 
display the variable contents on the form.


When I run this form from within the full application, GETFILE() 
displays the proper location and behaves perfectly fine, but when the 
user chooses a file, it always returns an empty string.


I've tracked this in the debugger. In both cases, I emphasize, from 
the point the user presses the button, the exact same code runs, at 
each point generating the exact same results, until we get past


myvariable = GETFILE(parms)

line, at which point myvariable is empty in application mode, but 
contains the full path and file name in stand-alone mode.


I am following the correct procedure to obtain an appropriate full 
path, and in both cases the GETFILE() dialog displays the correct 
location and is configured properly according to my parameters.


It simply won't return a value when run from inside the application.

I've read everything with "GETFILE" in the subject line in the 
leafe.com archives. I can't find anything that addresses this situation.


My application does not use the _SCREEN (SCREEN = OFF in the 
config.fpw file). Instead I have my own main window which is modeless 
and "2 - as top level". Normally the import window, which is modeless 
and  (1 - in top level), is called from a modal form that is opened 
from a menu item.


To eliminate the possibility that this modal/modeless business is 
interfering, I put the button that opens the import form directly on 
my main window, so that the only open windows are the modeless 
top-level form and the modeless in-top-level import form before the 
GETFILE() dialog is called. That's as close as I can get to running 
the import form in stand-alone mode. This did not help.


The stand-alone mode of my framework's forms actually creates the 
same environment that exists in the full application before opening 
the form, so I can't see how not actually running the full 
application can make a difference. I emphasize, again, in the 
debugger, from the point the user presses that button every single 
step runs exactly the same way, and returns the same results, up to 
the GETFILE() dialog, in both stand-alone and full-application modes.


My code stores the location that I want GETFILE() to display to a 
variable, mypath, so I do:


oldpath = FULLPATH(CURDIR())

CD (JUSTPATH(mypath))

myvariable = GETFILE(parms)

CD (JUSTPATH(oldpath))

Some people suggest using SET DEFAULT TO ..., so I also tried it like this:

oldpath = FULLPATH(CURDIR())

CD (JUSTPATH(mypath))

SET DEFAULT TO (mypath)

myvariable = GETFILE(parms)

CD (JUSTPATH(oldpath))

SET DEFAULT TO (oldpath)

That doesn't help either.

The default is for the file name and path to contain spaces, and this 
works just fine in stand-alone mode. But I renamed the test file to 
remove spaces, and put the file in C:\foo, so there are no spaces 
anywhere in the path or file name, and it still doesn't work full 
application mode. GETFILE() just returns an empty string.


I've also tried using PUTFILE() instead of GETFILE(), even though 
it's less elegant for my purpose. PUTFILE() also works as I expect in 
stand-alone mode but returns an empty string in full-application mode.


LOCFILE() is not an option because I can't mandate a file name for this.

This is driving me absolutely bonkers.

Possibly I could roll my own file dialog, but short of that, can 
anyone provide any suggestions to explain why this is happening?


Any suggestions 



___
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/44.CD.20123.7486F795@cdptpa-omsmta02
** 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.