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.
