[WASTE-list] Multiple views, shared controller (was: Re: WASTE 3.0 ClickLoop)

[Richard Laws]

Thank you!  Now if only I could stop getting that
param error with WENewViewWithCGContext(NULL, ...).

Richard

--- Marco Piovanelli <marco.piovanelli at pobox.com>
wrote:


> On Thu, 24 May 2007 10:26:50 -0700,

> Richard Laws (manistyman at yahoo.com) wrote:

> 

> 

> >One of the reasons I set aside my

> >WASTE-view-within-a-HIScrollView version of my

> HIView

> >was that I wanted a way of splitting the view to be

> >able to consult (and perhaps modify, copy, paste,

> >etc.) two or more sections of the text in the same

> >HIViewRef.  An HIScrollView's text subview would

> have

> >to respond to scrollable "scroll to" events with

> >WEScroll.  This is where the concept of

> >WEViewReference might come to the rescue.

> 

> Yes, that's the kind of scenario WASTE views were

> designed for.

> 

> >Consider the following: A parent HIViewRef is

> created

> >which creates a WASTE instance.  It then creates

> and

> >embeds one or more HIScrollViews, each containing a

> >'text' HIViewRef containing a WEViewReference

> created

> >with that single WASTE instance.

> 

> You probably want a SplitView (possibly modeled

> after

> the sample code in

> /Developer/Examples/Carbon/SplitView)

> containing two HIScrollViews, each of which, in

> turns,

> contains your WASTE-based HIView.  Each WASTE HIView

> would keep its own WEViewReference, but they would

> share

> the same controller (WEReference).

> 

> >My question is this: Would the multiple views work

> >independently when receiving scroll to events?

> 

> Yes.  Each WEViewReference has its own view and

> destination

> rectangles, and can scroll independently of the

> other.

> 

> >For example, I have two views of the same

> WEReference.

> >I've set my current WEViewReference to the lower of

> >the two.  I click that view's scroll bar.  I've got

> to

> >respond to that event (sent by the parent

> >HIScrollView) with WEScroll.

> 

> That WEScroll takes a WEReference, rather than a

> more natural WEViewReference, is only a historical

> artifact -- the original WASTE API wasn't designed

> for

> strict model-view-controller separation, but to be a

> drop-in replacement for TextEdit.  But internally,

> WEScroll, and many other view-centric APIs, are

> routed

> to the "current" view, which you can change at any

> point

> with WESetCurrentView().

> 

> In other words, instead of introducing a bunch of

> parallel view-centric APIs (WEScrollView,

> WESetViewDestRect,

> WESetViewViewRect, WEAdjustCursorInView, etc.) that

> duplicate

> the existing controller-centric APIs, I thought it

> simpler

> to maintain the old APIs, with the implicit

> stipulation

> that they operate on the current view.

> 

> >Would the upper view also scroll?

> 

> No.

> 

> >Or, not being the current WEViewReference, does it

> remain

> >stationary and stay that way when made current

> again?

> 

> Yes.

> 

> 

>                                     -- marco

> 

> -- 

> It's not the data universe only, it's human

> conversation.

> They want to turn it into a one-way flow that they

> have entirely

> monetized. I look at the collective human mind as a

> kind of

> ecosystem. They want to clear cut it. They want to

> go into the

> rainforest of human thought and mow the thing down.

> 

> 




      ____________________________________________________________________________________
Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center.
http://autos.yahoo.com/green_center/