Submenu issue ...

> I was looking at Menu and MenuItem, specifically for MenuBar.
>
> I note that a subMenu can in fact be a code block, which is very nice
> and should serve two purposes
>    1. allow the submenu, when it is invoked by the user, to be
> customized based
>          on the state at the time of invocation
>    2. specifically NOT run the code in the block UNLESS the user
> invokes it
>          because the code will take time (say 3 or 4 seconds).
>
> Item 1 seems to be handled quite nicely, but item 2 is defeated by the
> invocation of
>    menu  findGuiResourcesIn: ...
> which procedes to send value to all those blocks.
>
> just something to think about -- I don't know how critical the
> "findGuiResouces:" invocation is,
> I have basically disabled it for any submenu's that are blocks, and so
> far it seems fine.
>

> Dear Dennis,
>    just FYI, the Custom Refactoring project encountered a similar
> issue in the pre-VW7 RB which we solved by caching the menu in a temp
> at the point of block creation as shown in the code below. (Changes in
> the VW7 RB meant we no longer needed this code in VW7.)  If your
> change to #findGuiResourcesIn: has problems (as I suspect it may) and
> you need a solution for a specific case, this approach might work,
> noting that it needs the right relationship between the block's point
> of declaration and the holder of the state whose change needs
> recomputation.  (I'd guess the gui resources for a block-derived
> submenu will _usually_ never change.)
>
>          Yours faithfully
>             Niall Ross
>
> BrowserCodeTool>>optimizedSelectMenu
>    "On methods (e.g. to check test results) with huge embedded
> strings, the selectMenu is expensive to compute, and it is computed
> multiple times when the RB's menu bar is built. Optimisations in
> methods like #enableMenu:except: help, but the onus really lies here,
> in not recreating the menu when neither the text nor the selection
> within it have changed.  Conveniently, because the menupick holds a
> block and we are called anew for each code tool, we can return a block
> and let our method temps hold the cached state."
>
>    | text interval selectionMenu |
>    ^
>    [(text == self text and: [interval = self selectedInterval])
>        ifTrue: [selectionMenu]
>        ifFalse:
>            [text := self text.
>            interval := self selectedInterval.
>            selectionMenu := self selectMenu]]
>
> Dennis Smith wrote:
>
>> I was looking at Menu and MenuItem, specifically for MenuBar.
>>
>> I note that a subMenu can in fact be a code block, which is very nice
>> and should serve two purposes
>>    1. allow the submenu, when it is invoked by the user, to be
>> customized based
>>          on the state at the time of invocation
>>    2. specifically NOT run the code in the block UNLESS the user
>> invokes it
>>          because the code will take time (say 3 or 4 seconds).
>>
>> Item 1 seems to be handled quite nicely, but item 2 is defeated by
>> the invocation of
>>    menu  findGuiResourcesIn: ...
>> which procedes to send value to all those blocks.
>>
>> just something to think about -- I don't know how critical the
>> "findGuiResouces:" invocation is,
>> I have basically disabled it for any submenu's that are blocks, and
>> so far it seems fine.
>>
>
>
>