|
Which part are you having trouble with?
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
I think he may be calling out the lack of the equivalent controls that ASP.NET has. It also makes it look like the membership system and all that role based security is missing.
I myself am looking for examples of this and looking into the sever that I have found, many once again using services 
|
|
|
|
|
You can check RIA service if you are using Silverlight 3.
Thanks and Regards,
Michael Sync ( Blog: http://michaelsync.net)
Microsoft MVP (Silverlight), WPF/Silverlight Insiders
|
|
|
|
|
Hi,
I am developing one silverlight application in that I placed one main canvas(LayoutRoot) and there are 6 child canvas are there with videos.I have written mouse events for main canvas and child canvas seperately.Purpose when I drag and drop main canvas it will drag entire canvas with child canvas and if I drag one of the child canvas it shouldn't drag main canvas too only drag one that particular canvas.I am facing problem that if I drag main canvas
its working good and if I try to drag one of those child canvas it is dragging main canvas also.Can you please anybody help me how to stop main canvas mouse button events wont effect on child canvas.
Thanks in Advance
Pavani
|
|
|
|
|
Are you marking the mouse events "handled" after you handle them?
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
thank you for your response. I have written the mouse down,mouse up and mouse move events for parent canvas and child canvas to drag and drop those canvas.
But If I drag parent cavas it is working fine if i try to drag child canvas parent canvas events are also firing.So,I have put e.handled=true in child canvas mouse down and mouse up events now its not firing parent canvas mouse down and mouse up but parent canvas mouse move event is firing.Because of that if I drag child canvas parent canvas is also dragging.Please help me how to stop firing parent canvas mouse move event.there is no handled=true in mouse move event to set.
|
|
|
|
|
I have written the mouse down,mouse up and mouse move events for parent canvas and child canvas to drag and drop those canvas.
But If I drag parent cavas it is working fine if i try to drag child canvas parent canvas events are also firing.So,I have put e.handled=true in child canvas mouse down and mouse up events now its not firing parent canvas mouse down and mouse up but parent canvas mouse move event is firing.Because of that if I drag child canvas parent canvas is also dragging.Please help me how to stop firing parent canvas mouse move event.there is no handled=true in mouse move event to set.
|
|
|
|
|
I typically just add a flag to my class like "bool isInDrag;".
Set the flag true on mousedown, false on mouse up, and only handle mousemove event
if the flag is true.
You may need two flags if your handlers are in the same class 
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Hi,
I am working on a WPF application. In this I have to implement RSS feeds in my WPF application. Please help me how can I implement RSS feeds in my WPF application.
IF you have any idea, Please reply me.
Thanks in advance.
|
|
|
|
|
|
This is a fairly trivial task. As RSS is just XML, all you need to do is read the feed into an XML document, and parse it - possibly using XLinq. To be honest, you could write a simple RSS reader entirely in XAML with no code behind whatsoever using the XmlDataProvider.
"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
|
|
|
|
|
Somehow, my boss hgot it in his head that Silverlight would be a viable technology to deploy an enterprise-level application. We've just spent the last 6 weeks creating a WPF demo, and I'm not in favor of changing to Silverlight at this point.
Can anyone with specific knowledge comment on the pros/cons of using Silverlight over a desktop WPF application? I want a clear and un-biased comparison of the two.
"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
modified on Tuesday, May 26, 2009 6:50 PM
|
|
|
|
|
Here is my un-biased answer - Silverlight rocks!
|
|
|
|
|
That's a completely useless f*ckin' answer.
"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
|
|
|
|
|
I guess I should have used the joke icon..
here another useful answer - The reasons why you should use silverlight over WPF is one that only your boss and I know. We cannot share the buisness secret with a commoner.
[A Serious Answer]:
if you google Silverlight vs WPF you get 2.5 Million result!
This is from my bookmark:
BLOG[^]
|
|
|
|
|
Bassam Saoud wrote: [A Serious Answer]
Quoted from that blog;
"The maddening answer is (of course): it depends!"
The link you pasted says it depends, whereas you say it "rocks". Now which of the two do you want?
I are troll 
|
|
|
|
|
i was making a joke damn it
|
|
|
|
|
John Simmons / outlaw programmer wrote: pros/cons
should'nt that be sucks/blows ?
This signature was proudly tested on animals.
|
|
|
|
|
Silverlight is WPF web 3.0ified. 
Afaik the only other major change is that you've got the normal web app based lack of local storage/pc access.
It is a truth universally acknowledged that a zombie in possession of brains must be in want of more brains.
-- Pride and Prejudice and Zombies
|
|
|
|
|
I was playing with Silverlight / WPF early on, and the best way I can describe it is that Silverlight is, essentially, a subset of WPF. Silverlight is stripped down to accomodate the stuff you can do in a web browser (don't get me started) versus what you can do in a client app ala WPF.
So, what your boss is asking you to do is reduce by a significant percentage the capabilities of the development platform you're using, for the benefit of being able to run it in a web browser. If you're doing stuff on the wide web, perhaps there's a case for that. If it's for internal company use only, then it's an unproductive decision that offers no benefits other than being able to say that you're trendy.
|
|
|
|
|
Christopher Duncan wrote: other than being able to say that you're trendy.
Which sometimes may be a deal maker.
Trust me, an "Enterprise Application" these days is naturally expected to have a web based front-end. IT departments love web based applications over desktop applications as it usually means a lot of time saved to them in support and deployment.
|
|
|
|
|
Rama Krishna Vavilala wrote: IT departments love web based applications over desktop applications as it usually means a lot of time saved to them in support and deployment.
That's the promise. Sadly, the reality often falls far short and there's just as much pain in supporting said application, having followed a vastly increased development time as you spend so much time working round web app limitations.
"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
|
|
|
|
|
Pete O'Hanlon wrote: Sadly, the reality often falls far short and there's just as much pain in supporting said application, having followed a vastly increased development time as you spend so much time working round web app limitations.
Same thing happens in desktop apps. Count the calls to DoEvents() in a legacy VB app, and you'll get a feel for how much time the author spent fighting, rather than working with the threaded, event-driven model of Windows desktop apps...
|
|
|
|
|
Shog9 wrote: Count the calls to DoEvents() in a legacy VB app
No I won't. 
Seriously though, I agree with Pete, browser development is seriously limited, it is supposed to be. That is not at all comparable to the limitations of the Programmer using the tools.
The invention of the Web and Browsers was never intended to be used as a replacement for client/server desktop applications. The pains we are currently going through is no more than squeezing a balloon where we transfer the problems associated with installing/maintaining local software to a whole new set of problems that are generated using browser development. The inherent limitations of HTTP/HTML have no comparable limitations in desktop development and likely tip the scale when comparing the two approaches.
There are certainly perfectly good scenarios demanding browser based applications. However the current trend completely ignores the choice of desktop versus browser even in situations where the criteria clearly suggests desktop would be a better fit. I am fairly confident that history will view this as a an all to common failure.
|
|
|
|
|
led mike wrote: The inherent limitations of HTTP/HTML have no comparable limitations in desktop development and likely tip the scale when comparing the two approaches.
Sure they do. Or rather, they can - don't think of it as HTTP+HTML vs. C++ native app running as root/admin, think of it as a VB app running as a limited user: you've accepted certain limitations in exchange for a framework that lets you do certain things more easily / provides extra security for your users / etc. Folks did some rather complex apps with VB, but still the framework was never designed for multithreading, access to system APIs, etc. In both cases, as soon as you step outside of what was easy, what was envisioned by the designers (data-entry forms / static text pages...), things got weird and difficult.
led mike wrote: There are certainly perfectly good scenarios demanding browser based applications. However the current trend completely ignores the choice of desktop versus browser even in situations where the criteria clearly suggests desktop would be a better fit.
IMHO, the primary difference with the Web stuff is that we're not in control. After decades of writing apps that - given the right choice of language and library - could pretty much treat the user's system as their own private playground, we're back to writing server software that has only very limited control over the terminals it must use for interacting with users. You really can't publish system requirements for a web page if you want it to have a broad audience; for an internal app, you might be able to mandate a certain browser version and perhaps also screen size and color depth, but ultimately the user still has final say over more factors than you do, and if you don't accept that then both of you will suffer for it.
And... I love it. Because the truth of the matter is, for every desktop app that understood the responsibility that came with the power to control everything, there were scores of apps that saw it as a invitation to abuse that power, to reach in and screw with my system in rude ways, place arbitrary restrictions on how i could use the app itself, or fail to play nicely with other apps. It's forced developers to learn to write scalable software, after decades of "threads are hard, let's call DoEvents" attitudes. And it's put the users back in control of their own data and their own hardware.
led mike wrote: I am fairly confident that history will view this as a an all to common failure.
History is notoriously cyclical. Plenty of perfectly good mainframe apps ported to the desktop without improving performance, data-entry efficiency, or reliability (although there was plenty of opportunity to achieve all three...) just because desktop apps were Teh New Hotness. Plenty of perfectly good text apps turned into GUIs for the same reason. And now, we're seeing web apps replacing perfectly good desktop apps... including some of the same sorts of applications originally written for now-ancient terminals.
Pointless re-writes and counter-productive redesigns didn't start with The Web, and certainly won't end with it... I'm willing to bet that right now there are teams of programmers re-writing perfectly good web apps in WPF, Silverlight or Air. C'est la vie...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
