ProFox

profox@leafe.com

2704 discussions

Re: GETFILE() Returns Empty String in Some Cases
by Brant E. Layton 31 Jul '17

31 Jul '17

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-request(a)leafe.com wrote: > ------------------------------ > Message: 10 > Date: Mon, 31 Jul 2017 15:23:06 -0400 > From: Philip Borkholder <plborker(a)netzero.net> > To: profoxtech(a)leafe.com > Subject: Re: GETFILE() Returns Empty String in Some Cases > Message-ID: <588017c0-9341-521a-b853-270a04a58e6e(a)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]

1 0

RE: GETFILE() Returns Empty String in Some Cases
by Ken Dibble 31 Jul '17

31 Jul '17

>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

2 1

GETFILE() Returns Empty String in Some Cases
by Ken Dibble 31 Jul '17

31 Jul '17

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

2 1

"Source not available" -- seems to happen in the history of the list!
by mbsoftwaresolutions＠mbsoftwaresolutions.com 28 Jul '17

28 Jul '17

VFP9SP2 Frustrated!!! All of the sudden my 2003 project code wants to rebel. I'm trying to debug some things and when I try to step into the code--code which has worked since 2003, mind you--it now says "Source not available" DESPITE THE FACT that I'm in the Project's home folder, where the EXE resides (I did a Build EXE & Run after), and the PROGS subfolder is in my path. Here's my first call to create the Custom biz obj: https://www.screencast.com/t/5UsbNGGXBGr Then here's the next screenshot, showing that nasty message and confirming my curdir() and SET('Path'): https://www.screencast.com/t/E1UOoe9h You can see in the first that I've even changed the pathing of the object call to what it really is. I never do that; I always used relative pathing like this: NEWOBJECT("Class",".\progs\_bizobj.prg") I searched the ProFox archives and saw this thread: https://leafe.com/archives/full_thread/468343 ...but Kurt's issue was resolved by relocating the EXE to the proper path. Mine is in the same spot it has been for 14 years! As Sytze (RIP) suggested, I deleted all of the FXP and did a COMPILE c:\dev\fabmate11\progs\*.prg to recreate all of them. Using Richard's tip, I verified that yes indeed, my project does have Debug Info included/checked in the Project manager. Also reviewed this thread, started by Richard: https://leafe.com/archives/full_thread/392144. I renamed the EXE and ran the new one....nope, same bad behavior. So I've ruled out pathing, out-of-sync FXPs, and the Hale-Bopp comet. I'm thinking my next step is to recreate the project file from scratch and rebuild. Any other ideas? tia, --Mike

6 13

3+month onsite VFP gig in West Mifflin, PA
by mbsoftwaresolutions＠mbsoftwaresolutions.com 28 Jul '17

28 Jul '17

From Ellen at EPS: Seeking VFP Contractor One of our clients is seeking a VFP Developer for an on-site only 3+ month contract in West Mifflin, PA. Development is for an existing custom ERP App written in VFP9 with DBF backend. If you are interested, please email your resume to info(a)codemag.com. Please only respond if you are available on-site. Have a great day! Ellen Whitney EPS Software & CODE Magazine I can't go onsite; otherwise I'd apply.

1 0

Re: "Source not available" -- seems to happen in the history of the list!
by Gene Wirchenko 28 Jul '17

28 Jul '17

At 10:10 2017-07-27, Ted Roche <tedroche(a)gmail.com> wrote: >On Thu, Jul 27, 2017 at 11:20 AM, ><mbsoftwaresolutions(a)mbsoftwaresolutions.com> wrote: > > VFP9SP2 > > > > Frustrated!!! All of the sudden my 2003 project code wants to rebel. > >Well, it is fourteen. Teenagers! My app is 20. Should I worry that it might want to start a family? Sincerely, Gene Wirchenko

2 1

RE: Variable/Procedure Naming Conventions
by Gene Wirchenko 28 Jul '17

28 Jul '17

At 00:29 2017-07-27, Paul Newton <Paul.Newton(a)pegasus.co.uk> wrote: > True. Why is the variable name not dDue? > >Because it could be an amount due? How so if the the prefix "d" means date? [snip] Sincerely, Gene Wirchenko

1 0

Determining VFP field to be AutoInc or not
by mbsoftwaresolutions＠mbsoftwaresolutions.com 27 Jul '17

27 Jul '17

VFP9SP2 I'm retrofitting old code and need to identify if the field's IID field in AutoInc or not. Looks like AFIELDS() is my friend here for array elements 17 and 18. Just wondered if anyone else had a better way? Thanks. --Mike

4 10

[NF] The 2017 Top Programming Languages: Python jumps to No. 1
by Malcolm Greene 27 Jul '17

27 Jul '17

The 2017 Top Programming Languages: Python jumps to No. 1 (article and reddit comments)http://spectrum.ieee.org/computing/software/the-2017-top-programmi… Malcolm --- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html ---

2 1

Variable/Procedure Naming Conventions
by Paul H. Tarver 27 Jul '17

27 Jul '17

I was reading a chapter on 'Meaningful Names' in the book "Clean Code" by Robert C. Martin last night and right after he made a big point of using "Intention-Revealing Names" ie: make the name of a variable, procedure or function reflect its use, he then takes the opportunity to trash the Hungarian Notation system (and by extension I suppose any similar naming convention, including the YAlan Griver convention) saying that with today's strongly typed variables, notation like this is useless and should be avoided. Quite frankly, it hacked me off as I've spent the better part of 25 years learning and becoming disciplined enough to use the YAG naming convention as well as I could in FoxPro and I've used the same naming convention regardless of the language or its strongly typed variables because it works for me. In my world, any roadmap or breadcrumbs I can leave myself for future maintenance and standardization is a good thing. Thoughts? Paul H. Tarver Tarver Program Consultants, Inc. Email: <mailto:paul@tpcqpc.com> paul(a)tpcqpc.com --- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html ---

8 13

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

ProFox