comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Re: Locating a (bitmap) file
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
Re: Locating a (bitmap) file [message #22652 is a reply to message #22650] Wed, 29 November 2000 00:00 Go to previous messageGo to previous message
John-David T. Smith is currently offline  John-David T. Smith
Messages: 384
Registered: January 2000
Senior Member
Dave Greenwood wrote:
>
> I 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?
>>
> [snip]
>> 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.)
> [snip]
>
> From one of those anonymous RSI/Kodak lurkers came the following suggestion
> which will solve my problem:
>
>> If you make a call to HELP, CALLS = calls, the return is a
>> string array whose first element (calls[0]) contains the name of
>> the current routine (which you'll have to STRSPLIT to get out the
>> routine name by itself.)
>>
>> HELP, CALLS = calls
>> thisroutine = (STRSPLIT(calls[0], ' ', /EXTRACT))[0]
>>
>> With that you can call ROUTINE_INFO(name, /SOURCE) to get the
>> path to the .sav or .pro file that owns that routine. Find
>> the right-most directory separator character for your
>> platform (STRPOS(/REVERSE_SEARCH)) in the info.path field,
>> then extract the string up to that point.
>>
>> source = ROUTINE_INFO(thisroutine, /SOURCE)
>> CASE STRUPCASE(!version.os_family) of
>> 'WINDOWS' : dirsep = '\'
>> 'UNIX' : dirsep = '/'
>> 'MACOS' : dirsep = ':'
>> 'VMS' : dirsep = ']'
>> ELSE : dirsep = ''
>> ENDCASE
>> root = STRMID(source.path, 0, STRPOS(source.path, dirsep, /REVERSE_SEARCH))
>> Let's say your bitmaps are in a subdirectory named "bitmaps" beneath
>> your source directory. You can build the appropriate file name
>> via
>>
>> file = FILEPATH('mybitmapfile.bmp', Root = root, SubDir = ['bitmaps'])
>>
>> One advantage of using this method is that there is only one step
>> that actually requires platform-specific code, where you use
>> perhaps a CASE statement based on !version.os_family to define the
>> directory separator character.
>>
>> A second advantage is that you never have to worry about the installation
>> directory that your "customer" has defined; directory and file paths are
>> based on locations relative to wherever it is they put the .pro/.sav files.
>
> This second advantage is exactly what I wanted to achieve.

Of course, we *could* have hoped RSI would have simply allowed embedded
representations of color bitmaps, just as they did black and white
ones. Like:

widget_button,value=mybmp

instead of

widget_button,value='my.bmp'

Maybe they thought we were not smart enough to encode color icons.
5.4.1 perhaps?

JD

--
J.D. Smith | WORK: (607) 255-6263
Cornell Dept. of Astronomy | (607) 255-5842
304 Space Sciences Bldg. | FAX: (607) 255-5875
Ithaca, NY 14853 |
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Previous Topic: IDLDE crash on printing!
Next Topic: Contours driving me mad

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Fri Oct 10 21:20:58 PDT 2025

Total time taken to generate the page: 0.71804 seconds