microsoft / ConcordExtensibilitySamples

Visual Studio Debug Engine Extensibility Samples
Other
122 stars 50 forks source link

Method Chaining in Practice? #27

Closed tszirr closed 8 years ago

tszirr commented 8 years ago

Hey,

first of all thank you for these descriptions and examples, in the last few days I was repeatedly amazed by the remarkable extensibility of VS throughout its many iterations. However, skimming through the vsdebugeng.h header, I cannot find any lead on how to attempt the "method chaining" part in the actual interface specifications (referring to https://github.com/Microsoft/ConcordExtensibilitySamples/wiki/Component-discovery-and-configuration#method-chaining).

Could you clarify how exactly one would have to go about in order to partly extend existing debugging functionalty, say for example, an expression compiler/evaluator that translates custom expression syntax to native C++ expressions that can be compiled by the built-in evaluators?

Since an additional input parameter of the next evaluator in the chain seems to be forbidden by the interface specifications, are you supposed to retrieve the other implementations from the context in some way?

Thanks!

plnelson commented 8 years ago

What scenario are you trying to support? I tried to clarify the documentation on the page you linked, but I don't know if that will help you without understanding the scenario better.

gregg-miskelly commented 8 years ago

@tszirr the dispatcher will take care of finding the next implementation automatically. You just call the same API again. Something like:

class MyExpressionEvaluator : public IDkmLanguageExpressionEvaluator
{
    HRESULT STDMETHODCALLTYPE EvaluateExpression(
        _In_ Evaluation::DkmInspectionContext* pInspectionContext,
        _In_ DkmWorkList* pWorkList,
        _In_ Evaluation::DkmLanguageExpression* pExpression,
        _In_ CallStack::DkmStackWalkFrame* pStackFrame,
        _In_ IDkmCompletionRoutine<Evaluation::DkmEvaluateExpressionAsyncResult>* pCompletionRoutine
        )
    {
        CComPtr<DkmLanguageExpression> pNewExpression;
        TranslateExpression(pStackFrame, pExpression, &pNewExpression); // your code translates the expression into C++

        return pInspectionContext->EvaluateExpression(pWorkList, pNewExpression, pStackFrame, pCompletionRoutine);
    }        
    ....
}

You may find that you need to create a new inspection context since the one provided for you will have the language id set to your language. But I think the C++ EE will just carry on in C++ mode anyway.

tszirr commented 8 years ago

Thank you, that is exactly the information I needed!

Could you clarify the section in the sense that the "first parameter" bit in the text usually refers to some kind of context or dispatcher object? I was very misled by matching IDkmExample and DkmExample, which led me to think that chaining only works if I explicitly get a pointer to the next implementation in the chain. (The concrete example given by Gregg is very helpful in that regard.) Thanks!

gregg-miskelly commented 8 years ago

@tszirr I tweaked the wording a bit. Let me know if that sounds more clear.

tszirr commented 8 years ago

Great, now it is more than clear. Thanks a lot!