@NerdyWoman: Yep, I loved WordPerfect's tag system back in 1989-1992-ish (painful to say that) and it did help the mental transition into HTML.
11 hours ago, NerdyWoman wrote
I understand that XAML is used to define the elements on the page
... I'll be nit picky for a moment in order to reinforce this important concept: XAML doesn't inherently have anything to do with with defining elements on the page. However, when used with an API for building user interfaces like WPF, it can be used to create instances of classes defined in the given API and set their initial properties. Again, just want to make sure we've got that nuanced idea cemented.
11 hours ago, NerdyWoman wrote
... but it doesn't actually instruct the elements to act or respond to user actions in any way... that's what the code page is for.
Correct, XAML can only create instances of classes and set initial properties. If you need more logic to control the given user interface API or respond to events that are triggered by the user or the system (page load, button click, timer, etc.) then you will use imperative C# or VB code in the "code behind" that is associated with the declarative XAML code file. How are the two associated? The "main page" file that you see in the visual designer and the "code behind" file are two parts of a whole ... they are both partial classes and will be turned into Intermediate Language (IL) by the compiler ... the two files of code combine together to define a new class that derives from the Page class.
11 hours ago, NerdyWoman wrote
Being a newbie at this, I'm still not sure I understand about APIs. Does WPF (as an API) enable some procedures/events to be written on the main page vs. a code behind page?
Good question! API == Application Programming Interface. It's a fancy term used for years and not specific to .NET. Simply put ... an API is a collection of classes with properties, methods and events that someone (in this case, at Microsoft) creates with the intent that it will be used by other developers. You could also call an API a Library, like the .NET Framework Class Library, an important component to every .NET application. Just a library of functionality you can borrow from.
APIs hide complexity thereby making it useful to other developers. All of the down-n-dirty implementation details are hidden behind a public "interface" ... in this case the term "interface" consists of some classes, some properties, some methods, etc. that are made public (so that other developers reference and use them in their code). Meanwhile deep down inside the code of the API some classes, properties and methods are made private (because they do important stuff that the original developers don't want anyone fiddling with). This is the notion of Encapsulation in Object Oriented Programming.
API's usually encapsulate important work that is common to everyone, not just to your specific "problem domain" (business need). However, suppose you work at an accounting firm and want to create an API that handles tax calculations for all states. That would be a good re-usable component that could be documented and utilized by other developers in your organization. That's a great example of an API ... albeit, one that you probably don't want to share with the world because it is specific to just the developers in your organization. Still, it's "standardized", documented and hopefully other developers can learn how to utilize it within their apps.
In .NET, there are APIs for everything ... data access (ex. ADO.NET API), web development (ex. ASP.NET Web Forms API), web services (ex. Windows Communication Foundation, the WCF API) ... IN FACT there are MULTIPLE API's created by Microsoft to do the same basic job ... as you can see, the Windows Presentation Foundation (WPF) API is one way to create a Windows application ... there's also the Windows Forms API, Windows Store API / WinRT API, Windows Phone API, etc. Competing APIs are created to give developers options on how to approach a problem, which technologies can be used. They are split up into their own APIs to reduce complexity and application size.
Some APIs have "sub API's" ... for example, the ADO.NET API has a popular sub-API called the Entity Framework API. Inside of *that* API, there's other sub-API's ... LINQ to Entities, the DbContext API, the Change Tracking API, the Validation API ... again, these are conceptually different aspects of a larger set of functionality. They may even be deployed in the same physical .DLL file (more about that later) but can be referenced conceptually as a distinct set of classes, methods and properties used to accomplish some sub-feature of a larger feature set. Simply put, a sub-API is just a way to talk about a sliver of the overall functionality ... it's just a label that describes a conceptual boundary around some classes so you can isolate and talk about those since they were intended to work together.
API's rarely have user interfaces themselves. They are just literally libraries of code that can be leveraged by other developers. They may be used to CREATE user interfaces, but you couldn't just run an API on it's own ... there would be nothing to see. It needs YOUR CODE to drive it to do something meaningful like "print a form to screen" or "print a button to screen" or "respond to a click event" or whatever.
In the .NET world, API's are usually packaged into one or more assemblies. An API is the more conceptual way to refer to a a .dll Assembly file. You add a reference to a .dll / Assembly in your Visual Studio Project as a means of accessing the API. All .NET applications reference the core .NET Framework Class Library, and some Project templates add references to other .dll Assemblies depending on the type of application you're creating. This is a shortcut made simply by choosing
API's also are versioned and there are important rules around how to properly version them so you don't remove or change functionality in one version of the API that developers depend on in their applications. The words "breaking changes" are considered an anathema.
I think I've literally told you everything I know about the term "API" ... except to answer the last bit of your question:
Does WPF (as an API) enable some procedures/events to be written on the main page vs. a code behind page?
Well, no ... not exactly. I mean, XAML is really just used to create instances of classes in a given API and then initialize the properties of that new instance. It can WIRE UP an action to an EVENT HANDLER in the code behind, sort of like:
<x:Button ... onclick="myButton_Click" />
... it can't actually handle the event when it happens. It must defer to the imperative C# or VB code in the code behind file since it can be used to write logic to define what happens next. So, it's not a limitation or restriction of the given API per se, it's more a matter of what each language is equipped to do. Like the video I referenced, you COULD create an entire WPF app exclusively in VB or C#, HOWEVER it would become laborious. You don't NEED XAML. XAML is merely a short-hand, a short-cut both mentally for those of us who think of layout in terms of tags, and in terms of the actual number of characters you need to type to achieve similar results (i.e., creating a new instance of a Page class, adding to that class an instance of the Grid class and setting all its properties, then adding as children to the Grid class instance new instances of buttons, stack panels, etc.) That would take FOREVER and you wouldn't be able to see the results in a friendly designer at Design Time. You would have to F5 Start Debugging the application to see each little change you wanted to make. So, XAML, as used for layout against the WPF API or what have you, is merely a convenience. Not a requirement.
Hope that helps?