There is a naming convention to call the DependencyProperty xyzProperty for a property xyz.
Is this just convention or does WPF behave differently if that naming convention is violated?
If it's not just convention: Isn't C# used that way moving towards a scripting language like TCL where everything is a string?
Is this just convention or does WPF behave differently if that naming
convention is violated?
No, all code is compiled and Xaml parsed and linked so there is no difference in the resulting WPF. Feel free to name your properties in any way.
Coding conventions are simply to make all developers adhere to a system which may or may not lend itself to more maintainable code; hence its target audience is developers and not the end system.
If it's not just convention
I have been working professionally in WPF/Silverlight/WP Xaml since its inception and frankly have never come across that convention actually used.
Isn't C# used that way moving towards a scripting language like TCL where everything is a string?
No. C# is not moving that way because it was designed from the ground up to be procedural language and not a functional language. It may take in some things which give it a functional air, but it was designed as a procedural language and it cannot simply change its philosophy without abandoning a large chunk of its codebase to achieve that direction.
Related
I'm getting more and more confused in regards to C's supersets the further I venture into the programming world. There's just so many versions.. C, C++, C#, Objective-C, Objective-C++ and God knows what else.
I only know tidbits about these languages (some are object-oriented, some are procedural, C was originally developed for UNIX, C++ started as an extension and is used primarily on the Windows OS, Objective-C is primarily used on Linux and Mac OS/iOS, etc), but I'm not even sure that what I know is correct.
I would just like someone to shed some light on what I "know" - a little bit more information about which are successive versions, which platforms each are generally used on, which are the best versions to learn, etc if anyone is feeling generous. :)
Update
Also, I hope to eventually start native (without needs of plugins, such as the .NET framework) application development for Windows and Mac, so can anyone confirm that I would need to learn C++ for Windows and Objective-C for Mac?
C++ started life as "C with classes", in which Bjarne Stroustrup working at AT&T sought to add features like methods and inheritance to C structures in a way that requires as little support from a runtime library as possible. The classes added to "C with classes" are very heavily influenced by the Simula language. It's since grown to include a number of other features, some of the important ones being generics, lambda functions and an expressive standard type library.
Objective-C started life not too dissimilar from its current state, except that it was originally implemented as a C preprocessor. Brad Cox, at his company Stepstone, wanted to combine the power of the Smalltalk object-oriented model with the performance of C native execution. Objective-C uses a dynamic message-passing system to dispatch calls to objects, a design that's directly opposed to C++'s goal of doing everything in the compiler. Thus while objc and c++ start from the same base, the results are very different.
Both of the above language authors also published books explaining the design intention behind their respective languages. Cox's book is long out of print, but both are worth reading if you get the chance. Stroustrup's publications list
Objective-C++ relies on the fact that GCC (or LLVM) can generate code in either language, so the compiler writers allow you to use features from both in the same source file. There are some limits on what's possible at the boundary layer, and Objective-C++ is mainly used either to adapt a C++ library to an Objective-C app or to use STL or Boost data types from C++ inside an Objective-C class.
Finally, languages like C# and Java are not C supersets or C descendants at all. They use C-like syntax to provide some familiarity (and perhaps to avoid having to think about designing a de novo language syntax) but are different beasts that work in a very different way.
You're mixing up the name of the language and what that was meant to imply.
C was first, procedural and low level non-generic (at least not type-safe) as you may know.
Then C++ originated as C with classes, and templates. Later this evolved into something that sets itself apart from C more and more, expanding its standard library in each step. C++ is a multi-aradigm language, meaning it has stuff for procedural, generic, functional (a little) and object-oriented programming. Don't forget about Boost as a powerful extension to the Standard library.
Objective-C is a C expanded with numerous runtime facilities (like messages) to ease object-oriented development. Objective-C++ is the same extensions applied to C++, staying compatible as much as possible with the original language.
C# is something entirely different. Think of it as a hybrid between Java and C++, although that will set bad blood with users of all three languages. It has a garbage collector.
(Objective-)C used primarily on Linux is not entirely correct. All of KDE is C++, for one. C++ primarily on Windows isn't entirely true, the OS API is all C. What Microsoft made of a C++ API (MFC/ATL) is a living hell. Microsoft is pushing C#, along with associated .Net stuff a lot. So think of C# as mostly Windows, although there is ongoing effort to create a cross-platform .Net alternative (mono). Apple's Foundation APIs are Objective-C, but the underlying OS APIs are all still C.
"Supersets" is a wrong terminology. C is not a subset of C++. Both share a common subset. Only Objective-C(++) is a pure superset of C(++).
As to the best versions to learn: the latest, obviously, perhaps limited to the compiler support on the various platforms you will write for.
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.
I want to do RAD with C, but the only ones I can find only use C++.
Check out Glade, a UI designer for GTK+.
You may have to define what you expect when you use the term RAD. Technically is is a methodology agnostic of language (see http://en.wikipedia.org/wiki/Rapid_application_development, to understand what I mean).
If you mean "visual development" (which is the context in which it is applied to tools such as Delphi and C++Builder, primarily as marketing buzzwords and because Microsoft had already essentially trademarked "Visual" with respect to development tools), then use of C would require an application framework and tool to support this. There is a reason why such tools are usually implemented with object-oriented languages; it is a much more natural fit for GUI elements. This being the case, a tool vendor would be unlikely to choose C as the basis for such a tool.
Also it may be useful to understand what platform(s) you wish to target.
A judicious bit of Googling threw up a couple of things that may fit your requirements:
Auto-C
MGui
You may use BCX DevSuite Pro. It comes with GUI Designers that produces BCX code. When you compile BCX code, it produces also C code.
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 have a library written in C that I would like to use in an Objective-C app, either on the Mac or the iPhone.
Unfortunately, since this library is being written by individuals in the open source space, the documentation is quite sparse and incomplete. While I can figure out how to use the stuff in the library, I don't really have an overview of the entire code base.
What I would like to do is wrap the library up into some easily usable and transferrable classes in Objective-C.
Does anyone have any tips on how to approach this?
Any advice on the best way to get a visual hierarchy of how the library is structured?
How would I go about deciding how to best structure the wrapper for reusability and ease of use?
Any and all help will be greatly appreciated, thanks!
I've done this a few times myself. This can be fun -- it's your chance to fix (or at least hide) bad code!
You can use Doxygen to get a visual hierarchy of the code (although I've only used it for C++ libraries, it also works with C), or any of the other free tools out there.
Don't structure your wrapper class like the underlying library if the library isn't designed or documented well. This is your chance to consider the point of view of the user and how they are going to be using the code. Write your test cases first to figure that out, and/or talk to some people who use the library already.
Two nice design patterns that match up with what you're doing are Adapter and Facade.
First, remember: a C library is an Objective-C library. You don't actually need to do any wrapping at all, although you may want to if the library interface is especially cumbersome.
Second, if you decide that you want to write a library wrapper, keep it simple. Identify the core functions of the library that you actually plan to use, and think about how best to provide an interface to those functions and those functions only, with your intended usage in mind. Design an interface that you want to work with, then implement it over the library.
Since ARC (Automatic Reference Counting) was added to the Apple compilers and libraries, Objective-C and C are no longer so freely interchangeable. (Here's a list of ARC documentation and tutorials.) You need to consider the memory allocation issues much more thoroughly, and you might just want to "bridge" the libraries. See this SO question and some of the links from there, about how Apple bridges between Obj-C and C libraries.