[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Locating a (bitmap) file



Dave Greenwood wrote:
> 
> Using IDL 5.3 and Windows NT I've created an IDL windows application
> (thanks to the kind folks who responded to my recent posting on the
> subject).  My application uses a couple of color bitmap labels which
> are stored as .bmp files.  The application will be used on multiple
> systems, possibly in a separate location on each system.  I'd prefer
> not to hard code the location of the .bmp files.  The question is how?
> 
> I suppose I could use findfile to search candidate locations, but
> that still requires advance knowledge of each system where the
> application is used.
> 
> I wouldn't mind requiring the .bmp and .sav files to be in the same
> directory if I could somehow find out from within my application
> where the .sav file is located.  Is that possible?  (I tried !DIR but
> it points to some place in the RSI distribution.)
> 
> Is there a way to return a color bitmap from an IDL function like you
> can with a b/w bitmap?  That way I could compile the function and
> store it in the save file.
> 
> Since I'm not particularly experienced with IDL, I'm hoping that I've
> missed some (potentially obvious) way of dealing with this.

Assuming that your IDL directory (say /usr/idl_app) is in the IDL path, you could do
something like (on a unix system at least):

pos = STRPOS( !PATH, '/usr/idl_app/bmp_datafiles' )

begin_pos = RSTRPOS( !PATH, ':', pos ) + 1
end_pos   = STRPOS( !PATH, ':', pos ) - 1
file_path = STRMID( !PATH, begin_pos, end_pos - begin_pos + 1 ) + '/'

file = file_path + 'no1.bmp'

This does require the initial hardcoding of the location, but if it's in a generically
named directory, I don't see a problem with that (like most things in unix default to
/usr/bin or /usr/local/bin etc..). 

Alternatively, you could stick your code and data in a subdirectory of the IDL
distribution (like the old /user_contrib directory). Either way it will be a bit messy
since you have to take into account the different directory delimiters of different
systems, mac unix, windoze, vms...oops that's right, no more vms soon. :o(

paulv

-- 
Paul van Delst           Ph:  (301) 763-8000 x7274
CIMSS @ NOAA/NCEP        Fax: (301) 763-8545
Rm.207, 5200 Auth Rd.    Email: pvandelst@ncep.noaa.gov
Camp Springs MD 20746