When creating a custom XML ribbon in an VSTO add-in is there an order with which the various get* callback methods are invoked (e.g. getDescription, getEnabled, getVisible, etc.)?
Surely there's an order.
But that's an internal implementation detail of Office and you absolutely shouldn't rely on that.
The only order you can rely on is the call of onLoad which is guaranteed to come first.
The rest of these methods should not rely on each other. They should be implemented as stateless as possible and should only return the requested value. (Hence their names starting with get....)
That is, you get the id of the control in and have to return some value - maybe with some information from the current Excel.Application.
One additional information:
If you need a refresh of all these get... methods, you can call IRibbonUI.Invalidate().
(You get the instance of IRibbonUI as a parameter of the onLoad call.)
Related
We are using a 3rd party ActiveX control in our application, recently as per our request they have added new function in ActiveX control interface and we are trying to access those function in our application. Due to some reason there are chances where we can not deploy our 3rd party ActiveX control but we are deploying our application. So old 3rd party ActiveX does not have new functions but our application which is consuming those function are trying access new function. Because of that we are getting some inconsistent behaviour lIke crash or message error box.
So we wanted to understand that is there any way to determine function of 3rd party ActiveX control exist or not in our application ? So based on that we wanted to avoid calling those function.
Thanks.
Well, you can get the type library information and try to read and walk it to determine if the function exists.
Or, you can call the function through IDispatch::Invoke and see if it fails. If it fails, don't call it again and call the fallback function.
So, it doesn't have a separate Guid for the two different interfaces? Technically, it is supposed to...but sometimes vendors don't provide new Guids for updated interfaces....I plead the 5th.
The way it is supposed to work is the you QueryInterface for the interface you want and use it.
Is there a way to monitor and record COM calls, with parameters, made into a specific EXE/DLL module, without explicitly adding logging functionality to the module itself? I'm thinking along the lines of how you can track windows messages in Spy++, but for COM.
The motivation is to record calls for diagnostic and automated testing purposes - e.g. click a button on a window on a client PC, monitor the COM calls sent to a server module, and later 'replay' those calls without needing the client PC.
If tools exist which do this, that is great. If not, is it something one could write and if so how?
Caller of COM method simply calls a function with agreed convention. parameters etc. and there is no middle layer between the caller and the callee, except when proxy/stub pairs are marshaling the call. Even in the latter case, there is ho standard way to hook the call for logging purposes, which you can do without specific preparations of sorts. All in all, you need to take care of tracking calls and diagnostic yourself. In can direct logging in prolog of every method of interest, or you can wrap your object/interface into customized middle layer which tracks a call and passes it further to intended callee (such as described here, for example).
I am trying to run some code on objects that are loaded from RavenDB, and I need to do it just after the object has been loaded with its property values.
I've tried intercepting the deserialization process using a CustomCreationConverter and overriding ReadJson, but the object I can access at that point has all the properties set, except the one I need : the Id. Is there somewhere else I can slot into the pipeline in order to do this?
The reason you don't see the Id is because it's not part of the document, it's in the metadata as #id.
If you want to intercept client side, you can register a custom Conversion Listener. Create a class that implements IDocumentConversionListener and register it with documentStore.RegisterListener(). In the DocumentToEntity method, you can run your custom logic. The documentation is lacking on Listeners in general, but there is another topic that also uses them:
http://ravendb.net/kb/16/using-optimistic-concurrency-in-real-world-scenarios
The other option would be to add a bundle that intercepts on the server side. For that, you would use a Read Trigger.
I am developing a rather large application and would like to implement IErrorHandler multiple ways for different conditions. However, it appears that ALL of the instances will be called for every error. Is there a way I can tell WCF that the error has been handled by a particular instance so that any handlers remaining in the list are not called?
(For a little more detail, we are using a 3rd party toolkit that adds a "default" error handler. This means that no matter what we do, this handler will be invoked and reverses some of our changes.)
You could just use a provider pattern and inside it have a list of your error handlers. You could then have whatever condition you like to delegate to the handler of your choice.
Ie you would hook up 1 error handler that contains all your handlers instead of hooking up many which all get executed sequentially.
I am interested in the best practice of the following scenario. I have a CustomAction method that hits a web service and returns some information that I use to populate a combo box. Later in the install process in another CustomAction method, I need to access some of the meta data returned from that first web service call.
In the first method, I create a List that is a public static member of my CustomAction class. In my second method when I access the list its empty.
My thoughts were to serialize it using xaml serialization into a session variable then deserialize it in my second method.
Am I way off here? Is there a better way?
I will assume that your second custom action is making configuration changes to the machine and running in the execute sequence as deferred with no impersonation. This means it can only access the CustomActionData property.
This means your first custom action will have to serialize the CustomActionData property for the second one to deserialize. Now the CustomActionData is a Key:Value collection and what you do with it ( including have a Key with a Value that is yet another serialized datatype ) is completely up to you.
Be sure to read the DTF documentation to understand how to use the CustomActionData type and members off the Session class to your advantage.