The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
1. The lounge is for the CodeProject community to discuss things of interest to the community, and as a place for the whole community to participate. It is, first and foremost, a respectful meeting and discussion area for those wishing to discuss the life of a Software developer.
The #1 rule is: Be respectful of others, of the site, and of the community as a whole.
2. Technical discussions are welcome, but if you need specific programming question answered please use Quick Answers[^], or to discussion your programming problem in depth use the programming forums[^]. We encourage technical discussion, but this is a general discussion forum, not a programming Q&A forum. Posts will be moved or deleted if they fit better elsewhere.
4. No politics (including enviro-politics[^]), no sex, no religion. This is a community for software development. There are plenty of other sites that are far more appropriate for these discussions. Or if you must, use the Back Room[^] - but enter at your own risk.
5. Nothing Not Safe For Work, nothing you would not want your wife/husband, your girlfriend/boyfriend, your mother or your kid sister seeing on your screen. For those discussions where you wish to be a little more frank, use the Soapbox[^]
6. Any personal attacks, any spam, any advertising, any trolling, or any abuse of the rules will result in your account being removed.
7. Not everyone's first language is English. Be understanding.
Please respect the community and respect each other. We are of many cultures so remember that. Don't assume others understand you are joking, don't belittle anyone for taking offense or being thin skinned.
We are a community for software developers. Leave the egos at the door.
Charles Petzold is sometimes known for producing large and wordy tomes. I started with Creating
Mobile Apps with Xamarin.Forms, and several days later am only on chapter 9 of 27, and all he has done is basic hello world apps, and written a million words the Xamarin student must wade through, discussing how great XAML is.
Any recommendations for a book to quickly get up to speed producing mobile, especially Android, apps using Xamarin would be most welcome.
"'Do what thou wilt...' is to bid Stars to shine, Vines to bear grapes, Water to seek its level; man is the only being in Nature that has striven to set himself at odds with himself."
I've been building native Android apps (using Xamarin) for a little over a year now. The productivity and ability to share code using C#/VS is awesome! Apart from a foray into Xamarin Forms about 2+ years ago, I decided to stay away from it for a while. Instead, I focused on learning the Android platform, which I did by reading most of this book before writing a single line of code:
Orange you glad these fruit puns exist? The shear number of them is kiwi-ng me. Dragon fruit through the bottom of the pun barrel is plum useless, but gives you apple time to think of more.
Thats what I got, Peach Out y'all.
Reason I Hate Microsoft Of The Day: I'm tasked with building Windows 10 system images for our new hardware platform. This means using Microsoft's "Windows Assessment and Deployment Kit", which is Windows 10's collection of command line tools for building images. The command lines in question are can be 200 characters long, with option names often 30 characters or more.
That's not my reason to hate Microsoft.
I hate Microsoft today because they can't issue a simple "File not found" message. Nooooo, they issue a dozen or more messages, liberally laced with things like "Error code: 3" and random HRESULT's. I wasted a f***ing hour trying to figure out why a command wouldn't work, when the simple problem was I'd missed a character in a file name.
The Deployment bastards are working hard at taking the Device Driver group's number one slot on my list of developers-first-against-the-wall-when-the-revolution-comes.
Microsoft's error messages have always been a pain.
Not exactly always - .NET handles exceptions quite nicely.
The COM error system, on the other hand, was a very bad joke made in the poorest of taste. A horrible, horrible, horrible thing! Quite possibly, the single worst error handling mechanism ever inflicted on mankind.
And it's still out their lurking in little (and sometimes not so little) corners of Windows - every time I see that dread string "HRESULT", my heart sinks because I see a trainload of grief approaching.
Have you ever written an installer for a device driver? The WDK docs describe three different, mutually exclusive ways to do it. The correct way is the fourth one. The whole thing is an abomination before the deity-of-your-choice.
Our history with Windows device driver development was sufficiently traumatic that all of our current custom hardware is built as single-board embedded computers that talk to our Windows-based controller via Ethernet TCP/IP. No Windows drivers, no awkward I/O constructs, vastly fewer undocumented rules that must not be broken.
I fault Microsoft for the necessity of typing command lines that are hundreds of character long.
I also fault their oh-so-detailed error messages that are effectively meaningless because of the barrage of worthless information that fails to address simple use cases. Don't give me random numeric error codes, and don't display HRESULT's. Stupid morons don't even use their own mechanisms for turning such things into meaningful text.
This is a toolset that's handed out to thousands of OEM's. If Microsoft is so all-fired worried about people doing this correctly, after 30 years there has got to be a better way than a mish-mash of command line garbage.