mirror of https://github.com/lianthony/NT4.0
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
204 lines
6.8 KiB
204 lines
6.8 KiB
|
|
drop target registration at window-creation time
|
|
drop target revoke at window-destruction time
|
|
|
|
|
|
=================================
|
|
call sequences:
|
|
=================================
|
|
|
|
DoVerb(OLEIVERB_SHOW | OLEIVERB_UIACTIVATE)
|
|
SrvrCtrl::RunningToInPlace
|
|
_pInPlace->ActivateInPlace
|
|
CreateUI
|
|
SetObjectRects
|
|
ShowWindow
|
|
SrvrCtrl::InPlaceToUIActive [object is locked]
|
|
_pInPlace->ActivateUI
|
|
_pInPlaceSite->OnUIActivate
|
|
InstallUI
|
|
InstallFrameUI
|
|
InstallDocUI
|
|
SetFocus
|
|
|
|
Click outside UIActive object window and:
|
|
it's site transitions from OS_UIACTIVE to OS_INPLACE
|
|
(this forces any non-InSideOut object to OS_RUNNING):
|
|
_pInPlaceObject->InPlaceDeactivate()
|
|
[on the object side, in sctrl]
|
|
_pCtrl->TransitionTo(OS_LOADED)
|
|
UIActiveToInPlace() [object is unlocked]
|
|
_pInPlace->DeactivateUI()
|
|
RemoveUI()
|
|
ClearSelection();
|
|
RemoveDocUI();
|
|
_pDoc->SetActiveObject(NULL, NULL)
|
|
RemoveFrameUI();
|
|
hides tool windows
|
|
_pFrame->SetMenu(NULL, NULL, _hwnd);
|
|
_pFrame->SetActiveObject(NULL, NULL);
|
|
_pInPlaceSite->OnUIDeactivate(FALSE)
|
|
InPlaceToRunning()
|
|
_pInPlace->DeactivateInPlace()
|
|
DestroyUI();
|
|
reparents windows and destroys toolbar-trays
|
|
removes and destroys the menus
|
|
DetachWin();
|
|
destroys the IP window
|
|
_pInPlaceSite->OnInPlaceDeactivate();
|
|
_pInPlaceObject->Release();
|
|
>> object should now be "loaded" at it's site
|
|
|
|
|
|
=================================
|
|
PBrush surgery notes:
|
|
=================================
|
|
|
|
What are the windows?
|
|
|
|
pbrushWnd[i] ==
|
|
PARENTid 0 "pbParent" ParentWP -- the frame window
|
|
PAINTid 1 "pbPaint" PaintWP -- the drawing surface
|
|
TOOLid 2 "pbTool" ToolWP -- the tool tray
|
|
SIZEid 3 "pbSize" SizeWP -- the line thickness tool
|
|
COLORid 4 "pbColor" ColorWP -- the color tray
|
|
xxxxxxxxxx "pbFull" FullWP -- the preview (full-screen) window
|
|
xxxxxxxxxx "pbZoomOut" ZoomOtWP -- the zoomed-view window
|
|
|
|
|
|
Where are the windows?
|
|
procs:
|
|
Parent -- PARENTWP.C
|
|
Paint -- PAINTWP.C
|
|
Tool -- TOOLWP.C
|
|
Size -- SIZEWP.C
|
|
Color -- COLORWP.C
|
|
|
|
created:
|
|
Parent -- WndInitGlob
|
|
Paint -- WndInitGlob
|
|
Tool -- WndInitGlob
|
|
Size -- WndInitGlob
|
|
Color -- WndInitGlob
|
|
Full -- MenuCmd
|
|
ZoomOut -- MenuCmd
|
|
|
|
moved/sized:
|
|
ParentWP WM_SIZE procesing moves the children
|
|
|
|
shown/hidden:
|
|
|
|
destroyed:
|
|
Parent -- killed in TerminateServer
|
|
Full -- kills itself
|
|
ZoomOut -- kills itself
|
|
|
|
What communication paths exist between the windows?
|
|
|
|
Parent -- talks to all child windows (below)
|
|
Paint -- talks to "Parent", Paint; uses ZoomIn wndproc
|
|
Tool -- talks to "Parent", Paint
|
|
Size -- talks to Paint
|
|
Color -- talks to "Parent", Paint
|
|
Full -- talks to Paint
|
|
ZoomOut -- talks to "Parent"
|
|
|
|
|
|
=================================
|
|
Steps to InPlace:
|
|
=================================
|
|
|
|
1) build a server menu
|
|
|
|
2) build the InPace window
|
|
|
|
3) implement reparenting functions
|
|
|
|
4) additions to tool windows for use in floating-palette mode
|
|
|
|
5) take it out for a spin, do basic debug, show it off...
|
|
|
|
6) fix problems uncovered, review changes, incorporate sugestions...
|
|
|
|
7) build a drop target
|
|
|
|
8) implement the transfer object, take a stab at drag scrolling
|
|
|
|
9) set up conversion plumbing for OLE1 PBrush objects
|
|
|
|
10) debug, debug, debug!
|
|
|
|
|
|
=================================
|
|
Problems:
|
|
=================================
|
|
|
|
(1) The Window-positioning problem
|
|
|
|
There are a number of places in the old PBrush code that cause
|
|
a recalc of the size/position of the Paint, Tool, Size and Color
|
|
windows.
|
|
|
|
When InPlace, the new PBrush floats the Tool, Size and Color windows,
|
|
and gives the Paint window the full extent of the InPlace window. The
|
|
old recalc code hardcoded the positioning relationships between these
|
|
windows.
|
|
|
|
The solution implemented by the new PBrush code is to create simple
|
|
tool-tray windows to house the Tool, Size and Color windows and to
|
|
cause the old calculation/positioning code to leave these windows alone.
|
|
While InPlace (signaled via the global gfInPlace), the trays own
|
|
responsibility for setting the positions of the Tool, Size and Color windows.
|
|
|
|
In addition, the InPlace code causes the Paint, Tool, Size and Color
|
|
windows to be reparented to a window owned by the InPlace code. This
|
|
reparenting is reversed when the new PBrush UIDeactivates. The InPlace
|
|
window also forwards appropriate messages through to the Paint
|
|
window and the MenuCmd function so that commands, etc., get processed
|
|
as intended.
|
|
|
|
|
|
|
|
(2) The Menu-state problem
|
|
|
|
There are a number of places sprinkled through the old PBrush C code
|
|
where menus and sub-items are enabled/disabled. Access to these menus
|
|
is inconsistent, often MF_BYPOSITION: somtimes via hard-coded constants,
|
|
sometimes via defined constants, and sometimes through static index arrays.
|
|
|
|
When InPlace, the new PBrush uses a copy of the menu resource which
|
|
has had the File and View popups removed (at runtime). File was
|
|
removed because it is defined as a container menu. View was removed
|
|
because zoom is fundementally problematic for InPlace objects (see RandyKe,
|
|
TonyW, or NatBr for a review of the issues).
|
|
|
|
So, the old PBrush code attempts to access menu positions that are
|
|
wrong for the InPlace menus. The solution is to rationalize access
|
|
to the menus via shared (global) indexes and functions.
|
|
|
|
|
|
(3) The Mouse-capture problem
|
|
|
|
Paintbush uses mouse capture extensively. The mouse is captured whenever
|
|
a click hits the Paint window, and this capture is released when a mouse-move
|
|
event happens for a point outside the Paint window AND a drawing operation
|
|
is not being tracked. On Win32 mouse capture is thread-specific, so as long as
|
|
mouse moves are happening over a window owned by the same thread as PBrush,
|
|
there is a good chance a move message will be seen as the user sweeps out of
|
|
the Paint window. Unfortunately, in the LocalServer-InPlace scenario this is
|
|
not the case. The result is that the Paint window has no good (early)
|
|
opportunity to give up it's capture.
|
|
|
|
One possible "solution" would be to use the UIActive border as a buffer zone.
|
|
What if this zone isn't big enough (and reasonable movements get the cursor
|
|
across the zone before capture is released)? One HACK would be to create another,
|
|
transparent window under the border and Paint windows. The problem with this
|
|
(aside from it's gross overhead) is that a document could be scrolled such
|
|
that the PBrush object extends over the clipping boundary, loosing the border
|
|
altogether! An even grosser possibility would be to create a top-level
|
|
transparent window underneath the PBrush object.
|
|
|
|
The solution adopted is to NOT capture the cursor (except during tool tracking)
|
|
as long as PBrush is InPlace.
|
|
|
|
|