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
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]
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.
GAAAAAHHH!!! 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
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.
GAAAAAHHH!!! 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]
On 2017-07-31 16:04, Ken Dibble wrote:
GAAAAAHHH!!! 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
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 <Table> 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-bounces@leafe.com] On Behalf Of mbsoftwaresolutions@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:
GAAAAAHHH!!! 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]
+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 DaveC@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_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 <Table> 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
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 john@jbweller.force9.co.uk:
+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 DaveC@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_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 <Table> 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]
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-bounces@leafe.com] On Behalf Of Koen Piller Sent: Tuesday, August 01, 2017 11:01 AM To: profoxtech@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
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.
+1, what John said!
Paul H. Tarver Tarver Program Consultants, Inc. Email: paul@tpcqpc.com
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of John Weller Sent: Tuesday, August 01, 2017 3:25 AM To: profoxtech@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 DaveC@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_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 <Table> 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]
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 <Table> 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
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, mbsoftwaresolutions@mbsoftwaresolutions.com 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 <Table> 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]
+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: paul@tpcqpc.com
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of mbsoftwaresolutions@mbsoftwaresolutions.com Sent: Monday, July 31, 2017 7:16 PM To: profoxtech@leafe.com Subject: Re: GETFILE() Returns Empty String in Some Cases
On 2017-07-31 16:04, Ken Dibble wrote:
GAAAAAHHH!!! 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]
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.
GAAAAAHHH!!! 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
-
Alan Bourke -
Dave Crozier -
John Weller -
Ken Dibble -
Koen Piller -
Laurie Alvey -
mbsoftwaresolutions＠mbsoftwaresolutions.com -
Paul H. Tarver -
Peter Cushing -
Philip Borkholder -
Richard Kaye