RE: [platform-debug-dev] Threads and stack frames disappear in move from

[Darin Wright <Darin_Wright@xxxxxxxxxx>]

Nothing like remote debugging over a latent connection... but it still 
works with background content :-)

Ken says:

> 
> Break in DebugViewContentProvider.getChildren(..) when the parentElement
> is an instance of my IDebugTarget derivative (let's call it
> MyDebugTarget). It checks whether the parentElement is an instance of
> IStackFrame. It's not, so it calls fManager.getChildren(parentElement),
> which takes us to RemoteTreeContentManager.getChildren().
> 
> Here it calls RemoteTreeContentManager.getAdapter(parent), which checks
> whether parent is an instance of IDeferredWorkbenchAdapter. It's not. It
> _is_ an IAdaptable, so it calls
> MyDebugTarget.getAdapter(IDeferredWorkbenchAdapter.class), which returns
> null because it doesn't adapt to IDeferredWorkbenchAdapter (should it?).
> 

Does your debug target (and other debug elements) eventually subclass 
org.eclipse.core.runtime.PlatformObject? By subclassing PlatformObject, 
you will pick up adapters registered by the adapter extension and factory 
mechanisms. If you don't subclass PlatformObject, this will not happen for 
free. As well, your implementation of #getAdapter(...) in your debug 
elements should call super.getAdapter(...), to give the platform a chance 
to provide adapters that your model object does not provide directly.

For your convenience, we have provided an abstract org.eclipse.debug.core.
DebugElement implementation in Eclipse 3.1 that you may want to subclass 
when implementing your elements. Its not required, but might be 
convenient. 

Interestingly enough, you may have found a good note for our "migration" 
guide. The API of debug elements has not changed, but we assumed that if 
you implement IAdaptable you have extended PlatformObject to take 
advantage of extensible adapters.

Darin