| 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
|
|
|
|
| Re: Project newbie asks...well what about ENVI projects? [message #61630 is a reply to message #61627] |
Fri, 25 July 2008 08:58  |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Mort Canty writes:
> 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 :-(
Gives you something to do in retirement, updating
your book to a new version. ;-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: Project newbie asks...well what about ENVI projects? [message #61631 is a reply to message #61630] |
Fri, 25 July 2008 08:55 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Jeff N. writes:
> The reason I did this is because 1) it just seemed like an easier way
> to make sure that the top-level part of my menu always gets created
> and the lower-down menu items know that the top level menu item is
> there. and 2) Some menu items are generated or not-generated using
> conditional logic. I have some spectral library stuff distributed in
> text files, so i have logic that only creates the menu to process the
> spectral libraries if the spectral libraries are actually present. 3)
> It also lets me put debug commands in the menu that only i see, but
> normal users don't see when all the code gets distributed. Definitely
> handy stuff!
Good idea!
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: Project newbie asks...well what about ENVI projects? [message #61632 is a reply to message #61631] |
Fri, 25 July 2008 08:50 |
Mort Canty
Messages: 134
Registered: March 2003
|
Senior Member |
|
|
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
|
|
|
|
| Re: Project newbie asks...well what about ENVI projects? [message #61635 is a reply to message #61632] |
Fri, 25 July 2008 08:50 |
jeffnettles4870
Messages: 111
Registered: October 2006
|
Senior Member |
|
|
On Jul 25, 10:50 am, David Fanning <n...@dfanning.com> wrote:
> 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
> --
> David Fanning, Ph.D.
> Fanning Software Consulting, Inc.
> Coyote's Guide to IDL Programming:http://www.dfanning.com/
> Sepore ma de ni thui. ("Perhaps thou speakest truth.")
Thanks David.
I've definitely used the _Define_Buttons routines. For my particular
application, however, i've done things a little differently than the
standard method of puting the "define buttons" procedure at the top of
the .pro file containing the procedure you're trying to add a menu
item for. I created a separate pro file that does nothing but call
the define-buttons ENVI command, and has a little placeholder
procedure at the bottom.
So my "Menu.pro" file has this in it:
PRO MyApp_Menu_Define_Buttons, buttonInfo
;do all the menu items for the entire app
END
PRO Myapp_Menu
;do nothing at all
END
The reason I did this is because 1) it just seemed like an easier way
to make sure that the top-level part of my menu always gets created
and the lower-down menu items know that the top level menu item is
there. and 2) Some menu items are generated or not-generated using
conditional logic. I have some spectral library stuff distributed in
text files, so i have logic that only creates the menu to process the
spectral libraries if the spectral libraries are actually present. 3)
It also lets me put debug commands in the menu that only i see, but
normal users don't see when all the code gets distributed. Definitely
handy stuff!
Jeff
|
|
|
|
| Re: Project newbie asks...well what about ENVI projects? [message #61643 is a reply to message #61632] |
Fri, 25 July 2008 07:50 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
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
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
