Hank Emery wrote:
Stevens Miller wrote:In your Character interface, how do you specify what/who is being attacked?
AH! attack should have a parameter. Thanks for the correction.
Here's the XAML that defines those Buttons:At Line 10, I have again used my crude trick of embedding a DOS newline in the text. The first Button displays the two lines, left-justified. Note, however, that the "equivalent" XAML at Lines 12-14 doesn't work. The second Button is back to using one line. So, the newline "method" is not recommended. Here's where we stop using text as the content of a Button altogether. For the third Button, defined at Lines-16-21, we replace the text as the Button's content with a StackPanel element. Nested inside that, we include two TextBlock elements as the StackPanel's content. Finally, the content (somewhat confusingly set with the "Text" property) of those TextBlock's is set to the original two lines of text we used in the previous Buttons. The result, in the third Button down from the top, is the left-justified text we had in the first place. To center it, we simply add the HorizontalAlignment property to each TextBlock and assign the value of "Center." That's how the fourth Button is defined at Lines 23-28 (with the TextBlocks at Lines 25 and 26). Note that quite a wide variety of elements can serve as the content of a WPF Button, beyond text and TextBlocks. For example, the fifth Button is defined by Lines 30-32. Its content is an Image element, the source of which is actually a URL, with the image file residing somewhere on the Web. The wisdom of using Web resources for UI controls is debatable, but Line 31 does, I think, a striking job of illustrating how far a WPF Button's contents can be from plain text, and how easily the required XAML code can cross that distance. Note also that this post, which I have originated in the Visual Basic forum, contains no Visual Basic. As per the WPF design goal of being usable in all .NET languages, the XAML here would work just as well in, say, a C# context as it does in a Visual Basic context (hence, I am adding the C# forum to this posting). I'm reading Adam Nathan's "WPF 4.5 Unleashed," which is an excellent guide to WPF and XAML. (Its example code is all in C#, but there seems to be little effort required to mentally translate that into Visual Basic, especially if one already knows C/C++ and/or Java.) I'm not usually a fan of the "Unleashed" books, as their editorial style is often a bit unfocused, I feel. This one is different. If you are looking for a book on WPF, this is the one you are looking for. More soon...
Where did you see that, Claude? As I recently posted in another thread in this forum, it tends to be easy to find someone, somewhere, who will tell you that whatever language/operating system/toolkit/framework you are using is dead when it's actually thriving. Try Googling "Java is dead" and you'll see what I mean. But, as I also conceded in the same comment, Microsoft does have a tiresome tendency to announce "no further enhancements will be made" regarding lots of their current technologies. Over the many years I've used Microsoft products, I've just learned to live with it. Regarding C# and Visual Basic as alternatives, this paragraph from Wikipedia is interesting:
Claude Moore wrote:I've read that Microsoft isn't going to evolve Visual Basic further, is that true ?
An Infoworld article by Paul Krill supports the above. It might be noteworthy that Krill's article was written in 2009, and refers to Visual Basic 10 and C# 4. The latest Visual Studio lists these components when you click "Help / About Microsoft Visual Studio:"
Wikipedia wrote:C# and Visual Basic .NET are Microsoft's first languages made to program on the .NET Framework (later adding F# and more and others have also added languages). Though C# and VB.NET are syntactically different, that is where the differences mostly end. Microsoft developed both of these languages to be part of the same .NET Framework development platform. They are both developed, managed, and supported by the same language development team at Microsoft. They compile to the same intermediate language (IL), which runs against the same .NET Framework runtime libraries. Although there are some differences in the programming constructs, their differences are primarily syntactic and, assuming one avoids the Visual Basic "Compatibility" libraries provided by Microsoft to aid conversion from Visual Basic 6, almost every command in VB has an equivalent command in C# and vice versa. Lastly, both languages reference the same Base Classes of the .NET Framework to extend their functionality. As a result, with few exceptions, a program written in either language can be run through a simple syntax converter to translate to the other. There are many open source and commercially available products for this task.
Right at the top there you can see both Visual Basic and C# designated as their 2017 versions. I suppose Microsoft could just renumber the same old program with every release of Visual Studio, but I doubt they'd do even that much if they wanted to put a language out to pasture. It is also interesting to compare the historical ranking for C# with the historical ranking of Visual Basic. C# ranks a bit higher, but has trended downward since its peak in 2012, while Visual Basic has trended upwards over the same span of years. (Not that the Tiobe index is conclusive, but it is interesting.) I think Les's characterization is quite apt. Back in the '80s, a computer researcher I knew predicted that, "eventually, all languages will converge to something like C." Being a long-time C fan, I tried C# first, when I was recently motivated to look for an all-Microsoft way to get something done. (Mostly, I write in Java and use the JNI when I need something specific to Windows that Java can't do on its own. This time, I needed to avoid relying on there being, or having to install, a Java Runtime Environment on my users' machines.) I was kind of surprised by how much if, at least upon my first glance, did not look like C. In particular, I saw some stuff in square brackets that kind of put me off. Having learned Visual Basic long ago, I looked at that again. Imagine my surprise to discover that, since my last go-round with it (when it was still called Visual Basic 6), it had become a truly object oriented language. While it is true that Visual Basic does not use curly brackets, nor end a statement with a semicolon, I'm pretty much finding that its current form makes writing the Visual Basic equivalent of a Java method mostly a matter of looking up the comparable keyword. (I posted a handy cheat-sheet that illustrates how much the two languages have grown alike, grammatically if not syntactically.) So, it appears that, for now, whether one uses C# or Visual Basic is a matter of personal preference, there being no capability unique to either. And, as far as I can tell, Microsoft remains equally committed to both for the foreseeable future (which, when we are talking about Microsoft, maybe only be about twenty minutes, but that's how it is for both languages.) Hope you'll post here often. New forums need new input!
Stephan van Hulst wrote:Cool, thanks Stevens!
XAML is the main reason I have not strayed from old Windows Forms applications yet.
I think Visual Studio's Forms designer is also much friendlier than the WPF designer. When I eventually have to bite the bullet, I'll come back to these posts.
I also still need to get into JavaFX, after being intimately familiar with Swing.
I really dislike having to learn all these new presentation layer technologies.