Tagged: wpf Toggle Comment Threads | Keyboard Shortcuts

  • danielsaidi 10:49 pm on June 27, 2011 Permalink | Reply
    Tags: , theming, , windows 7, wpf   

    Visual Studio and WPF force Windows 7 to apply basic theme 

    Every time I open up my WPF projects in Visual Studio (2010) and open a XAML file, my computer switches from the nice semi-transparent theme to Windows 7 Basic.

    Does this happen to you too? If so, this is how to solve it:

    1. In the main menu, select “Tools/Options”
    2. Under “Environment/General”, uncheck “Automatically adjust…” and “Use hardware acceleration…”
    3. Enjoy the Windows 7 flashy theme 🙂
    Easy enough, right? Rumors says that R# is causing this issue, but I love JetBrains and their God-like skills way too much to even consider that to be true.
     
  • danielsaidi 3:30 pm on May 12, 2011 Permalink | Reply
    Tags: i18n, l12n, localization, wpf   

    How to localize an WPF application with a resource files 

    I currently need to localize a WPF application that consists of a main application project as well as separate DLL projects that provides the app with general user controls, model classes etc.

    Many of the tutorials I found suggested using the App.xaml file to localize the application. This does not work for me, since I need to be able to localize all parts of the application, as well as the separate DLLs.

    Fortunately, it is really easy to get resource file-based localization up and running for your WPF app. Just follow the steps below…and keep in mind that the names that I use are only boring suggestions. You can go as wild as you want to when you try it out for yourself.

    Step 1. Create a WPF application

    First, create a new WPF application. I call mine…HelloWorld!

    WPF app

    An insanely complex application called “HelloWorld”

    As you can see, I also added something to localize. I chose a Button; what do you choose? Tell me in the comments below 🙂

    Step 2. Create the resource file

    Now, let’s add a resource file into which we will add our textual content.

    To separate resource files from the rest of the application, I place the file in a Resources folder and name it AppLanguage.resx.

    Resource file

    A resource file with (so far) one single parameter

    Now, go ahead and add some content to the resource file. As you can see, I added a parameter called ButtonText, which I will apply to the Button.

    In order to access the resource file from XAML, we also need to make the file public:

    Make the resource file public

    Make the resource file public

    Once this is done, let’s access the resource file from XAML.

    Step 3. Access the resource file content from XAML

    Now, let’s use the resource file parameter in our XAML file.

    Connect the XAML code to your context class by adding the following line into the Window tag:

    xmlns:Resources="clr-namespace:HelloWorld.Resources"

    After that, you can access the resource parameter as such:

    <Button Content="{x:Static Resources:AppLanguage.Menu_LoadData_All}"></Button>

    Voilá! The text is finally displayed within the button:

    The resource text is displayed within the button.

    Since we use a resource file instead of App.xaml, we can use the same resource file to translate textual content code-behind as well. Let’s try it out.

    Step 4. Access the resource content file from code

    To access resource file content from code, simply call the AppLanguage class as such:

    using HelloWorld.Resources; //Add this topmost among the using directives
    MessageBox.Show(AppLanguage.ButtonText);   //Add this code inside the MainWindow() ctor

    When we now start our application, the message box is displayed….juuust the way we want it:

    Resource file content

     
    • Ashish Jain 9:33 am on July 10, 2013 Permalink | Reply

      Really very Helpful., Thank you for the post.

    • akatran 6:37 am on December 4, 2013 Permalink | Reply

      What about design time localization. How can someone change the language while designing the XAML of windows/page or whatever?

  • danielsaidi 9:32 am on March 24, 2011 Permalink | Reply
    Tags: border, checkbox, wpf   

    WTF WPF!? 

    My personal WPF WTF list has grown steadily since I started to work with WPF. In my opinion, WPF is filled with bad naming conventions, inconsistencies and just…bad smell.

    As my work with WPF progress, I will write some blog posts where I will vent the steam that builds up when I am faced with such WPF goodies.

    Before I go on, I want to underline that I find the WPF technology in itself impressive. However, it seems that MS squeezed too much into the WPF universe at once. If they aimed at replacing Windows Forms, they should have put more effort into making the new standard consistent…and also applied to conventions that already exist out there.

    Border

    For instance, let’s take the Border control, which can have…a background. To me, that’s not just bad design. To me, that serves as a prime example of the rotten smell that leaks out of WPF. It breaks SO many conventions.

    First of all, let’s talk about the border concept. What do we mean?

    Well, if I would say “let’s put a border around that thing over there”, “the thing over there” would be something that is responsible for its entire context. The border would just something that will get smacked around it. It may be thin, thick, green, aquatic, slimey…I do not care. It will surround “the thing over there”. That’s it.

    Second of all, if you have worked with web development, you may know the border concept as something that can be applied to divs, spans, images etc…that is, most kinds of graphical components. In these cases, “the thing over there” is a graphical component, and my definition above still applies. This border concept is also applied to great extent in the Windows Forms framework.

    So, why change the border concept in WPF? Why not call it something else?

    In  my opinion, all the examples below would be better than Border:

    • Panel (did they not want to re-use this name?)
    • Container
    • Box
    • Div (yeah, even Div would be better than Border)
    • SurrounderThingie
    • Kwanzabalubah

    By naming this UI component Border, MS changes the meaning of an already established concept. DO NOT CHANGE THE MEANING OF AN ALREADY ESTABLISHED CONCEPT!

    CheckBox

    Now, as I wrote earlier, the Border example is just ONE example of the rotten smell that leaks from the WPF framework…but a damn good one. Let’s move on to the CheckBox control.

    If a Border is something that surrounds something else, a check box is something that we have come to known as a UI control that can be either checked or unchecked. It maps beautifully to a boolean value.

    Well, except in WPF. In WPF, the IsChecked property is nullable (bool?), since it can also have an undetermined state. Wow, that changes everything.

    To me, if a checkbox is not checked, it is not checked, unchecked, whatever. Simple as that. If MS wanted to change this, perhaps they should have introduced a new UI control (it could even inherit a regular CheckBox). It could have been called:

    • NullableCheckBox
    • FuzzyCheckBox
    • CheckBoxGoodForSwedishDecisionMakersWhoDoNotWantToMakeADecision
    • NotReallyACheckBox

    By mapping this new kind of behavior to the check box concept, MS changes the meaning of an already established concept. DO NOT CHANGE THE MEANING OF AN ALREADY ESTABLISHED CONCEPT!

    WPF CheckBox enemy bonus content

    After publishing this post, I decided that you deserve something in return, if you decide to join me in my war against WPF. How about a nice extension method to the CheckBox class?

       public static bool IsChecked(this CheckBox checkBox)
       {
          return checkBox.IsChecked.HasValue && checkBox.IsChecked.Value;
       }

    Enjoy 🙂

    Conclusion

    Wow, that felt good.

    Please, provide me with more examples. Maybe, in a not so distant future, we can have a clean WPF framework that conform to the rest of the world. Wouldn’t that be something?

     
    • Henrik 10:51 am on March 24, 2011 Permalink | Reply

      Daniel, I think you are brainwashed with html and css – which are BAD design languages. WinForm also is BAD as a design tool. WPF is more, MUCH MORE, than forms and even GUI! You can create ANYTHING with WPF! It’s not even bound to be used as a GUI! The things you can do with html/css/javascript is just a drop in the ocean compared with what you can do with WPF. Don’t forget that! WPF is not restricted to forms etc. With WPF you can let a button be rotating 3D-cube with a Grid inside that displays a film on every row (bad example :-).
      With WPF you can do anything – ANYTHING(!) – you want! And that’s both good and bad: “with great power comes great responsibility” (to quote a famous film).

      So…

      How would you create a border in a real design tool like InDesign (or perhaps imaging tools like gimp/photoshop)? You wouldn’t set a border property on an object – you would actually draw a border and put things in it. Right? That’s how WPF works (beacuse WPF is also a good “design tool” and you need to rethink – and remember that html+css is bad for designing). The Border control is itself a container object. And remember what I said with WPF you can put anything inside a border – anything you dream of! That’s why it’s not just suffice to have a border property on the “thing over there”.
      Because then ALL controls in WPF would have a border property. And THAT would be even more confusing: a border property on a Line..? With WPF anything can be done, so if you want to put a Line inside a Border – that’s ok! And it actually makes sence: “A line inside a border” (nothing wrong)! But a Border property on Line? What’s that!?

      There is actually a Rectangle object also. Can you tell why it is a separate object (when the same thing can be accomplished with a Border)?

      CheckBox inherits from ToggleButton which has an IsThreeState property. Just set that property to false and you get the “old” behaviour of a checkbox back. It’s just an inheritance issue. I can agree that it may be a bug that the CheckBox instance should set IsThreeState to false by default. But maybe not..?
      When doing design stuff it’s good to know if a user has “touched” the checkbox or not. Maybe you want to make a binding that makes another element green when the user makes a decision. Or maybe better example; you want to force the user to make a selection and change some other content depending on the choice. You don’t want to assume the user has made a choice (and display content dependinig on it) when he/she actually hasn’t. But I may be wrong?

      They have to change the meaning of the established concepts because the concepts in WPF are changed!
      I think that is what you have a problem with. THE CONCEPTS ARE CHANGED! Like it or not…

      • danielsaidi 11:18 am on March 24, 2011 Permalink | Reply

        Thank you, Henrik. Great to have the discussion started. People – join in!

        I agree that Windows Forms is a BAD design tool…and I agree that WPF is MUCH MORE…and I disagree – I do not think that HTML/CSS are BAD design “tools” (well, CSS may be a bit bulky), although they are a bit restricted.

        …and, as I wrote, I find the WPF technology in itself impressive…its flexibility included.

        In my world, a button may spin, jump, bounce, dress up as Superman. I do not care…as long as I can click it and trigger something. The question is – is dressing a button up as a 3D cube with a Grid inside a good thing? Well, that’s a different topic… 🙂

        In my opinion, what YOU do with a framework is different from what the framework itself is. If a framework offers you the possibility to create a Chicken and call it a Turkey, fine by me…as long as I do not have to dive into your code later on. The framework itself, however, should be consistent.

        Regarding the good ol’ Border, I think, what you’re describing sounds much more like a container, box or whatever, than a border…semantically. Do you like that name…Border? I do not. Or…maybe they mean Border like a country border. In that case, the background would represent the topology of the country…and in that case, the background could be 3 dimensional. Great!

        Regarding the CheckBox…maybe it could have a IsChanged property instead, which would indicate that is has been affected by a user? In my opinion, using the IsChecked property to signal that kind of information is wrong.

        I agree that WPF is much more than web design and I like the idea, yet I am still disgusted by the smell. I stand my ground regarding the naming of Border and the check handling of the CheckBox. You will have to bring a lot more gun powder to knock me to my knees 🙂

        (btw, I LOVE the agressive war semantics in this blog discussion)

        • Henrik 1:58 pm on March 24, 2011 Permalink

          Border… Yes, it’s a container (that has a border)… but, I can agree, the name could be better. Because, semantically; can a Border be a container? I don’t think so… Maybe you are right? But I can’t come up with a better name (since you actually want to put something (anything) in a container that has a border). What about BorderContainer, would that be better? Talk to the MS WPF team 😉

          CheckBox. Again it’s just a “bad” inheritance symptom. Set ThreeState to false and there you go, your problem is gone 🙂
          But the threestate has a meaning… Another example: what if you want to have a CheckBox (or better a ToggleButton) that sets a selected text to bold. But the selected text is both bold and regular – the indeterminated state is useful! But I agree, perhaps it shouldn’t be set by default – the “normal” behaviour is what you explain. The WPF team might have an explanation..?

        • danielsaidi 9:38 pm on March 24, 2011 Permalink

          Aaaaah, so I have started to convince you about the naming conventions. Winning! 😀
          So, first of all, we can agree that the Border name sucks. Great. Winning!
          Second, moving on to the CheckBox, I would like to take the “just another bad inheritance symptom” and reply with a “that’s exactly my point with that whole CB section”. Bad inheritance. Winning!
          Still, I’m intrigued by the ThreeState property and will check it out. Let’s call that one a draw.
          FInally, I did not understand “the selected text is both bold and regular”. How could that be!? The war goes on.
          Great discussion. I am happy! 🙂

        • Henrik 9:53 pm on March 24, 2011 Permalink

          Winning? I think I have started to move your mind a bit to 🙂

          “selected text is both bold and regular”: if you enter som text e.g. “Lorem ipsum dolor sit ame”. Then make “ipsum” and “sit” bold (by selecting those words and then click on the “B” CheckBox/ToggleButton). The CheckBox/ToggleButton will be checked when selecting those words again (because they are bold) and unchecked when selecting another word (which is regular text). But what happens when you select the entire phrase (with both bold words and regular words)? You get it! It has an indeterminated state – ThreeState!

        • danielsaidi 10:10 pm on March 24, 2011 Permalink

          Ha ha ha, damn…three states? I think you’re entitled to a small winning as well (a really good example), but hear me out first 🙂

          I do not deny the existance of the ThreeState checkbox type…not at all, but the IsChecked name is still dead wrong. If we consider your excellent example, maybe IsChecked should either be completed with or entirely replaced by the Value/State property that I suggested to Fredrik?

        • Henrik 10:18 pm on March 24, 2011 Permalink

          Daniel your getting softer… 🙂 Reading your answer to Fredrik below: “I think that it IS OK to have an uninitialized state where the SelectedValue/SelectedItem properties are null” – Aha! See! It has a meaning! Remember that RadioButton is inherited from ToggleButton too (as well as CheckBox).

          But I have to admit something too 🙂 I think I misinterpreted you. I thought you disliked the whole concept of the ThreeState CheckBox. Because we can agree of something; nullable booleans is BAD! Hate it! Doesn’t really understand why it exists. The Value/State property (enum) is better! And with that the IsXxx semantic is ruined, as you said.
          But at the same time – it’s easy to grasp! If you set ThreeState to false the IsChecked property can’t have a null value and everything is very understandable and usable.

    • Henrik 11:11 am on March 24, 2011 Permalink | Reply

      Forgot my conclusion: Don’t compare WPF with web development!
      Because then you must also compare WPF with InDesign, Flash, PDF, WinForms, HTML etc etc…
      With that said you may be right about one thing – they put to much in it..?

    • Fredrik 2:09 pm on March 24, 2011 Permalink | Reply

      Daniel, I totally agree with your border concept, they should have picked a better name for it. I’d stick to Rectangle.

      Henrik really has a point here. I don’t think WPF should be compared with anything else than traditional Windows developing. The three-state checkboxes has been around since Windows 95 at least. It might not be very logical to let a checkbox have three states but it’s very Windows/Microsoft-ish. Just accept it 🙂

      What’s really ugly, and also very common on the web, is the uninitialized radio buttons (option button). Even if this is a Windows heritage as well, I believe it’s a bigger conceptual failure than the checkboxes, simply because it’s impossible to return to the initial state once the user have clicked an item. Daniel let me hear your thoughts, should it be possible to display an unselected radio button in WPF? Is it?

      • danielsaidi 10:05 pm on March 24, 2011 Permalink | Reply

        Welcome to the war, Fredrik 🙂

        Hmmm…an unselected radio button group? I can see the point that a user should be FORCED to make a decision, both with checkboxes and radio groups, but that does not mean that we have to pollute the conceptual meanings of our property names. If you have a property that is named IsX, the name indicates that the value can be either yes or no. Not maybe! Introducing a maybe value alternative destroys the entire concept of the Is-part of the property name and introduces a fuzzy state that really pisses me off.

        Now, the CheckBox case is an open goal. The property is named IsChecked. Now, is it checked or not? Well, in Microsoft’s opinion, yes, no and maybe/undetermined are all good legitime possible values. I stroooongly tend to disagree. If a checkbox can have these three states, how about to letting the IsChecked property JUST answer the question if it the checkbox checked or not, and instead add another property that is called IsChanged (or something like that), that indicates if the user has modified the initial state of the checkbox. Or how about this – if it can have three states, why not let it have a Value/State property instead, that can be CheckBoxState.Checked, CheckBoxState.Unchecked or CheckBoxState.Undetermined? Note that these are just alternatives that I came up with in one minute or so…I believe MS has put a lot more effort into their design decisions, and that’s quite sad. 😉

        Now the RadioButton case is a bit trickier, but not that tricky. Here, you have a group of radio buttons, where the selected radio button (if any) will determine the value of the entire radio button group. Note the “if any” part of the last sentence. Now, if you want to force the user to select a radio button in the group and therefore have no selected item initially, I think that it IS OK to have an uninitialized state where the SelectedValue/SelectedItem properties are null, since there IS no selected item and thus no selected value. If you would make it possible to unselect any selected radio button, one alternative could be to simply add another radio button or a button (e.g. “I changed my mind…I am not sure at all after all”) that resets any selected item in the group.

        Now, I have to go. Henrik has posted another reply that I am eager to read 🙂

      • Henrik 10:07 pm on March 24, 2011 Permalink | Reply

        Fredrik, Rectangle already exists in WPF! The only(?) difference between the Border control and the Rectangle control is that the Border control can have content. I.e. it’s a container, where as the Rectangle is not a container (just a “shape”).

        In WPF RadioButton is inherited from ToggleButton (same as CheckBox), so yes, it has the ThreeState “mode” too. In WPF you can, programmatcally, set the initial state back to indeterminated.

  • danielsaidi 11:54 am on March 17, 2011 Permalink | Reply
    Tags: , infragistics, ioc, , , wpf   

    Infragistics – not that TDD friendly 

    I am currently working with cleaning up a WPF application that is tightly connected to Infragistics UI components. I am SOLIDifying, Dependency Injecting, IoC:ing and all those high fashion stuff. Does that turn me into a state-of-the-art developer? Time will tell 🙂

    However, since no unit tests existed when I took over responsibility for the solution, I decided to take the opportunity to wrap all code that I am rewriting in unit tests. Sadly, Infragistics does not seem to want you to test functionality that is based on their classes, since almost every class that I’ve come across so far has been internal. No public constructors, no interfaces…nothing.

    To work around the problem, I am currently wrapping everything within facade classes as well. It feels cheap and gives me a looot of additional work, but when I am done, I will at least have a shot at becoming the Joel Abrahamsson of the Infragistics universe. Not bloody likely, I know, but at least, I will probably put the resulting facade classes up for download.

     
    • Ivar 7:55 am on March 25, 2011 Permalink | Reply

      en annan lösning är ifall du kan gå in och pilla på assemblyt och lägga in [InternaldVisibleTo] och peka ut ditt testbinliotek.

      Ps. Trevligt i Barcelona!

      • danielsaidi 10:27 pm on March 25, 2011 Permalink | Reply

        Aaah, okej 🙂 Jag tror inte att jag kommer att göra det, eftersom projektet är rätt kort, men tack för tipset!

  • danielsaidi 11:47 am on March 14, 2011 Permalink | Reply
    Tags: close button, wpf   

    Hide the close button of a WPF window 

    In a WPF application that I am currently working with, I have to be able to hide the close button of a progress window. Instead of being closed by the user (like an alert window or message box), this progress window should instead be closed by its owner window once its related operation has finished.

    So, how do you hide the close button. There is no such property (at least, I do not find one), so it seems to me that you have to roll up your sleeves and do some DLL import goodness 🙂

    First of all, define two constanst and two methods:

    private const int GWL_STYLE = -16;
       private const int WS_SYSMENU = 0x80000;
    
       [DllImport("user32.dll", SetLastError = true)]
       private static extern int GetWindowLong(IntPtr hWnd, int nIndex);
    
       [DllImport("user32.dll")]
       private static extern int SetWindowLong(IntPtr hWnd, int nIndex, int dwNewLong);
    

    Then, in the window class, call the imported DLL methods as such:

    var hwnd = new WindowInteropHelper(this).Handle;
       SetWindowLong(hwnd, GWL_STYLE, GetWindowLong(hwnd, GWL_STYLE) &amp; ~WS_SYSMENU);
    

    Naturally, the most convenient way to achieve this is to wrap the functionality within an extension method:

    public static class WindowExtensions
       {
          private const int GWL_STYLE = -16;
          private const int WS_SYSMENU = 0x80000;
    
          [DllImport("user32.dll", SetLastError = true)]
          private static extern int GetWindowLong(IntPtr hWnd, int nIndex);
    
          [DllImport("user32.dll")]
          private static extern int SetWindowLong(IntPtr hWnd, int nIndex, int dwNewLong);
    
          public static void HideCloseButton(this Window window)
          {
             var hwnd = new WindowInteropHelper(window).Handle;
             SetWindowLong(hwnd, GWL_STYLE, GetWindowLong(hwnd, GWL_STYLE) &amp; ~WS_SYSMENU);
          }
       }
    

    If you know a more convenient way to hide the close button (maybe I just did not find a native property/method that actually exists?), please indulge me.

     

     
    • agenX 9:21 pm on June 11, 2011 Permalink | Reply

      [DllImport(“user32.dll”, SetLastError = true)]
      what could be the reason that my visual studio 2010 could not be found this “DLLimport” what should i do? thanks…

      • danielsaidi 5:33 pm on June 12, 2011 Permalink | Reply

        Hmmm….I’m not sure. It is probably available for download somewhere, but I do not know why some have it and why you do not. Anyone?

    • Trapper Ano 12:20 pm on July 20, 2012 Permalink | Reply

      @agenX – I do realize that I am replying very late, but just in case…

      Make sure you include a using statement for the InteropServices at the top of the class to be able to use DLLImport. The following line should do the trick:

      using System.Runtime.InteropServices;

      … Furthermore, in my case I also had to use the following:

      using System.Windows;
      using System.Windows.Interop;

c
Compose new post
j
Next post/Next comment
k
Previous post/Previous comment
r
Reply
e
Edit
o
Show/Hide comments
t
Go to top
l
Go to login
h
Show/Hide help
shift + esc
Cancel