On Sat, 25 Jan 2003 16:08:31 -0000 Tomas Frydrych <[EMAIL PROTECTED]> wrote:

TF> 
TF> ap_Win32Frame.cpp/h, ap_Win32FrameImpl.cpp/h: fixed a nasty 
TF> bug in the _bindToolbars() mechanism; incidentaly ap_Win32Frame 
TF> and ap_Win32FrameImpl are rather messed up -- stuff that should 
TF> be in the implementation is in the frame.
TF> 

Note: toolbar stuff is inprogress (until today I haven't had a
chance to work on it) so it has yet to be split (i.e. unaltered), 
and this is a known issue.  I also have other changes in my local
tree, where there is almost nothing to ap_Win32Frame, so I'm
wondering (ignoring anything related to toolbars) what implementation
stuff is there in ap_Win32Frame that should be in ap_Win32FrameImpl?  
[I am going to ignore the funny issue of ap_Win32FrameImpl is the
implementation of ap_Win32Frame which is the Windows implementation of
ap_Frame.]

Let's see, methods in ap_Win32Frame that don't directly forward to ap_Win32FrameImpl
- the construction/destruction/initialization stuff, I don't see anything
here that should be put into the impl
- toolbar functions, covered above, being done as I write this
- bindToolbars, already moved in my local tree and I see now you did this
in cvs version as well
- toggleStatusBar,  it calls some FrameData stuff, which I thought was
silly to have the impl do (why FrameData still exists now that there is
an impl class I'm not sure, but more work than I wanted to do) and
then calls into the impl class to update the container window.
- get/setZoomPercentage, calls super class func or uses FrameData
- createViewGraphics, calls impl to create, sets the zoom, returns
- setViewFocus, empty
- createScrollBarListener, clearly marked as INPROGRESS
- replaceView, override to add in code because of a logic flaw somewhere
- scrollFuncX/Y, gets the Frame then calls impl function
- that's it

I realize you don't have access to my local changes, but I
would appreciate it if sometime in the next few weeks after
I commit them if you would let me know what you think should
still be move to the impl class.

...
TF> Tomas
TF> 

Jeremy Davis
[EMAIL PROTECTED]



Reply via email to