|
That's cool, but how quickly would this have been developed as a desktop app?
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
That's a tough one. If we had just gone WinForms, maybe half the time, but to keep our Mac clients as well, maybe twice the time. When the decision was made to go web, Mono was till quite lacking, and non of the other so-called cross platform libraries came close.
|
|
|
|
|
Pete O'Hanlon wrote: ollowed a vastly increased development time
I don't agree with it necessarily.
My experience in terms of rapidity of development has been:
VB6 / Winforms > ASP.NET > ASP.NET with jQuery/ExtJS > MFC > WPF > SilverLight.
If I want to develop something really quick and dirty and short lived form/grid based LOB app, I invariably choose winforms.
However, I have found that in a complex - long lived project the choice of technology itself plays very less part in the development time. Because each technology comes with its own set of problems.
|
|
|
|
|
And web applications are truly independent of OS on the clients.
You really gotta try harder to keep up with everyone that's not on the short bus with you.
- John Simmons / outlaw programmer.
|
|
|
|
|
It's just a shame that they aren't browser independent.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
Ours is getting damn close through extJS.
You really gotta try harder to keep up with everyone that's not on the short bus with you.
- John Simmons / outlaw programmer.
|
|
|
|
|
Well, these days there is no excuse of writing browser dependent code. The Javascript libraries are extremely powerful and encapsulate lot of complexities away.
|
|
|
|
|
Christopher Duncan wrote: then it's an unproductive decision that offers no benefits other than being able to say that you're trendy.
Which can then be wrapped as as saying it's "Enterprise" ready, and the decision is practically a given! 
|
|
|
|
|
Jim Crafton wrote: Which can then be wrapped as as saying it's "Enterprise" ready, and the decision is practically a given!
So does that mean the software is approved by Star Fleet Command?
|
|
|
|
|
Christopher Duncan wrote: to accomodate the stuff you can do in a web browser (don't get me started)
No, seriously. Why don't you tell us what you think of web applications?
|
|
|
|
|
John - you already know that I like this stuff, so let's get this out of the way straight away, Silverlight is a long way from being able to do the tasks that you'd typically want to do for Enterprise level applications. There's a lot of functionality that you'd want as part of the base framework that you end up having to write yourself.
It sounds like he's picked up a tech magazine and read the byline without having a clue about what's going on. Bottom line - stop reading the toilet roll packets and assuming that it's reality.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
|
John Simmons / outlaw programmer wrote: that Silverlight would be a viable technology to deploy an enterprise-level application.
Answer to this question and any other similar question is that - it depends!
In my experience, deploying application via web browsers is preferred by IT departments of many big companies. So Silverlight scores big points in that area. Silverlight is obviously a subset of WPF but if the subset is enough for your needs, there is no reason why you should not go for it. Also by discipline it is possible to use same code base for WPF and SilverLight which will offer best of both worlds.
Also look at technologies such as Prism and .NET RIA services. They look promising (from a distance at least).
If you can live with certain limitations of SilverLight like running in a sandbox environment and support for only a subset of .NET framework, by all means, go for SilverLight.
One advantage of Silverlight is that it can run on Mac which does not matter for matter for many enterprise applications.
|
|
|
|
|
I would suggest that if your boss wants you to develop in SilverLight then he should send you to a class for programming business applications with Silverlight. Good luck finding one...
I didn't get any requirements for the signature
|
|
|
|
|
Deployment is a big pro for Silverlight:
Silverlight will act like a web application -- it runs right there in the browser, no manual install required. It doesn't require the full, huge .NET framework. (It uses a subset of the .NET framework that takes less than a minute to install on a fresh machine.)
Compare this to to installing the latest WPF runtime on a fresh machine without the .NET framework, which will involve a big download, longer install time, and possibly restarting the computer.
Silverlight apps run in a sandbox; you can't harm the end user's machine.
Silverlight apps and data can be indexed by search engines[^] if you do things right.
Silverlight runs on multiple platforms, including the Mac. With Mono's Moonlight port of Silverlight, you can also run your Silverlight app on Suse, Ubuntu, and Fedora[^].
A con for Silverlight: it doesn't offer everything WPF offers, many WPF features and APIs are missing from Silverlight. Also, because of the sandbox, you can't do things like pop up dialogs willy-nilly, your access to the file system is limited to the isolated storage directories, and you're limited in how much data you can store on the end-user machine.
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon
Judah Himango
|
|
|
|
|
John Simmons / outlaw programmer wrote: I want a clear and un-biased comparison of the two.
Urgentz ... pleze.
|
|
|
|
|
John,
The development team I'm currently on is facing similar issues, minus the "boss" part.
Here's what I can tell you:
1). There is very little cross-over between WPF XAML and SilverLight
2). SilverLight 3.0 is really closer to be "LOB ready", don't waste time with 2.0
Other issues:
10 SilverLight Gotchas, with SilverLight 2.0[^]
But again, from what the "guys" on my team have mentioned, I would skip 2.0 and concentrate effort on 3.0.
|
|
|
|
|
You already know, like Pete, I love this stuff too.
A year ago I laughed and joked with everyone at the thought of me doing web apps...
now it's my main business, all using Silverlight/ASP.NET/WCF.
I'm not going to answer your question - I think you know you have to research the pros
and cons, and better yet, try it yourself.
I will say, however - PLEASE beg your boss not to do it. I don't want to see your posts here (after
you've been working with WPF) as you realize painfully how much Silverlight IS a SUBSET of WPF...the lack
of rich WPF databinding in markup alone makes me cry (luckily I like writing actual code anyway)...
Please....no...
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Mark Salsbery wrote: I will say, however - PLEASE beg your boss not to do it. I don't want to see your posts here (after you've been working with WPF) as you realize painfully how much Silverlight IS a SUBSET of WPF...the lack
of rich WPF databinding in markup alone makes me cry (luckily I like writing actual code anyway)...
If there was a site available that listed the things you probably won't like about WPF (and/or Silverblight), at least I would have gone in with my eyes open instead of being utterly surprised at how much it still sucks after three years. And truth be told, it's not so much WPF itself as it is the tools.
Since I already knew Silverblight is a subset of WPF, and since I already know that the WPF tools suck, it just goes to reason that developing for Silverblight is going to suck as well. For those reasons, you won't get any of the same "Why Silverblight Sucks Today" messages that I've already gone over for WPF. However, if some new suckage raises its ugly head, I will most assuredly expose it to the light of day. In fact, I already have a new suckage item regarding Silverblight, direct from Microsoft.
I guess you'll just have to deal with it and try to talk me down if I get too agitated. Remember, I don't want to hate this stuff, but Microsoft hasn't taken any steps - at all - to ease my pain. I can handle tools that are merely adequate, but when they just plain suck ass, it pisses me off.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Actually now that I've reread your entire post and not just the topic
(because comparing Silverlight to WPF is, well no comparison),
I'll answer...
John Simmons / outlaw programmer wrote: the pros/cons of using Silverlight over a desktop WPF application?
Cons:
1) The sandbox
2) Very small subset of the .NET framework (although for certain app types, there's plenty)
3) It runs in a browser. 3.0 has offline capability, but it's still in a browser
Pros:
1) It runs in a browser. but it runs in more than one browser on more than one platform.
2) Deployment. There's no easier deployment - including ClickOnce
Now, if you're convinced you want or need a browser based app, perhaps because it's cross platform
and deployment is easy, then there's even more pros:
1) You can leverage existing .NET skills, like C#/VB.NET on a browser platform
2) The Silverlight runtime provides a subset of .NET, so interacting with existing desktop .NET based applications (like using WCF and/or ASP.NET) can be much simpler.
3) Silverlight apps actually run code on the client, unlike other web technologies like ASP.NET (and Silverlight code runs faster than js). Depending on the application, and with a thoughtful design, this can benefit web app performance by allowing distribution of CPU load between server and client.
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I have a textbox and it need the user not allow to enter any specialcharecters
He can enter 1. A-Z
2. a-z
3. 0-9
4. Space.
How can I make the KeyDown event to do this?
|
|
|
|
|
Rather than use KeyDown, try PreviewKeyDown on this instead. More importantly though, are you sure you've thought this through properly? What happens if the user presses the backspace or Delete key? What about the Tab key?
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
What I need is he can't enter any special characters in the textbox.
|
|
|
|
|
How do you define a special character? You need to think about your requirements a bit more. For instance, what about an apostrophe? If you're masking inputs like this, you wouldn't allow my surname through - and that would seriously annoy me (to the point where I probably wouldn't use your product).
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
I like to use the KeyPress event. Here is a sample that allows only alpha characters, numbers, and the control keys like enter, tab, backspace, delete, etc.
Private Sub txtMyTextbox_KeyPress(ByVal sender As Object, ByVal e As System.Windows.Forms.KeyPressEventArgs) Handles txtMyTextbox.KeyPress
If Char.IsDigit(e.KeyChar) OrElse Char.IsControl(e.KeyChar) OrElse Char.IsLetter(e.KeyChar) Then
e.Handled = False
Else
e.Handled = True
End If
End Sub
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
