Using Pre/Post Images in Plug-ins
A lot of people have been blogging some pretty basic things about Titan and I had considered not blogging this yet since it's a little more advanced. I changed my mind and decided I would put it out just in case others had started looking for the information. So if you haven't gotten this far into plug-ins yet, don't worry - book mark it you will come looking for it later!
When you start coding to the new plug-in model one of the things you might want to do is access the pre/post images. When the plug-in’s execute method is invoked at the appropriate time in the platform operation pipeline you will be passed a context object that will allow you to get access to information about the current message being processed. It’s pretty common for example on an update to access the InputParameters property of the context object to access the Target image that is placed inside the Input Parameters collection.
Once you get that down, typically you will start looking for Pre/Post operation images. The PreImage is very useful if you’re plug-in is invoked as a post operation plug-in and you want to know what the value of an attribute was before. On the context object is a PreEntityImages and PostEntityImages property that similar to the InputParameters is a collection of properties being passed in.
By default when you register a plug-in the Pre/Post collections do not contain any images. You must indicate at registration time of the plug-in what images you want passed. There are a couple of ways to accomplish that either using the tool with the SDK or via the API directly.
One thing to point out is there are two tools that are currently in the SDK – a Plug-in Registration tool and a Plug-in Developer tool. The plug-in registration tool is intended to be an interactive tool for developers and requires you to manually input the plug-in info each time. This tool originated in CTP2.
New to CTP3 is the Plug-in developer tool. This tool is driven by an xml file that describes the plug-in assembly as a “solution” and that solution has one or more steps that will be registered. This tool is intended to make life easier especially when you’re registering your plug-in over and over.
The following is an example of a step in the registration file that identifies your plug-in and hooks it up to the Update message.
Notice in the XML <Images> tag we specify that we want to be passed a PreImage and what attributes we want to be passed. The developer tool will take care of registering that and when invoked we will be passed the pre-image as part of the PreEntityImages collection.
The other way you can indicate the type of images you want is via the API directly. That’s really what’s happening inside the Plug-in Developer tool, it just does it based on what you put in the XML. For now, we won’t cover that we will leave that for a future post possibly. If you can’t wait – just take a wonder though the Solution.cs file that is used by the Plug-in Developer tool.
David Yack
5 Comments
1 Reference
Email Article to FriendReferences (1)
-
Response: ????? ????If Music Is Your PASSION Home Archives Contact Radio Promo Mixes Links Wallpapers Dr Needles- Ping Pong (VDI001) 12 May 2008 Filed under: Deep , Dub , Electro , Electronic , Minimal , Minimal- Tech , Tech- House , Techno Author:
Reader Comments (5)
Could you possibly post a "step-by-step" how-to create a plugin from scratch?
Hoping to also gather some more ideas of what people would like or think would be useful.
There were some changes in RC0 that might be what your hitting if the ISV.Config is from an older build.