| Re: ENVI menus, programmatically. [message #38541] |
Tue, 16 March 2004 14:25 |
Robert Moss
Messages: 74
Registered: February 1996
|
Member |
|
|
Peter Mason wrote:
> Robert Moss wrote:
>
>> Does anyone here know the trick to programmatically adding menu items
>> to ENVI? Yes, I have "googled" on this topic, and found one instance
>> that looked promising, but it doesn't really answer the question.
>> Clearly there is a way to do it... and it appears to involve creating
>> a procedure that has one parameter which is a data structure that
>> defines the menu structure. What happens inside this routine, or what
>> undocumented programs it may call, or what undocumented program call
>> it, is non-obvious. Any takers?
>>
>> Robert Moss, PhD
>> EOIR Technologies Inc.
>> robert.moss@nvl.DONOTSPAMTHEarmy.mil
>
>
> I wish that RSI would get on with it and document this interface as it is
> very useful. IMHO, they under-estimate the nuisance factor involved in the
> traditional route of editing the menu file. Even if you give
> copy-and-paste instructions to your users, it's _still_ a nuisance as they
> have to find the envi.men file, overcome the geek factor, and so on. Most
> ENVI users can't be having with this sort of run-around. (Other sorts,
> sure, but not this one :-))
> Whereas.
> I sort-of found out how this interface works a good few years ago and use it
> routinely. *It has been stable for a number of ENVI versions.* In the
> interests of motivating some genuine documentation, here's what I know:
>
> The system only kicks in if your file (.PRO or .SAV) is in ENVI's SAVE_ADD
> subdirectory.
>
> The action is in a special procedure that you write. This procedure is
> named after the .PRO or .SAV file that it's in: filename_define_buttons.
> For example, if the host file was called QWERTY.PRO or QWERTY.SAV then you
> would name your procedure: QWERTY_DEFINE_BUTTONS
>
> The procedure has one positional parameter. Call it B. So:
> pro qwerty_define_buttons, B
> I think that stuff can come in via B sometimes but have never worked out how
> to deal with that. What I know is that you can define B from scratch with
> just your own menu additions and - if you do it right - these additions will
> find their way into the ENVI menu.
>
> B is an array of structures, one element per item (node or leaf) of your
> menu additions. The structure definition is un-named, I think, and it
> looks like this:
> { parent:"", sibling:"", name:"", uvalue:"", event_handler:"",
> separator:0, display:0 }
> Straight away, you can see that it's a lot like an entry in the envi.men
> file.
> Anyway, for a given element in this structure array:
> Set PARENT to the name of an existing node under which to add this entry, or
> set it to an empty string to add this entry as a top-level item in the ENVI
> menu.
> Set SIBLING to the name of an existing node/leaf if you want this entry to
> appear just after it, or set it to an empty string to make this entry "go at
> the end".
> Set NAME to what you would like to call this node/leaf in the ENVI menu.
> Leave the other members empty/zero if this entry is a node. If it is a
> leaf (a module invocation) then continue...
> Set UVALUE to anything you like. (I don't use this item myself and don't
> know what it's for.)
> Set EVENT_HANDLER to the name of your module's top-level procedure (the same
> one that you would have specified in envi.men)
> I think that SEPARATOR gives you one of those menu partition things. I
> haven't used it.
> I think that DISPLAY, if set non-zero, might add your item to the display
> menu rather than the main menu. I haven't used it - I've always left it
> zero to add to the main menu.
>
> That's about it. You simply set up a structure array and return it.
> When ENVI starts, it goes looking in SAVE_ADD, restoring or compiling
> modules that it finds there. For each module, it'll look for a
> ..._DEFINE_BUTTONS procedure and it'll run it if found.
> What I don't know is how to get some interaction going if you have more than
> one module that's trying to add menus. i.e., If they share a common root
> node but it's a node that must be created, which one should have the
> honours? The trouble is that ENVI appears to discover files (in SAVE_ADD)
> according to some lower-level file-system thing rather than alphabetically,
> so you can't count on a discovery order. (I just try to avoid this
> situation by combining related modules into one .SAV file and having one
> DEFINE_BUTTONS procedure for the lot.)
>
> HTH
> Peter Mason
>
>
Thanks, Peter. You've made my life a little easier.
R
|
|
|
|
| Re: ENVI menus, programmatically. [message #38542 is a reply to message #38541] |
Tue, 16 March 2004 14:14  |
Peter Mason
Messages: 145
Registered: June 1996
|
Senior Member |
|
|
Robert Moss wrote:
> Does anyone here know the trick to programmatically adding menu items
> to ENVI? Yes, I have "googled" on this topic, and found one instance
> that looked promising, but it doesn't really answer the question.
> Clearly there is a way to do it... and it appears to involve creating
> a procedure that has one parameter which is a data structure that
> defines the menu structure. What happens inside this routine, or what
> undocumented programs it may call, or what undocumented program call
> it, is non-obvious. Any takers?
>
> Robert Moss, PhD
> EOIR Technologies Inc.
> robert.moss@nvl.DONOTSPAMTHEarmy.mil
I wish that RSI would get on with it and document this interface as it is
very useful. IMHO, they under-estimate the nuisance factor involved in the
traditional route of editing the menu file. Even if you give
copy-and-paste instructions to your users, it's _still_ a nuisance as they
have to find the envi.men file, overcome the geek factor, and so on. Most
ENVI users can't be having with this sort of run-around. (Other sorts,
sure, but not this one :-))
Whereas.
I sort-of found out how this interface works a good few years ago and use it
routinely. *It has been stable for a number of ENVI versions.* In the
interests of motivating some genuine documentation, here's what I know:
The system only kicks in if your file (.PRO or .SAV) is in ENVI's SAVE_ADD
subdirectory.
The action is in a special procedure that you write. This procedure is
named after the .PRO or .SAV file that it's in: filename_define_buttons.
For example, if the host file was called QWERTY.PRO or QWERTY.SAV then you
would name your procedure: QWERTY_DEFINE_BUTTONS
The procedure has one positional parameter. Call it B. So:
pro qwerty_define_buttons, B
I think that stuff can come in via B sometimes but have never worked out how
to deal with that. What I know is that you can define B from scratch with
just your own menu additions and - if you do it right - these additions will
find their way into the ENVI menu.
B is an array of structures, one element per item (node or leaf) of your
menu additions. The structure definition is un-named, I think, and it
looks like this:
{ parent:"", sibling:"", name:"", uvalue:"", event_handler:"",
separator:0, display:0 }
Straight away, you can see that it's a lot like an entry in the envi.men
file.
Anyway, for a given element in this structure array:
Set PARENT to the name of an existing node under which to add this entry, or
set it to an empty string to add this entry as a top-level item in the ENVI
menu.
Set SIBLING to the name of an existing node/leaf if you want this entry to
appear just after it, or set it to an empty string to make this entry "go at
the end".
Set NAME to what you would like to call this node/leaf in the ENVI menu.
Leave the other members empty/zero if this entry is a node. If it is a
leaf (a module invocation) then continue...
Set UVALUE to anything you like. (I don't use this item myself and don't
know what it's for.)
Set EVENT_HANDLER to the name of your module's top-level procedure (the same
one that you would have specified in envi.men)
I think that SEPARATOR gives you one of those menu partition things. I
haven't used it.
I think that DISPLAY, if set non-zero, might add your item to the display
menu rather than the main menu. I haven't used it - I've always left it
zero to add to the main menu.
That's about it. You simply set up a structure array and return it.
When ENVI starts, it goes looking in SAVE_ADD, restoring or compiling
modules that it finds there. For each module, it'll look for a
..._DEFINE_BUTTONS procedure and it'll run it if found.
What I don't know is how to get some interaction going if you have more than
one module that's trying to add menus. i.e., If they share a common root
node but it's a node that must be created, which one should have the
honours? The trouble is that ENVI appears to discover files (in SAVE_ADD)
according to some lower-level file-system thing rather than alphabetically,
so you can't count on a discovery order. (I just try to avoid this
situation by combining related modules into one .SAV file and having one
DEFINE_BUTTONS procedure for the lot.)
HTH
Peter Mason
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
