April 2008 - Posts
When you're trying to customize existing CommandBars and Menus in Visual Studio, you can most obviously find a command bar by its Guid or Name.
The problem with going with Name is that it isn't unique and consistent through different versions of Visual Studio.
That being said, You need to go by the Guid identifier.
How do you know each command bar's Guid though?
Well, read the useful references below. (The last one answers that question)
Useful References:
Get project CommandBar in VS 2008
Using IVsProfferCommands to retrieve a Visual Studio CommandBar
Using EnableVSIPLogging to identify menus and commands with VS 2005 + SP1
A pretty common animation when dealing with WPF is the transition of an element from layout to layout.
Take the following scenario:
Let's say I got a window with a form-like view.
The form has a rich textbox where the user can enter lots of content.
In this case, I would like to give the user the possibility to expand that textbox if he needs to edit it in a more convenient way.
So I go and add an expand button, when clicked I add the textbox as a child to a grid that is placed on the entire window's size.
Of course, collapsing it would return it to its former panel.
That will work just fine, but hey!! this is WPF!
We want WoW!
We want animations!
We could of course create the animations we need and manually activate it altogether.
Fortunately, there's the concept of "Layout To Layout" animation.
I found it in the WPF Feature Montage - Do download it to look at the code. (It's located in Layout.xaml)
Once you understand the concept, these layout transitions are dead easy to perform.
If there'll be a request for it, I will create a simple example illustrating the whole idea and implementation.
A great post by Terry Aney.
The post explains the gotchas when using LINQ to SQL to perform batch updates and deletes and offers an elegant and a very impressive solution!
Worth checking it out.
I must begin with the fact that I am totally in love with the extensible model of WCF.
I played around a bit with the 'ICallContextInitializer' interface - very cool.
It allows you to do whatever you desire before and after invocations of service operations.
It would be a good practice to set operation's thread specific settings and releasing it afterwards. (such as CultureInfo and so on)
Unfortunately, I found a scenario where using it would blow everything up.
The ICallContextInitializer won't function If I implement and host a generic contract, such as:
[ServiceContract]
public interface IRequestReplyService
{
[OperationContract(Action = "*", ReplyAction = "*")]
Message ProcessMessage(Message message);
}
If I use an endpoint behavior to add my ICallContextInitializer (as most examples illustrate)
public
void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher)
{
foreach (DispatchOperation operation in endpointDispatcher.DispatchRuntime.Operations)
{
operation.CallContextInitializers.Add(new ContextInitializer());
}
}
This code will not work as expected, it never enters inside the enumeration.
In this case, when using a generic contract, there are no dispatch operations defined.
I tried to tweak it, I implemented an operation behavior and placed it on the actual 'ProcessMessage' operation.
In this case, it did add the context initializer, looks alright? well, no.
When the client called the service the whole thing just blew up, no good.
I suspect ICallContextInitializer is unusable when working with generic contracts - shame, no doubt.
For the time being, I applied the implementation as a message inspector which works just fine though the natural place for my code would actually be in an 'ICallContextInitializer'.