The Artima Developer Community
Sponsored Link

Agile Buzz Forum
Calendar for New Pollock - Step 2

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
James Robertson

Posts: 29924
Nickname: jarober61
Registered: Jun, 2003

David Buck, Smalltalker at large
Calendar for New Pollock - Step 2 Posted: Nov 7, 2005 1:26 PM
Reply to this message Reply

This post originated from an RSS feed registered with Agile Buzz by James Robertson.
Original Post: Calendar for New Pollock - Step 2
Feed Title: Pollock
Feed URL: http://www.cincomsmalltalk.com/rssBlog/pollock-rss.xml
Feed Description: Pollock - the next VW GUI
Latest Agile Buzz Posts
Latest Agile Buzz Posts by James Robertson
Latest Posts From Pollock

Advertisement

Now that we have the Calendar nominally loaded, we need to start the work to actually get it to run.

Moving The Classes

First, we need to move the Calendar classes from their fake superclasses we used last time to get them to load, on to the actual classes they are going to use as their superclasses.

We'll move Calendar to be a subclass of ComponentPair, CalendarArtist to ComponentPairArtist, and CalendarAgent to ComponentPairAgent:

	Smalltalk.Pollock defineClass: #Calendar
		superclass: #{Pollock.ComponentPair}
		indexedType: #none
		private: false
		instanceVariableNames: ''
		classInstanceVariableNames: ''
		imports: ''
		category: 'Pollock-Calendar'

	Smalltalk.Pollock defineClass: #CalendarAgent
		superclass: #{Pollock.ComponentPairAgent}
		indexedType: #none
		private: false
		instanceVariableNames: 'dropDown workingDate '
		classInstanceVariableNames: ''
		imports: ''
		category: 'Pollock-Calendar'
		
	Smalltalk.Pollock defineClass: #CalendarArtist
		superclass: #{Pollock.ComponentPairArtist}
		indexedType: #none
		private: false
		instanceVariableNames: 'interiorDecoration '
		classInstanceVariableNames: ''
		imports: ''
		category: 'Pollock-Calendar'

Now that this is done, we can remove our ActionDisplay fake-out classes from the (none) package... No code for that here, just go to that package and remove them.

Just For Fun

I can tell you right now that just moving the classes around isn't enough to make our Calendar work, but let's try anyway, and see what happens. In case we have forgotten, here is the code to open our test window:

	CalendarTest new openWindowWithCalendar

The problem is a Message Not Understood for #edgeRectangleIncludingBorderEdge:

Ch-Ch-Cha-Changes

Many things and APIs have changed between last year when we created our first implementation of Calendar, and now. I spent most of this summer documenting those changes in previous posts here. This particular "bug" was a change in the APIs of the frame information APIs.

In this case, this method was renamed to #innerEdgeRectangleIncludingBorder:, so we can change our method to:

	interiorDecoration: anInteriorDecorationBorder
		interiorDecoration notNil ifTrue: [self interiorDecoration artist setPane: nil].
		interiorDecoration := anInteriorDecorationBorder.
		anInteriorDecorationBorder isNil
			ifFalse: 
				[self interiorDecoration artist setPane: pane.
				self frame clipDisplayableBounds: (self innerEdgeRectangleIncludingBorder: anInteriorDecorationBorder)]
			ifTrue: [self frame clipDisplayableBounds: self borderEdgeRectangle].
		pane invalidate

And restart in the debugger... But that's not enough... We immediately get another Does Not Understand for #clipDisplayableBounds:. Again, the whole notion of Displayable and Visible for bounds is gone, and thus the new API to use is #innerEdgeRectangle:.

While we're at it, let's change the other call to the bad clipDisplayableBounds:. And to be complete, I'll give a another change... #borderEdgeRectangle has changed to #borderInnerEdgeRectangle, so let's change that too.

	interiorDecoration: anInteriorDecorationBorder
		interiorDecoration notNil ifTrue: [self interiorDecoration artist setPane: nil].
		interiorDecoration := anInteriorDecorationBorder.
		anInteriorDecorationBorder isNil
			ifFalse: 
				[self interiorDecoration artist setPane: pane.
				self frame innerEdgeRectangle: (self innerEdgeRectangleIncludingBorder: anInteriorDecorationBorder)]
			ifTrue: [self frame innerEdgeRectangle: self borderInnerEdgeRectangle].
		pane invalidate

If we restart the debugger with these changes, we now get a new Exception... Event not supported for event clicked.

No Rest For The Weary

As previously noted, #clicked has changed to #pressed and #rightClicked to #rightPressed. This is in the #createDisplayPart method:

	createDisplayPart
		displayPart := InputField new.
		displayPart frame: (FractionalFrame 
			fractionLeft: 0
			top: 0
			right: 1
			bottom: 1).
		displayPart frame rightOffset: [self artist buttonWidth negated].
		displayPart frame topOffset: self artist displayOffset.
		displayPart frame leftOffset: self artist displayOffset.
		displayPart frame bottomOffset: self artist displayOffset negated.
		displayPart setArtist: (self widgetPolicy dropDownListInputFieldArtistClass on: displayPart).
		displayPart interiorDecoration: self borderPolicyClass calendarInputFieldDecoration.
		displayPart setEnclosingPane: self.
		self isOpen
			ifTrue: [displayPart setupKeyboardFor: self]
			ifFalse: [self configure: #setupKeyboardFor: for: displayPart argument: self].
		displayPart when: #pressed send: #triggerEvent: to: self with: #pressed.
		displayPart when: #rightPressed send: #triggerEvent: to: self with: #righPressed.
		displayPart when: #doubleClicked send: #triggerEvent: to: self with: #doubleClicked.
		displayPart when: #aboutToLoseFocus send: #triggerEvent: to: self with: #aboutToLoseFocus.
		displayPart when: #losingFocus send: #triggerEvent: to: self with: #losingFocus.
		displayPart agent doNotIncludeInTabList.
		self when: #gettingFocus send: #activate to: displayPart.
		self when: #losingFocus send: #deactivate to: displayPart

That's how it is supposed to work, and if we try to accept that in the Debugger, we get a warning when trying to accept it:

    Declare "displayPart" as variable:

Well, that's a pointer to a much bigger problem. For the moment, we'll click on the "Leave Undeclared" button, and then exit the debugger, close our test window, and discuss where we go from here.

Embrace Change

Part of the move from ActionDisplay to ComponentPair, renamed and moved some of the guts. Where the displayPart was part of the main ActionDisplay Pane, it is now a part of the ComponentPairArtist, and is now called the tailPart. Additionally, the actionPart, while still part of the Artist, is now the named the headPart in the ComponentPairArtist.

Nap Time

Next time we'll go about moving all the parts to their correct places, and continue to get our Calendar working. However, our Calendar is now savable as a Package, and so I've saved it to the Cincom Public Repository: Pollock-Calendar - Version 2.0.

And So It Goes
Sames

Read: Calendar for New Pollock - Step 2

Topic: Smalltalk Solutions 2006 Call for Submissions Previous Topic   Next Topic Topic: Say What?

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use