$cinst.$class of a subwindow - 2

[David Walton]

Sure. I've been building my new app on the "single window" approach -  
rather like mac based (mail, itunes, etc) programs where you select a  
function from a tree list on the left side and the sub-window changes  
on the right, sets a bunch of references and installs menus on the  
main window. Since most of my functionality is already built into  
other windows, the sub-window thing is just right for that type of  
interface - and the interface is something people are already familiar  
with.

Lots of pitfalls though - modal vs modeless - keeping track of which  
event for which window is firing, how to override default window  
events and pass them back to sub-windows. It's been a real education!

On May 24, 2008, at 5:19 AM, Doug Kuyvenhoven wrote:

> Hi David:
>
> Very cool! I was unaware of the $subinst property. I ran into this  
> problem 2 weeks ago and couldn't figure out the solution. You nailed  
> it.
>
> Here's the code I put in the $construct of my window class... which  
> could be a standalone window instance or a subwindow instance
>
> If $cinst=$cwind
> 	; Not a subwindow
> 	Calculate ClassName as $cinst().$class().$name
> Else
> 	; Is being instantiated as a subwindow
> 	Calculate ClassName as $cinst.$subinst().$class().$name
> End If
>
> Note - the () parenthesis are required for proper notation evaluation.
>
> Thanks!
>
>
> Doug Kuyvenhoven
> Vencor Software - www.vencor.ca
>
> On 23-May-08, at 6:24 PM, David Walton wrote:
>
>> I'm not sure if this helps but you may want to look at $subinst for  
>> referencing the subwindow methods. It has saved me lots of  
>> headaches like this.
>>
>> HTH
>>
>> On May 23, 2008, at 3:51 PM, Terence J. Young, D.C. wrote:
>>
>>> Hi,
>>>
>>> You can also try removing the $construct method, if any, from  
>>> behind the second subwindow field of the parent window; perhaps  
>>> this is conflicting with the scope of the code executing within  
>>> the $construct method of the subwindow.  Methods placed behind the  
>>> subwindow field of a parent window have a special relationship  
>>> with the subwindow instatiated within them; the methods can be  
>>> called from within the subwindow as though they were public  
>>> methods within the subwindow themselves.
>>>
>>> terry
>>>
>>> omnislist at dataweaver.com wrote:
>>>> Hi $all,
>>>>
>>>> I have a generic line in my $construct, which assigns a popup  
>>>> menu to a headed list as follows:
>>>>
>>>> Do irListHeaded.$contextmenu.$assign(con('mpop',$cinst.$class(). 
>>>> $name))
>>>>
>>>> If a popup menu exists in the form 'mpopWindowName' then this  
>>>> works fine...or doesn't in some cases!
>>>>
>>>> I have two subwindows on a parent window, 'WindowParent'.
>>>> One is called 'WindowA', the other 'WindowB'
>>>> There are two popup menus in the library: 'mpopWindowA' and  
>>>> 'mpopWindowB'
>>>> When WindowA is instantiating, $cinst.$class().$name returns  
>>>> 'WindowA' but when WindowB is instantiating, this returns  
>>>> 'WindowParent'.
>>>>
>>>> Funny thing is, if I set a reference to $cinst, the reference  
>>>> seems to point to the subwindow, WindowB. However, itemReference. 
>>>> $class() still returns the parent window name.
>>>>
>>>> Any ideas?
>>>>
>>>> Rgds
>>>> Gav
>>>>
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com
>