Is it possible for kids with only HTML/CSS programming experience to do game programming in SilverLight 4.0?
They are using Visual Web Developer 2010 Express edition.
Do they have to learn c# or any other language since they are just starting out?
Thanks
What age range are you talking about? I imagine if you had really smart kids, they could pick-up SilverLight 4.0, but yes, learning C# for the logic and XAML for the GUI would be required.
Ergo, my recommendation is to skip SilverLight given your requirements.
Instead, you should try Scratch which is a programming language designed for kids. It's very visually based and introduces the basic concepts of programming yet allows them to create their own games with ease.
I would say that Silverlight (and infact HTML/Javascript) would be difficult for children to grasp and easily produce a game without getting bored and frustrated.
You could try Kodu as a possible alternative:
Kodu is a visual programming language
made specifically for creating games.
It is designed to be accessible for
children and enjoyable for anyone.
Kodu provides an end-to-end creative
environment for designing, building,
and playing your own new games. The
core of the Kodu project is the
programming user interface. The
language is simple and entirely
icon-based. Programs are composed of
pages, which are broken down into
rules, which are further divided into
conditions and actions. Conditions are
evaluated simultaneously.
Well, lets start that - HTML / CSS is not programming. There is no logic in there that requires programming, so ANY programming is a totalyl different area an they will have to get started at point 0. If you would have javascript in the HTML/CSS side that would be different.
C# would be required - Silverlight backend is done in C#. Quite a lot is required. C# for logic, XAML for the UI, including the powerfull mechanisms for databinding etc. Not a totally easy starter, but as a nice side course it could work.
They will have to learn C#, yes. You can do a lot of the visuals using the XAML declarative markup, but the logic will be driven by C# code.
Related
I hope someone can assist, I am a beginner in computer programming and had purchased a book (Visual Basic - Step by Step), I was making good progress until I read an article on the internet about Windows Presentation Foundation (WPF) - apparently this the future.
I read up on Xaml and I find the syntax extremely difficult to understand, for instance I have been coding using the following format:
texbox1.text = "Hello World!"
However the guides I read on Xaml show that the coding in the .cs file are as follows:
<Grid>
<TextBlock Text="Hello World!" />
</Grid>
I am confused on which 'language' I should be learning!
I hope someone can shed some light into this.
Many thanks
There are many aspects to programming, and it can certainly become overwhelming for a beginner quickly. For starters, let's clear up a few terms:
VB (Visual Basic), C#, and C++ (mentioned in your title) are all high-level programming languages. Assuming that when you say Visual Basic you are referring to VB.NET (which is likely, unless the book you're reading is a decade old...), VB and C# are both languages that can be used with Microsoft's .NET Framework, a set of libraries and tools for building (primarily Windows) applications.
(C++, meanwhile, is a slightly lower-level language not directly connected to .NET. It requires an understanding of certain concepts that the .NET languages hide from you, such as pointers and memory management.)
Now, the programming languages mentioned above are not tied to a specific presentation technology - there are many ways to create interactive programs that display output to users and accept input regardless of the the language you use. The .NET languages, however, are typically used alongside a couple of powerful tools that the .NET Framework provides for creating graphical applications:
Among the simplest user interface methods, you can create a console program which takes typed input and produces text output on the system console. Nothing fancy here.
Windows Forms - originally provided with the pre-.NET versions of Visual Basic, this is a venerable API to the native Windows user interface. It is driven primarily by Form objects that contain Controls and are driven by user Events. Here is a primer.
WPF (Windows Presentation Foundation) is a newer technology than Windows Forms. It is used alongside an XML-like file format, which you've shown above, called XAML (eXtensible Application Markup Language) that lets you build user interfaces by quickly declaring a hierarchy of visual objects. The learning curve for building WPF applications is slightly higher (in my opinion) than that for Windows Forms, but it is a more versatile technology that better supports several good design patterns (that's hand-wavy, I know, but take my word for it for now).
So, to clear up a few points of confusion:
The programming language you use and the framework for building graphical user interfaces are two separate choices.
Both VB.NET and C# can be used to write the underlying logic for Windows Forms or WPF applications
WPF, the graphical subsystem, and XAML, the declarative markup language, are not the same thing, but they are used hand-in-hand with each other.
When creating WPF controls, you will have a file containing XAML (suffixed with .xaml) that is attached to a "code-behind" file containing C# (with a .cs extension) or VB (with a .vb extension), depending on which language you choose.
In general, a .NET programmer (which is an easy example for me to give, as I happen to be one) will use either VB or C# depending on what s/he is most comfortable with (or what's mandated by their team!) From a beginner's perspective especially, the two have different syntaxes but are functionally equivalent. I personally prefer C# for its similarity to the languages (Java and C) in which I learned to program.
Now, whatever the language, a programmer then selects the appropriate user interface technology for the project at hand. For graphical applications running on Windows, I believe that WPF is the tech to beat (especially because it's very similar to Silverlight, which can be used to target the web and Windows Phone).
I hope that at least begins the process of clearing up what is a very complex but navigable topic! I've already linked to it once above, but check out Microsoft's Beginner Developer Center as another resource to get you on your feet. Good luck!
The way you were coding and the xaml markup code does the same thing. The primary reason of XAML existence is to let the UI designers work on the UI using XAML and later programmers would tie up the business functionality using C# or XAML. XAML is primarily used in WPF but languages like C#, VB can be used to do a lot more things. Regarding what languages to learn, it all depends on your interest areas and your job.
djacobson's answer hits 90% of what I was about to write... so this is just a little supplement to that answer giving my personal advice.
If you're just starting out learning programming... it doesn't really matter too much where you start with which 'language' you choose. It looks like you've started out with learning Visual Basic. I write mostly in C#... but for the most part... they can do the same things, and are both good options to start learning about programming.
For your first couple of projects, simply create console applications that don't really have a user interface besides the command prompt (console).
As you move forward and want to start creating applications with a GUI (Graphical User Interface), then you can look into XAML (WPF if you're creating a desktop app, Silverlight if it's a web based app).
You'll still write your business logic code using Visual Basic or C#, the XAML is simply a way to define how your GUI will look and behave using the familiarity of XML rather than an older technology such as Windows Forms.
I'll be the first to say that I absolutely love WPF and XAML, but I truly feel that you're best off learning the basics of the language of your choice first, then work your way into the UI technologies later.
Since from last 2 years I am working on WPF and even I was like blank when it came to WPF. I would prefer C# over C++ and still you can find solutions for every language. But it depends on you what you are comfortable.
Let's suppose you're an IT student with a basic knowledge of C++ and C#. Let's suppose that you want to design apps that:
need to deliver some performance like archivers, cryptographic algorithms, codecs
make use of some system calls
have a gui
and you want to learn an Api that will enable you to write apps like those described earlier and:
is mainstream
is future proof
entitles you to find a decent job
is easy enough - I mean easy like VCL, not easy like winapi
So, making these assumptions, what Api will you choose? MFC, WPF, other? I really like VCL and QT, but they're not mainstream and I think few employers will want you to write apps in QT or Visual C++ Builder...
Thanks for answers.
Note: The following answer was written several years ago with Desktop application development in mind. Today (in 2018), you'd probably just build a web application to end up with something reasonably cross-platform and device-independent. (For example, using ASP.NET Core on the server side, coupled with a UI framework/library such as React, Vue.js, or Angular on the client side).
Win32 API -- I'd forget about it, if I were you. Programming a Windows application directly via the Win32 API only makes sense if you're programming in pure C, or if you really need to do a lot of system calls, or if you're concerned about the additional overhead introduced by more "comfortable" platforms or frameworks (such as the ones named below). Programming UIs directly through the Win32 API is tiresome, messy, and you need to deal with lots of details. It's also not platform-independent at all, but you may or may not be concerned about that.
MFC -- Perhaps an option if you're programming in C++ and fixed on the Windows platform. I never understood what's so great about it, other than it makes the Win32 API much more comfortable (AFAIK it's basically a collection of object-oriented wrappers around the Win32 API that take away some of it's complexity / messyness). Also, it's also not very platform-independent.
Qt, wxWidgets -- Fairly widespread UI frameworks. Might be good options where platform independence plays a role. AFAIK both frameworks are targeted at the C++ language.
WinForms (.NET) -- Similar to MFC, this is also based on the Win32 API (USER32 and GDI+). AFAIK the WinForms framework is now being ported to Mono, and therefore somewhat cross-platform. However, it's not exactly the most up-to-date technology. For complex UIs it can also be somewhat sluggish sometimes. If I had to decide today which framework to use, I'd rather choose...:
WPF (.NET) -- More modern than WinForms, with more graphical capabilities and, apparently, faster rendering, as it is no longer based on the Win32 API (GDI). (And it runs on .NET, which I find a great platform to develop for. Programming in C# is so much easier than programming in C++ IMHO, which is also an argument against Win32 API, MFC, Qt, and wxWidgets.) Note that WPF is not cross-platform, it exists only on the Windows platform so far.
Then of course there's Java, including the UI frameworks that come with it. I can't say much about that since I'm not a Java person, but I could imagine that Java would be the best choice for platform independence; and it's the dominant platform (over .NET) in certain industries (e.g. mobile phones, banking, due to the very solid JVM and security considerations).
So my recommendation would be the .NET framework, and WPF for the UI, if you're planning to stay mostly in the Microsoft world. Remember that you can still use the Win32 API (you won't come closer to "system calls" than that) via P/Invoke.
If you enjoy coding in C# and working with the .Net framework I'd recommend that you have a look at WPF. WPF is a great GUI framework where you can do just about anything - and also make it shine! WinForms might be easier to get a grasp on, but I'd say WPF is more "future proof". Another positive thing is that WPF is really similar to Silverlight, so if you handle WPF well you should be able to write Silverlight applications too - if that's of interest. Please don't bother to learn MFC.. I can't believe there are many that is using MFC today for other reasons than that they were using it before, and didn't get an opportunity to change..
There are a lot of good jobs out there for .Net programmers, so being able to handle some GUI framework in addition to C# and general knowledge about the .Net framework will be worthwhile.
When it comes to your points about being able to "deliver some performance like archivers, cryptographic algorithms, codecs" this really shouldn't depend on your choice of GUI framework. This kind of code will be writen in layers outside of the GUI layer, and will typically be bound to the GUI. With WPF you'd write your e.g. cryptographic algorithms in C# in some class independent of the GUI layer, and then the View written in WPF would bind to C# code and get its answer from here. However, if you used WinForms you'd still do the same thing, and the performance relies on the algorithms - not the GUI.
When it comes to getting started with WPF there are a lot of questions on SO helping with this. So you should find good help with a quick search.
Good luck!
Is there a pdf or video or some media that can inform me on how to program Winforms with C++. Obviously C++ is the most common programming language and I already have some prior knowledge. But when I try to find media about programming in C++, the examples are usually Console applications. I want some media that can teach me how to program Winforms in C++.
Here's a tutorial showing how to write Windows Forms applications in C++/CLI.
Just be aware that most samples tend to be in C#. Many people purposely use C# for the forms, C++ for their logic, and use C++/CLI to expose their logic as .NET assemblies (For easy use by C#/VB.NET). This helps, since the design-time experience is much nicer in C# or VB.NET for Windows Forms.
Bad idea, IMHO. Managed C++ is ugly; it was never meant to be a garbage-collected language. Its strength lies elsewhere. I recommend C# instead - similar syntax, highly marketable skill.
Preemtive snarky comment: all C++ is ugly.
Have you looked at the MSDN articles? I'm not saying I recommend this, but they do at least give a start.
As far as Seva Alekseyev's comment that all C++ is ugly: it's like the old comment about democracy being the worst form of government except for all the others. He's right that all C++ is ugly, but fails to mention that all the alternatives are even worse.
Just create a new C++ .NET project and start programming your C++. And additional syntax applies to .NET is managed pointers and .NET classes. Information about them you can find in MSDN, including lots of useful examples.
Well, there are opinions all over the place on this topic. My motto is always to use the right size hammer for the job-- and, in general, C++ is the wrong size hammer for making winforms. I love C++, but I only use it when there is an absolute necessity for speed of operations.
C# (or VB.Net, if you must) has MUCH better support for UI creation than C++, though I have noticed that Visual Studio 2010 offers some much needed enhancements to make developing Winforms easier in .NET 4.0. If you MUST stick with C++, look into obtaining a beta version of Visual Studio 2010. Otherwise, use C# as your UI, data access, file manipulation, general purpose language and C++ if you have to write a custom physics engine to go with it.
There has been a lot of talk surrounding the likes of WPF. I am wondering if WPF will become a new standard for graphical interactive user interface design. Is this where we are headed in terms of windows interfaces? Will it really take off like everyone says it will?
See also
Learning Windows Forms vs. Windows Presentation Foundation
(Contains links to many other useful posts on WPF).
I think there are plenty of applications still done in Win32, MFC and of course, WinForms. I think it would be a wise choice to add WPF to your tool belt. Should you drop everything and learn it today? That's up to you. I am seeing more demand for WPF. It's not overwhelming, but neither was C#/WinForms in 2001.
So the long winded answer is that you just have to take the chance. No one knows if WPF apps will dominate the market. I'm leaning towards the possibility and I'm also thinking Silverlight may be a real player in web apps moving forward. Since there are transferrable skills between the two, I'm hedging my bet a little bit by continuing to learn WPF.
Please see also Is it better to use WPF over WinForms
Sorry it's not a concrete answer.
You're asking us to predict the future :)
I think a better way to approach this is to look at the other technology you could learn if you didn't learn WPF. I would weigh the various tradeoffs and pick the one that was more valuable to me.
For instance if the choice was WinForms or WPF I would certainly go with WPF. WPF has a steeper learning curve than WinForms. However once you get past that learning curvie it is so much easier to work with. WPF can do in a few lines what took several hundred lines of a custom control in WinForms.
WPF is an ultimate graphic platform for Windows. Win32's GDI was a "first try", WPF is a "permanent structure". For the combination of Windows and flat displays (f.e. 3d displays might require something else), it will never be replaced. So learn it, it is a good commodity.
There is hell lot to learn in WPF. You need to die and reborn as a GUI programmer.
But is it worth the effort. Why?, Here is my answer.
Since you are asking this question, I assume you are Microsoft technologies based programmer.
As the direction of MS is towards WPF for GUI development, I see no choice. Win Forms will last long for probably 2 years more. Since the cool look and feel of WPF make users to ask for more and more WPF applications than Win Forms. As you know for many users GUI is the S/W :)
Now if you are non MS based programmer, probably from Java, I say WPF has lot of similarities with Java Swing. But it is a very-very big super set of Swing.
To have Swing catchup with WPF might take at least 2/3 years and by that time WPF might be ruling the word and I don't expect Swing to be much easier than this, if not difficult.
As silverlight is kind of platform independent and as it's model is similar to WPF, I predict WPF is going to rule at least for next 6/7 years if not a decade.
I believe and hope MS would make things much more easier for the programmers so that learning curve would be shortened or delegated to GUI artiists (using expression blend).
Hope I answered your question.
Microsoft has a habit of throwing everything in the wall and seeing what sticks... The Pocket PC platform, J#, and so on. With regards to WPF, it is too early to tell if adoption will increase in the future.
If you have programmed .NET Winforms and/or Webforms, the learning curve is not that steep. I would suggest dabble with it but don't throw all the eggs in the proverbial WPF (or even Silverlight) basket. As the others have noted, better to treat it as just another tool in your arsenal.
WPF has been around for a few years now and Microsoft's decision to rewrite Visual Studio (2010) in WPF is a good sign that it is here to stay. Remember, this is one of the most popular IDEs on the market and a sign of intent from the guys at Microsoft.
My organization adopted the technology last year and while it has a steep learning curve - you really have to learn to think in different terms - it has paid dividends in the richness of applications we are able to develop. I love winforms and am a big fan of asp.net but what blows me away about WPF is that you are provided with the building blocks and the possibilities are endlesss...
If I were you I would learn WPF for the experience and reap the rewards later. Don't forget - you'll also be learning the core of Silverlight if you adopt WPF - these are two technologies that in my humble opinion are going nowhere!
Using WPF is way better then WinForms and you need to have different mindset.
All I can say is Microsoft should have used HTML syntax when creating WPF and Silverlight applications so that front end coulde reused or at least for silverlight apps so that people that develope on Desktop could reuse the same code when writing browser apps that could be used anywhere.
If HTML5 becomes better I'm sure it will become popular as trend is toward open source (cheap technologies). No doubt WPF is far better for developing desktop apps then anything else I've used and c# is more powerfull as language (not speed) and how it's used.
Yes start learning it. It's applicable to Silverlight (though not a 1 to 1 mapping), it's also a very similar model to Abobe Flex's paradigm of MXML So you'll be getting 3 wins for the price of 1.
We're starting to see work come in that calls for it, so there's definitely a good reason to have it on the old utility belt.
I am begining to learn it Matthew MacDonald has writen a super book about it. I recommend that book to everyone (Infact I was surfing internet to learn WPF till I came across with his book and one more thing "stay away from Microsoft site (MSDN)"
Yes, if you will be designing desktop applications on the Windows platform, WPF is the emerging standard. WPF replaces the Win32 API that has dominated the Windows desktop until now, and Microsoft expects a similar lifetime for the WPF platform.
Besides, it's way cooler.
And then there is Silverlight, of course.
To be a 'silverlight' developer, is it basically asking for both programming and graphic skills?
Or is it just a matter of implementing the graphics into the silverlight project?
i.e. can you be a silverlight guru and yet not know heads from tails when it comes to graphic design?
To be a silverlight developer, you really only need to know a .NET language, event driven programming, and how to use markup for XAML. It's pretty simple really; the XAML describes UI elements (which can all be handled by the designer) which can then be used in code as a .NET object is created for each UI element.
Knowing graphic design is just a bonus.
If it's anything like Flash (and, from what I understand, the "finished products" can have similar capabilities), you don't necessarily need to be a designer. I'm part-flash developer and I don't have the first idea about anything related to graphic design :)
When I do flash programming, 99% of the work I do is in Actionscript. We have a couple of asset prep guys here who extract the visual elements and add them to a library, which us developers then use in the flash app.
Like I say, this is assuming there are some similarities between Flash and Silverlight (which, for all I know, may not exist). Good luck!
thats the power of xaml, both coder and designer can work in one language ;)
I've done a couple of WPF and Silverlight projects and I have terrible graphic design skills. You can certainly do Silverlight without having that type of skillset.
However, even though you can do some attractive work in those projects without having graphics skills it still very useful to have access to somebody that does have the skills.
For example, adding small animations to glassy-looking buttons can be entirely done by a programmer. But adding attractive backgrounds to form headers (other than gradients) is still better handled by a graphics guy. (In my opinion, of course)
It is not strictly necessary to be a good graphic designer, knowing how to develop .NET applications and XAML is sufficient. However, it's like drawing, all you have to do is to hold a pencil and move your hand, but if you have a good sense for art, the result will be better. Since in Silverlight your potential targets are Internet users and they're used rich user interfacese (maybe Flash based), if you know how to organize your elements, which are the best colors and things like that, your work will be easier.