What exactly is WPF, and why is it better than C#?
-
Dave Calkins wrote:
Being able to have multiple versions of an app installed side by side and each using the runtime they were built for can be a nice feature.
Which is why breaking changes are contained to major framework version increments, the only changes between major versions are to close exploits, and you can install and force an app to run on an old version of the framework. If you write software that relies on an exploit in a run time to work, it's not only your code that deserves to be broken. Edit: Whoracle's attempts to try and do the absolute minimum changes needed to close an exploit without breaking any applications that are doing similarly doggy activities was part of why we recently had the barrage of serial exploits where slightly modified versions of the attack worked around each new patch.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
Dan Neely wrote:
without breaking any applications that are doing similarly
doggyactivitiesIs that like "It's a doggy dog world?"
The difficult we do right away... ...the impossible takes slightly longer.
-
Yes, that's a good point and is a strength of the single central update approach. On the downside, its possible that the single update can then break older software. Or another scenario is where you want to install and run 3 different versions of an application which was built against 3 versions of some dependency which might not be completely backwards compatible. Being able to have multiple versions of an app installed side by side and each using the runtime they were built for can be a nice feature. But the security concern is a valid one and one approach for that is the central update. You can distribute with your own dependencies though provided you do keep up to date and your users keep up to date with things.
Dave Calkins wrote:
Yes, that's a good point and is a strength of the single central update approach. On the downside, its possible that the single update can then break older software. Or another scenario is where you want to install and run 3 different versions of an application which was built against 3 versions of some dependency which might not be completely backwards compatible. Being able to have multiple versions of an app installed side by side and each using the runtime they were built for can be a nice feature.
That however is idealistic fantasy in the modern desktop OS. The only that way that can happen is if you deliver the hardware with your software installed and with a license that does not allow the user to update anything on the hardware. Because otherwise any update to the system might, conceivably, break your software. Because that other software install might install an OS patch and that in turn might break your software.
-
I'll never understand why people hate on VB. I can understand not liking a particular language - what I don't understand is being bothered by someone else's use of it.
At work I write VB and C# whereas at home my preference is for C#(purely because there are more articles on C# and I have a preference for its elegance). There really is not much of a difference, in my experience, and I find I can swap between the two quite easily. There have even been cases where I have created a DLL in VB because it was easier to do that than write the code in the C#(and vice versa). In some ways this is the beauty of the .Net framework - you can program in multiple languages picking the one that suits you and your team best.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
Dave Calkins wrote:
Yes, that's a good point and is a strength of the single central update approach. On the downside, its possible that the single update can then break older software. Or another scenario is where you want to install and run 3 different versions of an application which was built against 3 versions of some dependency which might not be completely backwards compatible. Being able to have multiple versions of an app installed side by side and each using the runtime they were built for can be a nice feature.
That however is idealistic fantasy in the modern desktop OS. The only that way that can happen is if you deliver the hardware with your software installed and with a license that does not allow the user to update anything on the hardware. Because otherwise any update to the system might, conceivably, break your software. Because that other software install might install an OS patch and that in turn might break your software.
Yes, there's no way to completely insulate the app unless you lock down and control the system as you say. So there still is possibility that something could be broken by an update. Just like you probably can't do a 100% xcopy deployment, there's inevitably dependencies that creep in here and there. But it is possible to ship with the C RTL and MFC if you're using those and have a significant dependence under your control. Again, you then have to take care to update those as applicable.
-
My apologies, in advance, for the code dump. I do a lot of WPF, and the combination of XAML and C# in WPF is extremely powerful. Here's part of an application I'm currently working on, where an interface element is hidden until it's needed, then it's displayed almost transparent until the user needs it and when they mouse over or touch down on it, the control moves into view and makes itself solid.
<UserControl x:Class="Huda.Views.HistogramView"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
mc:Ignorable="d"
xmlns:vw="clr-namespace:Huda.Views"
Width="650"
Height="220"
x:Name="histogramView"
DataContext="{Binding Histogram, Source={StaticResource Locator}}"
Visibility="{Binding IsVisible}"
d:DesignHeight="300" d:DesignWidth="300" Opacity="0.2">
<UserControl.RenderTransform>
<TransformGroup>
<TranslateTransform/>
</TransformGroup>
</UserControl.RenderTransform>
<UserControl.Resources>
<Storyboard x:Key="OnMouseEnter1">
<DoubleAnimationUsingKeyFrames Storyboard.TargetProperty="(UIElement.RenderTransform).(TransformGroup.Children)[0].(TranslateTransform.Y)" Storyboard.TargetName="histogramView">
<EasingDoubleKeyFrame KeyTime="0:0:0.0" Value="-69"/>
<EasingDoubleKeyFrame KeyTime="0:0:0.7" Value="-122"/>
</DoubleAnimationUsingKeyFrames>
<DoubleAnimationUsingKeyFrames Storyboard.TargetProperty="(UIElement.Opacity)" Storyboard.TargetName="histogramView">
<EasingDoubleKeyFrame KeyTime="0" Value="0.2"/>
<EasingDoubleKeyFrame KeyTime="0:0:0.4" Value="1"/>
</DoubleAnimationUsingKeyFrames></Storyboard> </UserControl.Resources> <UserControl.Triggers> <EventTrigger RoutedEvent="Mouse.MouseEnter" SourceName="histogramView"> <BeginStoryboard Storyboard="{StaticResource OnMouseEnter1}"/> </EventTrigger> <EventTrigger RoutedEvent="TouchDown" SourceName="histogramView"> & -
That's what sold me on Silverlight. I absolutely love the control we have over controls. The ability to change the shape/color/behavior of anything is like magic.
I'm doing this for the Intel Ultimate Coder competition, and the speed I can crank out code is testament to the power of WPF (or Silverlight if you prefer that). I've got this control in place, and I'm adding in the option to trigger this display based on a gesture or voice command - and given the ease of customisation, the amount of code I have had to write is dramatically reduced.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier -
Not true. If you're writing native C++/Win32/MFC code you can distribute all the runtime lib and MFC dependencies as DLLs in your install directory. Very clean. Its a shame the newer technologies seem to completely ignore deployment hassles and just dump it all on the end user to install some framework/runtime just to run your app. Xcopy deployment is the way it should be imo :) Its not that you have the issue in any technology, its that you have the issue when the technologies are built without regard for deployment.
Dave Calkins wrote:
Xcopy deployment is the way it should be imo :)
That's still possible, you'd just not be doing it in a managed environment. If you want the benefit of a complete framework, that's the price you pay. Most machines will already have it, since quite some apps use it these days. It's also already baked in into the still supported Windows-systems. No, it won't run on Win98.
Dave Calkins wrote:
Its not that you have the issue in any technology, its that you have the issue when the technologies are built without regard for deployment.
You think it's more efficient to compile the 20Mb runtime into the app itself? Remember that the .NET framework is a bit "more" than the Delphi VCL, and also comes with a VM. ..but do feel free to write C++/MFC code.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
I'm doing this for the Intel Ultimate Coder competition, and the speed I can crank out code is testament to the power of WPF (or Silverlight if you prefer that). I've got this control in place, and I'm adding in the option to trigger this display based on a gesture or voice command - and given the ease of customisation, the amount of code I have had to write is dramatically reduced.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier -
It's perfection is why it had to be abandoned. Microsoft is always quick to jettison the good stuff.
I'd be fonder of WinRT if they hadn't crippled it with an incomplete implementation. No Blend behaviour support. No custom Markup extensions. No type converters. :sigh:
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier -
Dave Calkins wrote:
Xcopy deployment is the way it should be imo :)
That's still possible, you'd just not be doing it in a managed environment. If you want the benefit of a complete framework, that's the price you pay. Most machines will already have it, since quite some apps use it these days. It's also already baked in into the still supported Windows-systems. No, it won't run on Win98.
Dave Calkins wrote:
Its not that you have the issue in any technology, its that you have the issue when the technologies are built without regard for deployment.
You think it's more efficient to compile the 20Mb runtime into the app itself? Remember that the .NET framework is a bit "more" than the Delphi VCL, and also comes with a VM. ..but do feel free to write C++/MFC code.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
I don't think 20MB is a significant size to worry about, no. Actually if you compile it "into the app itself" as you said it would likely be smaller, if you distribute all the libraries as DLLs then the size is more like the 20MB you're referring to (assuming 32-bit and 64-bit libs are included). And C++/MFC code is exactly what I was talking about. Its a case where you can ship with your libraries and not require your framework to be installed separately. Not saying that applies in every case, just that it is a case where you have the ability to do that. Obviously if you're targeting .NET you then have to deal with the runtime install. It is helpful that, if the user is installing windows updates, they'll likely get the framework updates through that. Perhaps the "without regard for deployment" was a bit strong, just expressing my appreciation for being able to just ship the libraries with the app when doing C++/MFC :)
-
For starters, I made this and this (both funky UI's that would be hard to make with Windows Forms) in WPF with relative ease. For one, the binding syntax is super customizable. It really makes MVVM super powerful. On top of that, user interfaces are super customizable. You can put at tree inside a button inside a rich text control (or whatever you want). And since views are templated, you can override views and make them look however you want. And since it's all declarative, it's really easy to do. And pretty much everything can be nested and layed out however you like, as with this example of a label/circle/button inside of a button:
<Button>
<StackPanel>
<TextBlock>Hello</TextBlock>
<Ellipse Width="100" Height="100" Fill="Azure"></Ellipse>
<Button>Nested Button!</Button>
</StackPanel>
</Button>If you want something fun to work on, WPF is where it's at (though the new WinRT stuff is similar in that it uses XAML and it's the way Microsoft seems to be going from now on). Note to hamsters: I had to recreate this entire post, because my browser froze when I pasted the above code snippet. :mad:
Thanks for those two examples! I have not used WPF and have been curious about it, so it is good to see some concrete examples that show just what can be done. I think it has whet my appetite and I might start looking into implementing something simple to get more of an idea of just what the advantages are.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
I don't think 20MB is a significant size to worry about, no. Actually if you compile it "into the app itself" as you said it would likely be smaller, if you distribute all the libraries as DLLs then the size is more like the 20MB you're referring to (assuming 32-bit and 64-bit libs are included). And C++/MFC code is exactly what I was talking about. Its a case where you can ship with your libraries and not require your framework to be installed separately. Not saying that applies in every case, just that it is a case where you have the ability to do that. Obviously if you're targeting .NET you then have to deal with the runtime install. It is helpful that, if the user is installing windows updates, they'll likely get the framework updates through that. Perhaps the "without regard for deployment" was a bit strong, just expressing my appreciation for being able to just ship the libraries with the app when doing C++/MFC :)
Dave Calkins wrote:
I don't think 20MB is a significant size to worry about, no. Actually if you compile it "into the app itself" as you said it would likely be smaller, if you distribute all the libraries as DLLs then the size is more like the 20MB you're referring to (assuming 32-bit and 64-bit libs are included)
More if you take the updates in account.
Dave Calkins wrote:
And C++/MFC code is exactly what I was talking about. Its a case where you can ship with your libraries and not require your framework to be installed separately.
That's a set of libraries, whereas .NET runs a Virtual Machine. It'd be rather inefficient to compile that big a runtime into each app that uses it; makes more sense to have it as a part of Windows itself. Things like a GAC solve a lot of problems, that particular one caused by the XCopy behaviour. It gave us a DLL-hell, and applications with insecure and outdated libraries.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
Not true. If you're writing native C++/Win32/MFC code you can distribute all the runtime lib and MFC dependencies as DLLs in your install directory. Very clean. Its a shame the newer technologies seem to completely ignore deployment hassles and just dump it all on the end user to install some framework/runtime just to run your app. Xcopy deployment is the way it should be imo :) Its not that you have the issue in any technology, its that you have the issue when the technologies are built without regard for deployment.
We had a product written in C# (.net 4.0). Albeit there are many downloads, the actual successful install rate is a lot lower. Part of the causes is because .net 4.0 is not installed on a user's machine by default up to Windows 7 and many users either can't install the framework on their own or are not willing to take time to do it. It is strange that Microsoft developed the framework and somehow does not make it easy for a user to use it.
Having way too many emails to deal with? Try our SQLized solution: Email Aggregation Manager[^] which gets your email sorted, found and organized beyond known precision.
-
Dave Calkins wrote:
I don't think 20MB is a significant size to worry about, no. Actually if you compile it "into the app itself" as you said it would likely be smaller, if you distribute all the libraries as DLLs then the size is more like the 20MB you're referring to (assuming 32-bit and 64-bit libs are included)
More if you take the updates in account.
Dave Calkins wrote:
And C++/MFC code is exactly what I was talking about. Its a case where you can ship with your libraries and not require your framework to be installed separately.
That's a set of libraries, whereas .NET runs a Virtual Machine. It'd be rather inefficient to compile that big a runtime into each app that uses it; makes more sense to have it as a part of Windows itself. Things like a GAC solve a lot of problems, that particular one caused by the XCopy behaviour. It gave us a DLL-hell, and applications with insecure and outdated libraries.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
Eddy Vluggen wrote:
That's a set of libraries, whereas .NET runs a Virtual Machine.
Yes, it would be a different matter trying to apply the xcopy deployment to the entire .NET framework, I agree :) But it is nice that with C++/MFC you can deploy that way and the size penalty is not significant. If you take the approach of shipping C++/MFC libraries with the application, then yes you do need to make sure you update them and that your users do update the software since you can't rely on the Windows update mechanism to push the new framework updates out. In terms of DLL hell, using a private assembly within your app install directory should not adversely affect other apps. You do have the extra space by shipping with your own copy, but in this case that isn't a huge penalty. Speaking of the GAC, it had the problem of replacing DLL hell with manifest hell. It appears MS decided manifest hell was actually worse than DLL hell as VS2010 reverts back to a much simpler approach with the C++ runtime libs and MFC :)
-
I'd be fonder of WinRT if they hadn't crippled it with an incomplete implementation. No Blend behaviour support. No custom Markup extensions. No type converters. :sigh:
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier -
I imagine most of that will come in time, won't it? I've not looked into WinRT and probably won't for another two years. I don't care to be a guinea pig while they work out all the bugs. Is it very similar to developing in WPF/Silverlight?
MehGerbil wrote:
I imagine most of that will come in time, won't it?
I'm not sure it will. Unfortunately, WinDiv has too much say.
MehGerbil wrote:
Is it very similar to developing in WPF/Silverlight?
Not really. If you know XAML, it's not too bad, but you're best thinking of it as being closest to Windows Phone.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier -
At work I write VB and C# whereas at home my preference is for C#(purely because there are more articles on C# and I have a preference for its elegance). There really is not much of a difference, in my experience, and I find I can swap between the two quite easily. There have even been cases where I have created a DLL in VB because it was easier to do that than write the code in the C#(and vice versa). In some ways this is the beauty of the .Net framework - you can program in multiple languages picking the one that suits you and your team best.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
GuyThiebaut wrote:
There have even been cases where I have created a DLL in VB because it was easier to do
:confused:
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
Think inside the box! ProActive Secure Systems
I'm on-line therefore I am. JimmyRopes -
GuyThiebaut wrote:
There have even been cases where I have created a DLL in VB because it was easier to do
:confused:
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
Think inside the box! ProActive Secure Systems
I'm on-line therefore I am. JimmyRopesJimmyRopes wrote:
GuyThiebaut wrote:
There have even been cases where I have created a DLL in VB because it was easier to do
:confused:
Before .net 4.0 and C# optional parameters writing COM wrappers was often easier in VB because you could use 3 named parameters to call the COM object instead of having to seed your three values in between several dozen null's. I'm not aware of any cases where VB.net still has significantly better language support for a feature than C# (and VB's LINQ syntax is an abomination, and LINQ has becoem such a large part of my programming habits that it's already at -100 just for that). If there still are things easier to do in VB I'm eager to be proven wrong because the less time I spend swearing at tools that make my job harder than it has to be the happier I am at work.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
JimmyRopes wrote:
GuyThiebaut wrote:
There have even been cases where I have created a DLL in VB because it was easier to do
:confused:
Before .net 4.0 and C# optional parameters writing COM wrappers was often easier in VB because you could use 3 named parameters to call the COM object instead of having to seed your three values in between several dozen null's. I'm not aware of any cases where VB.net still has significantly better language support for a feature than C# (and VB's LINQ syntax is an abomination, and LINQ has becoem such a large part of my programming habits that it's already at -100 just for that). If there still are things easier to do in VB I'm eager to be proven wrong because the less time I spend swearing at tools that make my job harder than it has to be the happier I am at work.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
Dan Neely wrote:
Before .net 4.0 and C# optional parameters writing COM wrappers was often easier in VB
That was before Micro$oft abandoned their golden child. As they often do they champion a technology and then abandon it. These days, there is no reason, except for getting paid to do it, to code in VB. <confession> I once had a contract coding in VB6. Yes I am a code whore. Pay me enough and I will code in any language you like. It doesn't mean I like it or that I am proud of my actions. And yes, I did like that I could use an enum as an input parameter to a dll function and have a drop down to select for that parameter. That is the only thing I liked about VB that I couldn't replicate in C#. </confession>
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
Think inside the box! ProActive Secure Systems
I'm on-line therefore I am. JimmyRopes -
GuyThiebaut wrote:
There have even been cases where I have created a DLL in VB because it was easier to do
:confused:
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
Think inside the box! ProActive Secure Systems
I'm on-line therefore I am. JimmyRopesIt was a few year back, I would have to try and dig out what it was but I think Dan has hit it on the head and it was something to do with speech recognition and COM wrappers. I have recently done the opposite where I wrote a DLL in C# for a VB application because I knew I would be using the DLL again and as I mentioned I have a preference for C# due to its elegance :)
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
