For reference, I am using Blend 4...
I have been experiencing a lot of headaches with the auto-generation of the xmlns:d="http://schemas.microsoft.com/expression/blend/2008" namespace, and the associated "d:LayoutOverrides", etc. I do not want this code, and have to remove it all the time because the other developers I work with do not want it in the code. Is there a way to disable Blend from generating this code? I understand that it is there to help the design process but it is not necessary for me and the benefits are not outweighing the code cleanup costs. Thanks in advance!
If it really is causing problems (my thoughts are that these 'other' developers are not being particularly pragmatic), then just start using VisualStudio to write your XAML.
If the you're using Blend because you're going to be more productive due to having a highly styled UI to build, then these other developers need to see that the benefits by far out weigh the negatives of having the odd little bits of markup that get added (which in turn will make your life easier).
Related
I'm developping a winform application using Visual Studio 2008, and everytime I change something in the Form using the integrated designer, the files Form1.Designer.cs and Form1.resx are changing the content order.
As a result it makes complicated the version control of these file because the diff tool see a lot of differences along the commit althought there is sometimes just minor edit...
Do someone has ever solved this problem?
Unfortunately, no. The Winforms designer is notorious for introducing large textual changes that result in little (to no) semantic change; in other words, it will quite often rearrange or regenerate the code in the designer in such a way where the text is quite different from the original, even though it does largely the same thing. This behavior is sometimes amplified by third-party tools (I've noticed that Infragistics' WinForms tools are utterly INSANE in this manner).
There's really not a good way to handle it in source control, I'm afraid, other than making sure to check in often. This is one of the things that's so nice about WPF, since it's all XAML and it's much easier to keep track of what changes.
I'm trying to use FluidMoveBehaviour from the Dynamic Layout and Styles presentation at MIX 2010 in combination with MVVM (Caliburn.Micro).
The Master/Detail behavior is what I'm after. It isn't working and I would like to find out what's happening behind the curtains to see why Silverlight is not picking it up.
How can I debug the FluidMoveBehaviour?
Because the FluidMoveBehavior is so encapsulated and because the source code is not available, the only recourse when it is not working as expected is trial and error. Even worse, the feature is conceptually very opaque and the implications of what will happen if you change the settings are not at all clear initially.
Your best hope of getting the master/detail scenario to work (the most complicated one) is to create a very small example, get it working, and gradually reintroduce your code until it is fully integrated.
There are other working examples besides the MIX10 demo. I recommend reading and re-reading Mike Taulty's explanation until the feature is less opaque:
Blend Bits 14: Fluid Movement
Notice how he approaches the problem gradually and with little test programs. That is how to avoid wasting time trying to use a "black box" feature.
Anyway, the promise of "effortless interactivity" might ring rather hollow right about now. It is perhaps a lesson for other behavior developers: how will the clients debug it when it isn't working? The answer: give them the tools, like configurable logging. When it's not working, the silence is unbearable.
I'm planning to write my first program (it'll be in C#), and I need help with a decision. I know I'll want to use custom controls in the final version of the program (probably these), but someone advised me to use standard WinForm controls until the program is running right. They said once things are running right, then I could replace the UI with the custom controls I want. Is this the best way for me to do it? Or should I use the custom UI controls from the beginning?
About me:
-Never written a program
-Have some light Access/VBA experience and classroom C++ Logic and non-UI programming
-If it matters, I don't know exactly how to do it yet but I do plan to try to keep the logic and the UI as separate as I possibly can. I know that needs to be a priority.
Thanks.
It depends on some factors:
The complexity: a simple custom-draw control can easily replace the standard winform control but generally custom controls add new features and tend to have differents methods and properties. In this case, switching to the custom control is not a simple task.
Your experience: Since you are pretty new to this, using a custom control can add another level of difficulty. Generally, these controls offers more options than the winform controls. So, it would be wise to start with the simple winform controls.
Since this is your first project, I tend to agree with your friend. While there is nothing inherently wrong with starting with third party controls, you will find that there is much more documentation and help available for the built in controls. In your early development efforts, you will likely hit many stumbling blocks, regardless of the choices that you make. Therefore, starting out with the most well-travelled course may make things easier for you starting out.
Once you have a little more experience debugging some of the issues that you will inevitably experience while learning a GUI framework, then it would make more sense to start bringing in glitzy third party controls.
Just use the standard controls. Keep it simple, Keep it simple, keep it simple. Also know that if you are still programming next year (hopefully on other projects), you will look back at this code in shame -- but that is a good thing.
Never written a program? I would not advise using any third party libs at this point, you are still learning. If you want the benefit of custom controls, why not write them yourself? You get the custom behavior and you actually learn how this stuff works.
Also, this statement is a bit of a red flag:
-If it matters, I don't know exactly how to do it yet but I do plan to try to keep the logic and the UI as separate as I possibly can. I know that needs to be a priority.
Design patterns are great, but until you get some experience it is hard to understand why they are so great. Start like everyone else writing 'bad' code and then come back to the design patterns. That way you will truly realize why they are so important (rather than just being told that they are). Don't try to grok the advanced stuff before being full competent with the fundamentals.
I love WPF, but I hate XAML.
XAML is too verbose, has syntax issues when Microsoft tried to extend it (see StringFormat on Bindings), and is difficult to navigate.
Are there any alternatives to XAML?
(These are just my opinions. Feel free to disagree.)
There are alternatives:
XUL, Flash, Delphi resource syntax, C# Form.Designer.cs syntax, VB6 form syntax
Surely there are no compelling alternatives though.
It's like human bodies -- utter rubbish with all its juices and smells but that's by far the best life form known. XAML is clearly really really bad, but there's nothing half as good around.
XAML does seem to be the elephant in the room. While I'm a huge fan of WPF the verbosity of XAML can be a little hard on the eyes. Whilst Blend and VS2010 go long way to reducing the need for coding XAML from scratch, I still find hand editing a necessity in nearly everything I do.
I find power boots easy on the eyes and the CSS like syntax of JavaFX to be quite appealing. These seem to be the insparation for D'oh.
However verbose XAML is, at least there is tooling support to get us 90% of the way, any other alternative would take us back to hand coding all the UI. Not an attractive proposition for this coder.
One alternative is to not do the UI at all and have a designer do it in Blend instead.
This might be something to watch. There is nothing to download from the website yet though.
D'oh: The Super Productive Windows GUI Language
http://doh.xn--majkrsft-e0ab.se/
now I know why your name badge looked familiar at the last Innovation Day.
It would be a lot of work but you could make a small start - there's no reason why you have to use XAML, just need something creating the partial classes.
So, you could code up a DSL replacing XAML with something that was legal C# or go the whole hog and write a VS tool which generated C# the same way the XAML processor does. It depends on how much you want available to the code-behind file at compile-time.
Hmmm, with IronRuby, maybe a DSL in IronRuby
(DSL = Domain Specific Language for anyone reading who is acronymically challenged.)
We are evaluating the use of WPF for an upcoming project. We plan to "commercialize" some of our internal tools and could really use some of the effects WPF offers. We also like the idea of the design layer and code layers being independent to allow concurrent work.
Where can I find a simple UI built with WPF (XAML) that I can pull apart?
What is the workflow if the designer is creating the UI and the developers are coding. What does the design staff give the developers (.XAML files? an assembly?)
From Microsoft.
An open source app with relatively simple ui that is well designed is crack.net. I used it to finally understand mvvm.
As for design workflow, that's a harder question to answer for you. You need to figure out what will work for you and your designers. They can work within the same .proj file as your developers and that's very conveinient. But you may want to separate those assemblies for management sake.
As far as workflow goes.
I had worked in a team where we had a dedicated UI designer. Though he had a degree in CS he said that using Blend distracts too much from the UI design. So he still was doing mock-ups and a developer was translating that in Blend+VS+manual XAML tweaks.
Also, despite what is claimed, Blend is most useful as an example-snippet editor to better understand XAML.
On my current WPF project I use Kaxaml mostly, since WPF editor in my installation of VS is painfully slow and in-stable.
The idea is that your designer will produce you XAML and developer will simply add code to that - didn't work for us. And honestly, I don't see how that can work at all. Since there are still many things in UI that need to be tweaked for the presentation layer.
Also, any UI technology can be isolated in a well designed system. And I don't really see any advantages of WPF at that. Especially that MS promotes data-binding so eagerly.