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.
We have a VCL Delphi 2005 application, and would like to use DevExpress's XtraReports components, which is for .NET. Is it possible to use it without converting the VCL Delphi application?
Perhaps by converting the components as COM objects, or creating a WinForms application, and somehow embed the form into a VCL form?
Doesn't sound too easy, but just want to know what possible solutions are available.
Yes, its possible. You need to host the CLR from your Delphi app to do it.
There are some examples on MSDN on how to do this (the examples are using C++ though, so you would need to translate)
Or you could use the Jedi jclClrHost unit from the JEDI site. (see this question for some details)
Robo, you can use the RemObjects Hydra 3.0 components, to integrate Delphi and .Net technologies using plugins.
This is a bad idea. Yes you can do this. No you should not.
First look at Developer Express "Express Printing System", and Fast Reports. The first is a document/component print solution, the best one out there, and the latter is the best database reporting component set out there, which also handles non-database (code-based) reporting/printing with great flexibility and style.
I have first-hand experience using Express Printing System to print spreadsheet documents that are based on Developer Express Spreadsheet component, and the combination is very powerful, and easy to use. Both Developer Express and Fast Reports have very active development, and good technical support.
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.
i recently saw some videos on F#. it seems it used mainly for Service or Classes only? i see no "F# WPF" app in VS2010 Beta?
F# actually has some very nice constructs for creating event-driven UI applications, such as First Class Events, Object Expressions, calling property setters from a constructor e.g.:
new Form(Text="My Window Title", Width=600, Height=400),
and much else.
However, creating a forms designer in VS reqiures a CodeDom for your language. The current CodeDom architecture works great, as long as your language looks exactly like C# or VB; it does not lend itself well to generation of F# code (this from a webcast or interview that I can't locate right now). It also requires partial classes, which if I recall correctly, are not supported in the language as of Beta 1. Rather than focus on designer support in the first release, the F# team decided to spend their resources on enhancing other parts of the language, such as asynchronous and parallel programming, etc.
What this means is that you have at least 4 choices for creating UI in F#:
Write all UI code by hand, which is fine for simple apps;
Create your F# code as a library to handle the "hard parts," like asynchronous and parallel code, or computation centric code, and call it from C#/VB;
Create your UI code as a C#/VB library, and both drive it from F# and delegate event handling to F#; or
Use a DSL or Computation Expression (monad) to simplify building the UI by hand (just discovered this while looking for other links in this answer).
Of these, calling a C# UI library from F# may be the most flexible while still retaining a familiar paradigm. But, using computation expressions for quickly building UI by hand is certainly worth looking at.
You can certainly create GUIs in F# - it's just another .NET language, after all.
Tomas Petricek's book, Functional Programming for the Real World (which I've helped out with a little bit) has various GUI examples. The source code is available to download if you want to see examples.
Admittedly some aspects of GUI programming don't map terribly well to a functional style, as there's a lot of mutation involved, but there are ways and means around that :)
With F# 3.0 and the XAML type provider it's possible to create a WPF designer for F# in Visual Studio 11. See http://www.navision-blog.de/2012/03/22/wpf-designer-for-f/
We sell a commercial library called F# for Visualization that is written in 100% F# code and uses WPF to provide interactive graphics with typeset mathematics from your F# code:
(source: ffconsultancy.com)
So it is certainly possible to write GUI apps in F# using WPF.
It is a .NET language, so it can use the .NET class library. Which means Winforms, WPF or anything else you might use in C#.
Updated according to the link by James Hugard
For now F# will not be used much for GUIs because it is not the most important use case for it. From Don Syme's blog:
In this first supported release, our aim has to be to focus on the core strengths of F# for exploratory programming with F# Interactive, programming with data and implementing parallel and asynchronous components.
Although you can theoretically use F# and the standard GUI libraries if you need a GUI you should use VB or C#:
F# users should use the Visual Studio designer tools to generate C# or Visual Basic code and incorporate those components into their F# applications.
In the longer term "presentation-oriented designer tools that generate F# code" are, according to Syme, "definitely feasible".
Of course you can use all the WPF classes from F#, too. You can create Windows, controls and everything else from F# and I also sometimes use it from the F# console.
It's not as tightly integrated into Visual Studio as C# or VB yet, but as you can see in the comments, designer support in the future is feasible. I guess we'll have to wait until then (or use other tools).
At the moment I'm developing a web based application using Silverlight 3.0. For the business rules I'm looking for a rules engine that's both easy to use for me and my users, which will work with SL3. Is something like that available out of the box or will I need to roll my own?
I've Googled and looked around the various code sites (Codeplex, Code Project etc), but didn't see anything that suits my needs.
I did also have a good long look at NxBRE, but it's Rules syntax is too complex for 'dummy' users.
What about the rules engine that comes with Windows Workflow Foundation?
http://blogs.microsoft.co.il/blogs/bursteg/archive/2007/08/09/WF-Rules-Engine-without-Workflow.aspx
For people who stumbled upon this thread looking to use NxBRE as a Rules Engine with Silverlight (SL), here is my two cents.
I tried referencing NxBRE dll in my SL project with no luck. SL does NOT allow dlls that are not built using SL CLR to be referenced in an SL project.
Fortunately NxBRE is an open source project so I downloaded the source files to build it using SL CLR.
SL does not support a lot of .NET types, namely objects in namespaces System.Xml.XPath, System.Xml.XPath etc. These are required for NxBRE to compile.
So I had NO luck using NxBRE with SL. These are my first impressions, if I find more by digging deeper I shall let you guys know.
Hope this is of help to someone out there.
Thanks
Sai Gudigundla
I've searched around a bit more, and decided that Rules Engines actually don't fulfill our requirements. We don't need rules, we want to do calculations on a property when the value of that property changes.
Thanks for your answers,
Cheers,
Frances
For those who might be interested: eventually we went for CSLA .Net for Silverlight
Back to the original rule engine question...
If you want to run the rule engine inside of Silverlight, you would need to find one that has been built to only use the limited subset of .NET that Silverlight supports. For example, Silverlight supports generic collections (List) but not untyped collections (List).
At this moment, I don't know of a .NET rule engine that has been (re-)targeted to the Silverlight CLR.
Furthermore, while there are interesting applications for client-side rule engines (for example: in the browser or on a mobile device), one should always consider whether the rule engine is more appropriately hosted on the back end. Take into consideration how frequently the rules are called, how much data is being moved around, etc.