>>
>>Jim, I've gone back and reviewed the details of the problems we were having. Here's the problem with SP1. It's the same problem as with VFP8 original and BindEvent(). BindEvent() works fine with _Screen with events like ReSize and RightClick, but it apparently does NOT work with the OLEDragOver event. However, the older method of subclassing the _screen object DID WORK with this. With our app, users could drag-drop onto _Screen and it worked great, and users LIKED IT because it saved them from having to dig through forms to drag-drop items into the VFP application. THey could just throw the object onto _screen and the OleDragDrop event would figure out where it was supposed to go. Now that part of our apps is broken with SP1. I'm NOT a happy camper about this. The development team SHOULD NOT have broken the older capability without providing a completely compatible alternative, and you haven't.
>
>I tested this and BINDEVENTS() indeed does not work with the OLEDragOver. I see this with forms also, not just _screen. I also tested with the old screen hook code, and it works, but I managed to crash VFP about 10 times while playing around with it. Sergey had suggested using a container sized to the screen to process the drag events. I have a different suggestion, with using an AlwaysOnBottom form which is maximized to fill _screen. Your mileage may very, but this seems to work for me:
>
>

>_screen.addproperty('oMyForm')
>_screen.oMyform = NewObject('myform')
>_screen.omyform.show
>
>DEFINE CLASS myform AS form
>	oledropmode = 1
>	alwaysonbottom = .t.
>	windowstate = 2 && Maximized
>	titlebar = 0
>	borderstyle = 0
>	backcolor = _screen.backcolor
>	
>	procedure init
>		* react to changes in _screen backcolor
>		=BindEvent(_screen,'backcolor',this,'Setcolor',1)	
>	endproc
>	
>	PROCEDURE resize
> 		wait window Program() nowait
> 	endproc
>
>	PROCEDURE SetColor
> 		this.BackColor = _screen.backcolor
> 	endproc
>
>	PROCEDURE OLEDragOver
>	LPARAMETERS oDataObject, nEffect, nButton, nShift, nXCoord, nYCoord, nState
>	
>	DO CASE
>		CASE nState == 0		&&DRAG_ENTER
>			DO CASE
>				CASE oDataObject.GetFormat("OLE Variant Array")	&& Array
>					This.OLEDropHasData = 1		&&DROPHASDATA_USEFUL
>					This.OLEDropEffects = 1+2	&&DROPEFFECT_COPY + DROPEFFECT_MOVE
>					
>				CASE oDataObject.GetFormat(1)				&& Text
>					This.OLEDropHasData = 1		&&DROPHASDATA_USEFUL
>					This.OLEDropEffects = 1+2	&&DROPEFFECT_COPY + DROPEFFECT_MOVE
>					
>				CASE oDataObject.GetFormat(15)				&& Files CF_HDROP
>					This.OLEDropHasData = 1		&&DROPHASDATA_USEFUL
>					This.OLEDropEffects = 4		&&DROPEFFECT_LINK
>				OTHERWISE
>					This.OLEDropHasData = 0		&&DROPHASDATA_NOTUSEFUL
>			ENDCASE
>
>		CASE nState == 1	&& Drag Leave
>		CASE nState == 2	&& Drag Over
>	endcase
>ENDDEFINE
>

>
>A potential problem I saw is that you would have to have some mechanism to change the backcolor of the form when _screen.backcolor was changed, perhaps from changing Windows system colors. I incorporated a workaround for that in my code, but there may be other similar issues.

Thanks Jim. I think that your suggestion or some variation on the theme as suggested in other responses will solve the problem... but I haven't completely implemented anything yet.

The old screenhook method may have been unstable, but we luckily have had no problems using it for intercepting and processing OLEdragover, OLEdragdrop, and rightclick events.