Monthly Archives: April 2015

ASUS Product Support is Crap (continued)

Last Friday, I took a day to do run some errands and to tie up some lose ends including the old ASUS laptop that was returned to be the 3rd time, still broken.  As you may recall, from the previous post (, I was sending the laptop back to them the 3rd time after having it returned to me in the original broken condition 2 times.  Well, 3 times was *not* the charm for me.

Since I bought the laptop at Costco, I thought of using their Costco Concierge service to attempt to return the defective laptop back to them, but the best they could do for me was to contact ASUS to resolve it.  So back on the phone with ASUS, their customer service manager could, again, only offer me to have it sent in to them, but this time, he would request a replacement.  Progress?  Maybe.  He stressed to me that there is no guarantee that the laptop would be replaced, but at least he would initiate the process.  He also offered me an overnight shipping to them this time around.  Probably another benefit of having Costco on the phone with me.

In addition, I tweeted about my experience and to @ASUSUSA , who replied, offering to help:


So I mustered confidence to finally send it in the 4th time.  Needless to say, I was very skeptical and unfortunately, a little pessimist in me turned out to be correct.

They received the laptop on Monday, the 20th of April 2015.  On Tuesday, the 21st, I decided to check the status.  This is what it looked like:


On one hand, the word swap was now appearing in the status, a positive indicator that they are, indeed, looking to replace the laptop with another one. But, it also said something about waiting on the customer confirmation…  Hmm… Confimation of what?    I had to call to find out.

The tech on the other end politely put me on hold and spent a good 5 mins figuring out what that meant.  He came back and told me that I should have gotten an email asking me to confirm the specs of the proposed replacement.  Needless to say, I had not gotten such email.  I mentioned it to him, but he promised that it would come in 24 hours.

On Wednesday afternoon, a day after speaking with the tech, and after checking my spam folders and finding no email from ASUS, I decided to call them again.   They could not help me, because their manager could not access the system for some reason and they did not want to do a 3-way call with me.  They insisted in calling me back within 24 hours.  I even tried to go the Costco Concierge route, but those guys are beginning to sense a losing battle as well and starting to disengage from this toxic case.  They too said to wait a day.

Well, there’s always tomorrow, right?  As of right now, I don’t even have the broken laptop until I confirm an email that I never received.  Back to twitter I go.

Solving the WPF Resource Key Collision

In my previous post about WPF Resource Keys, I talked about how WPF handles resource resolution when multiple resources with same key end up in loaded into same ResourceDictionary via merging.  In this post, I will present a solution.

So, apparently, Microsoft thought about it and provided a solution in a form of a class class called System.Windows.ComponentResourceKey.  This class is derives from a base class called System.Windows.ResourceKey, which is used inside the WPF resource resolution code.

So what does it do and how does work?

Normally, the WPF resource resolution logic assumes that all keys are objects used to identify resources in a ResourceDictionary.  Unlike a regular dictionary, a ResourceDictionary, technically, supports having multiple resources added with same key, but during the lookup operation, only the last resource added for a specific key will be returned.  So during the ‘merge’ operation, the new resources will overlay the existing ones if the keys clash, and during the ‘unmerge’ operation (ResourceDIctionary.MergedDictionaries.Remove()) the previously covered resource will emerge as ‘active’, so all the resources referenced via DynamicResouce will update.

The above gets more interesting if the key is of type System.Windows.ResourceKey.  If so, the resource resolution logic will only look at the resources which live in a dictionaries defined in the assembly referenced by the ResouceKey.  Moreover, when such set of dictionaries is found, the instance of the key is compared against other instances of the key to see if there’s a match, and because the System.Windows.ComponentResourceKey class overrides Equals and GetHashCode, the rules of equality take into consideration a bunch of parts, not just string value.

Here’s the code of the Equals and GetHashCode methods:

public override bool Equals(object o)
    var componentResourceKey = o as ComponentResourceKey;
    if (componentResourceKey == null)
        return false;
    // Ether neither objects define the TypeInTargetAssembly, 
    // or if both are defined, then make sure they are same
    if (!((componentResourceKey._typeInTargetAssembly != null) ? 
              componentResourceKey._typeInTargetAssembly.Equals(this._typeInTargetAssembly) :
             (this._typeInTargetAssembly == null)))
        return false;
    //If resourceId is null make sure they are both null
    if (componentResourceKey._resourceId == null)
        return this._resourceId == null;
    //otherwise do a simple equals
    return componentResourceKey._resourceId.Equals(this._resourceId);

public override int GetHashCode()
   //use both, the type and the resouceid to generate a complex hashcode
   return ((this._typeInTargetAssembly != null) ? this._typeInTargetAssembly.GetHashCode() : 0) 
               ^ ((this._resourceId != null) ? this._resourceId.GetHashCode() : 0);

So when creating a reusable WPF component make sure you use the ComponentResourceKey class for your resource keys, do not just use strings and, obviously, refer to such resources using the ComponentResourceKey as well.  You can designate a single marker type (an empty public class) that lives in your assembly as a TypeInTargetAssembly to make it easier to reference your assembly when both, defining and referencing a resource.  This StackOverflow question showcases the use:

public class Resources
    public static ComponentResourceKey BaseControlStyleKey
            return new ComponentResourceKey(typeof(Resources), "BaseControlStyle");

myTextBox.Style = 
        as Style;

<!--Exposing -->
<Style x:Key="{ComponentResourceKey TypeInTargetAssembly={x:Type local:Resources}, ResourceId=BaseControlStyle}" TargetType="{x:Type FrameworkElement}">
    <Setter Property="Margin" Value="4,4,0,0" />

<!-- Using -->
<TextBlock Style="{DynamicResource {ComponentResourceKey TypeInTargetAssembly={x:Type local:Resources}, ResourceId=BaseControlStyle}}"/>

<!-- Using in xaml by relying on the static property defined above -->
<TextBlock Style="{DynamicResource {x:Static local:Resources.BaseControlStyleKey}}"/>