| A problem with pickfile? [message #6330] |
Tue, 04 June 1996 00:00  |
Tim Patterson
Messages: 65
Registered: October 1995
|
Member |
|
|
I seem to be having a problem with Pickfile on an OSF Alpha,
IDL 4.0.1. Sometimes it returns just the file name
and at other times it appends the path to the file name,
whether I use the GET_PATH option to return the path separately
or not. It seems to work on the first Pickfile call in a session
and then causes problems afterwards.
I'm looking through my code and the pickfile code
to see why this happens, but I was wondering if anybody else
had seen this problem and knew what could cause it.
Thanks
Tim
|
|
|
|
| Re: A problem with pickfile? [message #6389 is a reply to message #6330] |
Tue, 18 June 1996 00:00  |
Tim Patterson
Messages: 65
Registered: October 1995
|
Member |
|
|
Julien Flack wrote:
> I had a little routine to do exactly the above (check for '/' or
> a '\' in the filename string). However, notice that under Motif
> it is possible to get a return filename something like: 'temp/'.
> Therefore, to find out if the returned file contains the path
> you must search for a separtor and make sure that the position
> of the separator is not equal to strlen()-1.
>
> I agree, this inconsistency, although not unsurmountable,
> is a little messy. It would be better if the convention was that
> the returned filename never included the path.
>
> --
> Julien.
Unfortunately, if you want to be platform independent, you also
need to check for VMS type directory structure too.
In the end, I used an idea that Phil Willams sent me to strip
out the path name if it existed in an OS independent way:
file = pickfile(get_path = path)
if strpos(file, path) eq 0 then $
file = strmid(file,strlen(path),strlen(file))
However, I put this into the PICKFILE.PRO code so that it
always returns just the file name, and I have to use the
GET_PATH if I need to know the directory path.
I would have liked to fix the widget so that it only copies the
file name into the text widget when selected from the file list,
but the code appeared to be built-in rather than a library
routine.
Tim
|
|
|
|
| Re: A problem with pickfile? [message #6395 is a reply to message #6330] |
Mon, 17 June 1996 00:00 |
j.flack
Messages: 1
Registered: June 1996
|
Junior Member |
|
|
In article <4pq3qm$l7d@usenet.ucs.indiana.edu>,
amaravad@silver.ucs.indiana.edu (ratnakar amaravadi) wrote:
> In article <31B4DEBE.2781@raptor.lpl.arizona.edu>,
> Tim Patterson <tim@raptor.lpl.arizona.edu> wrote:
>> Sorry to be generating my own thread here...
>>
>> Well, I managed to track down my problem, and it appears to be an
>> inconsitency in the way pickfile works and I can't see this mentioned
>> in the FAQ...
>>
>> If I call up pickfile as
>>
>> file = PICKFILE(GET_PATH = path)
>>
>> it creates a pickfile widget and I can select a file.
>> The variable path is always returned correctly, but the
>> variable file can vary dependent upon how I use the
>> pickfile widget.
>>
>> If I click on an already existing file, the path+file names
>> are copied into the selection widget and returned on pressing
>> OK. So I end up with
>>
>> file = /usr/tim/file.dat
>> and path = /usr/tim/
>>
>> However, if I type a filename into the Selection widget
>> to create a new file and press OK, I get:
>>
>> file = newfile.dat
>> and path = /usr/tim/
>>
>> Surely this inconsistency in pickfile is a bug of sorts.
>> After all, there is no need to copy the path into the selection
>> widget when it is available at the top of the pickfile widget
>> already. The documentation says pickfile returns a file name
>> and doesn't say it returns a complete path.
>>
>> I guess I'm going to have to add some OS-dependent code into
>> my routines each time I call pickfile just to make sure
>> that there is no path already attached to the filename unless
>> somebody can tell me a clever hack around this...
>>
>> Tim
>
> How about checking for '/' in the filename string. If you get
> a -1 then you have only a filename w/o path. If not -1 then
> pickfile has returned path+filename.
I had a little routine to do exactly the above (check for '/' or
a '\' in the filename string). However, notice that under Motif
it is possible to get a return filename something like: 'temp/'.
Therefore, to find out if the returned file contains the path
you must search for a separtor and make sure that the position
of the separator is not equal to strlen()-1.
I agree, this inconsistency, although not unsurmountable,
is a little messy. It would be better if the convention was that
the returned filename never included the path.
--
Julien.
|
|
|
|
| Re: A problem with pickfile? [message #6413 is a reply to message #6330] |
Thu, 13 June 1996 00:00 |
amaravad
Messages: 11
Registered: September 1994
|
Junior Member |
|
|
In article <31B4DEBE.2781@raptor.lpl.arizona.edu>,
Tim Patterson <tim@raptor.lpl.arizona.edu> wrote:
> Sorry to be generating my own thread here...
>
> Well, I managed to track down my problem, and it appears to be an
> inconsitency in the way pickfile works and I can't see this mentioned
> in the FAQ...
>
> If I call up pickfile as
>
> file = PICKFILE(GET_PATH = path)
>
> it creates a pickfile widget and I can select a file.
> The variable path is always returned correctly, but the
> variable file can vary dependent upon how I use the
> pickfile widget.
>
> If I click on an already existing file, the path+file names
> are copied into the selection widget and returned on pressing
> OK. So I end up with
>
> file = /usr/tim/file.dat
> and path = /usr/tim/
>
> However, if I type a filename into the Selection widget
> to create a new file and press OK, I get:
>
> file = newfile.dat
> and path = /usr/tim/
>
> Surely this inconsistency in pickfile is a bug of sorts.
> After all, there is no need to copy the path into the selection
> widget when it is available at the top of the pickfile widget
> already. The documentation says pickfile returns a file name
> and doesn't say it returns a complete path.
>
> I guess I'm going to have to add some OS-dependent code into
> my routines each time I call pickfile just to make sure
> that there is no path already attached to the filename unless
> somebody can tell me a clever hack around this...
>
> Tim
How about checking for '/' in the filename string. If you get
a -1 then you have only a filename w/o path. If not -1 then
pickfile has returned path+filename.
ratty
--
Ratnakar Amaravadi Software/Hardware Engineer
Department of Radiology I.U. School of Medicine
(317)274-1843 (w) amaravad@indiana.edu
(317)274-4074 (fax) ratty@foyt.indyrad.iupui.edu
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
