Re: Project newbie asks...well what about ENVI projects? [message #61627] |
Fri, 25 July 2008 09:34  |
jeffnettles4870
Messages: 111 Registered: October 2006
|
Senior Member |
|
|
On Jul 25, 11:50 am, Mort Canty <m.ca...@fz-juelich.de> wrote:
> David Fanning schrieb:
>
>
>
>> Jeff N. writes:
>
>>> Now, however, i find myself writing a bunch of code that i want to
>>> distribute to several people, and the idea of setting up a project
>>> immediately starts to seem attractive. Here's the thing though....the
>>> code i'm writing is for ENVI. Basically i've got a bunch of .pro
>>> files that adds a new menu item to ENVI's main menu and then handles
>>> all the commands on that new menu item. So I think the relevant
>>> difference here between what i want to do and a normal (?) IDL project
>>> is that I don't want all of my .pro files to end up compiled into one
>>> big save file that you launch with a single command. I want to have
>>> one save file created for each .pro file. Is that possible? Is it
>>> possible to have the directory that the compiled code ends up in be
>>> different than the directory where the .pro files are (but maintain
>>> the directory structure)?
>
>>> I also have a resources folder that contains text files, images,
>>> spectral libraries, etc.....stuff that isn't code but still needs to
>>> end up in the "output" directory where all the compiled code ends up.
>
>>> In the alternative, should i be thinking about how i could write my
>>> own "build" program, that searches for .pro files, calls SAVE for
>>> them, etc. and then handles the resource directory?
>
>>> Any suggestions would be great.
>
>> This was a topic of conversation at yesterday's Extending
>> ENVI seminar. No one appears to be sure about the right
>> way to do this. One of the most sensible suggestions I
>> heard was to add your ENVI save-add folder to your
>> Workspace as a project, but to make sure it is NOT
>> on your IDL path.
>
>> This way, you can see the contents, drag your completed
>> save and pro files into it, etc., but not have to deal
>> with it otherwise.
>
>> I think you are going to have to hand-save the sav files
>> you want to add to ENVI. I would just do this in the normal
>> way in whatever project folder you are using at the moment,
>> then drag these files over to the save-add folder.
>
>> Note that there is a new way to create the ENVI buttons
>> now to make your added programs accessible to ENVI. You
>> no longer have to modify the ENVI menu text file.
>
>> Your user function has to have two modules in it: the
>> normal event handler module that gets called when the
>> action button is selected, and a procedure defined with
>> the same name as the event hander with a "_define_buttons"
>> attached to it:
>
>> PRO MyFunction_Define_Buttons, buttonInfo
>> .............
>> END
>
>> PRO MyFunction, event
>> ........................
>> END
>
>> Inside the "define buttons" procedure, you use the ENVI
>> routine ENVI_DEFINE_MENU_BUTTON to create your buttons.
>> Keywords allow you to name and position the button in
>> relation to other buttons, etc.
>
>> Apparently, this has been an undocumented feature for a
>> long time, but it has been exposed in this release. It is
>> very slick, I think.
>
>> Cheers,
>
>> David
>
> Right, but don't forget to plunk the file into SAVE_ADD, so that the new
> menu items are there when ENVI comes up. Wish to heck they'd "exposed"
> this feature before I published my book :-(
>
> Mort
Yep, That certainly has to happen. While we're talking about little
known ENVI tricks, I also recently found out about
ENVI_GET_CONFIGURATION_VALUES, a function that returns a structure for
config settings. Useful if you want to find out if your user has a
customized save_add directory like me :) I found it via a Help, /
routines call while ENVI was running, but turns out it's actually in
the documentation now. Now we just need an
ENVI_SET_CONFIGURATION_VALUES!
Jeff
|
|
|