Re: [cdt-dev] class StackFramesVMNode.IncompleteStackVMContext

[Pawel Piech <pawel.piech@xxxxxxxxxxxxx>]

Hi Dobrin,
Yes it is intentional.  The < more frames> element is not an IDMVMContext because it is not backed by any specific data model element, it is purely an invention of the presentation of the data model.  I suppose for practical reasons it may have been better to have it backed by a thread context directly, I'm not really sure actually.

Yes I think it is perfectly OK to have non DM elements in the view.  "Add New _expression_" element is another example.  If we were to implement grouping of large arrays into chunks, as the standard model does, I would think those would be non-DM elements. 

Cheers,
Pawel

On 08/11/2011 10:38 AM, Alexiev, Dobrin wrote:

Hello,

 

This is a question about the standard DSF VM adapters.

 

I was wandering why StackFramesVMNode.IncompleteStackVMContext does not derive from IDMVMContext?

When IncompleteStackVMContext is used as a viewer input for the other views, we will end up with CompositeDMVMContexts created with empty list of parents.

 

Later on, my _expression_ service will be called with that CompositeDMVMContext.

Now the CompositeDMVMContext derives from IDMContext, but has no parents.

 

In my DM hierarchy I was expecting to be able to get to my root parent, but when <…more frames…> node is selected I cannot get to it.

 

I see that in GDB’s _expression_ services MIExpressions there is a special handle for that:

 inside CreateExpression, if we can’t get to an execution context from the DM context a InvalidContextExpressionDMC is created.

 

I can do the same, but I wanted to make sure that StackFramesVMNode.IncompleteStackVMContext intentionally does not derive from IDMVMContext.

There can be other clients that receives IDMContext with no parents, and they have to accommodate for that.

 

I guess the generic question, is it OK for DSF to populate flexible threes with VM contexts that are not  IDMVMContexts ?

 

Thanks

Dobrin

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev