What exactly is WPF, and why is it better than C#?
-
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.
Disagree strongly. The one framework installation to rule them all is a major security enhancement. A single update gets library fixes deployed to every client application; without it most would remain exploitable for months or years in the future because even of the application developer did create a new redistributable with the fix most users would never check for a new version.
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
-
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.
-
MehGerbil wrote:
You can use VB, C# or other languages in the creation of applications
FTFY
If it moves, compile it
-
Disagree strongly. The one framework installation to rule them all is a major security enhancement. A single update gets library fixes deployed to every client application; without it most would remain exploitable for months or years in the future because even of the application developer did create a new redistributable with the fix most users would never check for a new version.
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
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.
-
I think you're looking at it with rose colored glasses. I'm pretty sure that is the sort of nonsense that frameworks were meant to fix.
My comment wasn't addressing use of frameworks, it was deployment of those frameworks. There are cases where being able to cleanly deploy with the framework embedded in the application can be a good thing.
-
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:
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
-
My comment wasn't addressing use of frameworks, it was deployment of those frameworks. There are cases where being able to cleanly deploy with the framework embedded in the application can be a good thing.
What I meant to say was that I've never had an application cleanly deploy that way - not even using the scenario you present. The C++ runtime, or the browser, or a .PDF reader, or Direct X, or such and such a toolkit, or security updates for the C++ runtime included with the software has to be updated, patched, re-installed, configured, homogenized, or a dozen user agreements signed, checked, read, viewed, or clicked through. This is with software distributed on a disk - because within 2 weeks the disk is out of date. Most of these require a re-boot whereas an update to Silverlight does not. Yes, XCOPY would be very nice. I've never had it happen.
-
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.
-
I actually write VB part of the time. I don't have an issue with it at all. Isn't it a Meme?
If it moves, compile it
-
What I meant to say was that I've never had an application cleanly deploy that way - not even using the scenario you present. The C++ runtime, or the browser, or a .PDF reader, or Direct X, or such and such a toolkit, or security updates for the C++ runtime included with the software has to be updated, patched, re-installed, configured, homogenized, or a dozen user agreements signed, checked, read, viewed, or clicked through. This is with software distributed on a disk - because within 2 weeks the disk is out of date. Most of these require a re-boot whereas an update to Silverlight does not. Yes, XCOPY would be very nice. I've never had it happen.
Yes, thats true :) Maintaining a completely clean xcopy deployment might not be possible, but I try and achieve that to the degree it is possible. Noting the security concerns raised by the other poster, it is nice to be able to have a more self contained install and control the dependencies, but as was said, you then also have to be aware of updating and ensuring your users do so too.
-
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
I understand what you're saying but its not necessarily a valid assumption that an application which is more self contained is doing anything "dodgy" or relying on exploits. Of course those things wouldn't be good :)
-
I've seen this popular thing on here. It's called WPF, I never really looked into it, because I am not into new things. But I've seen some cool things you can create with it. But, what exactly is it, is it different than Forms C#?
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"> & -
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
