Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Westi on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Alternative to GETFILE() ?

Status
Not open for further replies.

JRB-Bldr

Programmer
May 17, 2001
3,281
US
I have been using GETFILE() quite successfully for a good while now, but I need to look into an alternative.

I have a VFP7 application which is running both locally within workstations and within a server under Terminal Services mode for remote users.

When locally executed the GETFILE() works just fine.

However in the Terminal Services environment, the execution of GETFILE() or even GETDIR() will totally lock up the associated server on which the EXE is running. And the problem is not isolated to a user going into one directory or another.

As a consequence I am looking for a work-around. Is there an alternative to GETFILE() such as using Windows Scripting or another approach?

Obviously I will need to test the alternatives as well, but I cannot seem to get this to work.

Any advice or suggestions would be greatly appreciated.

Thanks,
JRB-Bldr
 
getfile() mostly is a win API call to common dialogs. See here:
Perhaps that solves the problem, if you have the same problem it may be in that API class mscomdlg.commondialog.

ou can use a listbox with RowSourceType set to 7 (files), which looks bad but may work better.

And then you may have the problems due to restricted rights of the TS users regading directory access.

Bye, Olaf.
 
Olaf, Thanks for the reply.

I tried the referenced code in my own local workstation (not in Terminal Service mode).
Code:
loComDialog = newobject( "mscomdlg.commondialog" )

* Set filters
loComDialog.Filter = "All Files (*.*)|*.*|Text Files(*.txt)|*.txt|Batch Files (*.bat)|*.bat"
* Specify default filter
loComDialog.FilterIndex = 2
* Set "Cancel" error trap
oErr = ON('ERROR')
ON ERROR plCancel = .T.
plCancel = .F.
* Display the Open dialog box
loComDialog.ShowOpen()
* Get File Name
lcFileName = loComDialog.FileName

if not plCancel
  Messagebox( lcFileName )
else
  messagebox( 'User clicked Cancel' )
endif

The code executed without an error, but nothing ever appeared on-screen similar to the GETFILE() browse window.

The code went on to inform me that the 'User clicked Cancel' despite my not having even seen a button to click. Let alone allowing me to click on it.

Any additional suggestions?

Thanks,
JRB-Bldr
 
You aren't populating the variable?
Code:
plCancel = ! loComDialog.ShowOpen()
 
I did assume it works, but you're right. And since ON ERROR plCancel = .T. catches any error you don't get to see the OLE exception.

This works for me on XP:
Code:
loComDialog = newobject( "mscomdlg.commondialog" )

* Set filters
loComDialog.Filter = "All Files (*.*)|*.*|Text Files(*.txt)|*.txt|Batch Files (*.bat)|*.bat"
* Specify default filter
loComDialog.FilterIndex = 2
loComDialog.MaxFileSize = 260

* Display the Open dialog box
loComDialog.ShowOpen()
* Get File Name
lcFileName = loComDialog.FileName

if Not Empty(lcFilename)
  Messagebox( lcFileName )
else
  Messagebox( 'User clicked Cancel' )
endif

Bye, Olaf.
 
A better use of your time might be a meeting (or yelling match ;-)) with the administrator of that terminal server. We have a half-dozen or so clients running on terminal servers and they don't have this problem, but getting administrators to set them up properly is invariably a problem during the setup phase.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top