Before You Ask

You're at work, coding madly under (yet another) crushing deadline. The code is due tomorrow, and it's working... mostly. Suddenly, something seems wrong. A function you're calling is crashing deep within the bowels of KERNEL32, three calls beyond the API you called. You check the documentation, and check your call. Everything looks fine. Even worse, it only crashes on Windows 98, not 95 or NT. This is strange. Very strange.

What do you do?

Doing Your Homework: RTFM and STFW

RTFM /R-T-F-M/ imp.
[Unix] Abbreviation for `Read The ****ing Manual'. 1. Used by gurus to brush off questions they consider trivial or annoying. Compare Don't do that then!. 2. Used when reporting a problem to indicate that you aren't just asking out of randomness. "No, I can't figure out how to interface Unix to my toaster, and yes, I have RTFM." Unlike sense 1, this use is considered polite.—The Jargon File

Well, you passed the first test: you re-read the documentation. One of the worst things you can do is immediately fire off a message to WinDev or another users' group, asking "URGENT!!! I'm getting a crash in a call to FooBrotz(). What am I doing wrong?". The nicer people who want to help will send you an email asking for more information anyway; the less-nice people will shake their heads and press the DELETE key, and the even-less-nice people might send you a blistering email questioning your parentage and inquiring as to in which cereal box you found your Computer Science degree.

When You Ask

How you phrase a question often is as important as what you ask. A terse, vague question with no sample code is likely to be passed over. Definitely include information about your compiler version, library versions, and runtime environment. Traditionally, you can do this with a simple one-line preface to your question like "Environment: VC++ 6.0, ATL 3.0, NT 4.0"

Sample code and reproduction steps are important. Nothing is more frustrating for a would-be answerer than to painstakingly try to reconstruct the problem from sparse information, just to learn later that the problem was caused by a typo in the original code. Try to reduce the code to under 20 lines if you can, but be sure to include enough context (variable declarations, setup calls, etc.) to give a feel for what is happening in your program at the time

If you've already tried several fixes, and they didn't work, tell us so we don't waste time telling you things you already know. If you've searched Google or MSDN and come up empty, tell us that, too, so we don't point you there. Writing about where you've looked and what hasn't worked so far also makes it clear that you've already put some effort into solving your own problem. We like that.

Off-Topic Questions

Would you ask your mechanic about a pain in your chest? Would you ask your doctor to change your spark plugs? Probably not. WinDev is primarily a list for questions about Windows Development, and most of the developers here focus on C, C++, and Visual Basic. Asking questions that don't pertain to Windows development using these languages is probably not your best route to a good, correct answer. Still, off-topic questions are usually tolerated by the list, within reason. We're pretty easy-going here. It's customary to prepend an off-topic subject with "OT:", as in, "OT: Need a good book on Python programming".

Of course, every rule is made to be broken, and we like a good non-technical conversation every now and again. There's a longstanding tradition on WinDev that off-the-wall, off-topic questions seem to happen on Fridays (probably because everyone is tired of programming Windows all week!). Feel free to join in, but still mark your question's subject with "OT:".

Introductory Questions

"I hesitate to respond at all, this is not an advanced question, and posts like this one have driven some very talented people away from the list...." —Mark McGinty, WINDEV, October 1998

When You Get Answers

"If my answers frighten you then you should cease asking scary questions."

—Samuel L. Jackson as Jules Winnfield, Pulp Fiction

So, you've researched your problem, posted a brilliant analysis, and the mail responses are flooding in. Hopefully, someone has exactly the answer you're looking for... but that's not always the case.

The Blind Leading The Blind

You might very well get answers to your question that are wrong. Sometimes laughably wrong. Go ahead and let the responder know that the answer doesn't work, or isn't feasible, or isn't possible to implement. Do it in a way that explains the problem, and not in a way that insults the person. After all, they went out of their way to suggest a solution, and if you can explain to them why their suggestion isn't a solution, you've helped them in the same way you wanted to be helped.

Right Answer, Wrong Question

Sometimes, people will misunderstand your question, and post something that seems completely irrelevant. Hold back on that reply button! Sure, if you're asking about a resource leak in the CPaintDC class, and someone tells you to make sure your monitor cable is firmly plugged in, they're probably a bit off the mark. But it might be that they just misunderstood the question, or it might be that you missed an important piece of context from your question. Go back to the original post, read over it again, and see if you can connect your question to their post. If you can, reply to the list and say why you think they're off—the respondent might know the real answer, but won't be able to tell you if they think they've already answered acceptably.

Bull's-eye!

It's customary to post a followup response some time after you've solved the problem. If someone had the answer you needed, thank them. This isn't just a matter of courtesy, but it provides closure for the question, and someone searching the archive years from now can be more secure that the response really did solve the problem. If the response didn't quite solve the problem, and you had to do some additional work to fix it, post that, too.

What if the responses were all wrong, and you fixed the problem on your own? Then definitely post a followup! Educate the rest of us—that's what this list is all about.

When You DON'T Get Answers

Alice sighed wearily. "I think you might do something better with the time," she said, "than wasting it in asking riddles that have no answers."

—Lewis Carroll, Alice's Adventures in Wonderland

Sometimes questions on WinDev are answered within minutes; other questions can take a few days before someone interested and knowledgeable sees the question, has time to research it, and posts a reply. If it's been three or four days and you haven't seen an answer, you can probably assume that you won't get one. Questions do go unanswered on WinDev for a number of reasons. Maybe the question was vague, or maybe no one really knows the answer to the question as you posted it. There are some things you can still do...

Twice Zero Is Still Zero

The second worst thing to do if you don't get an answer to your question is to post it again, unchanged. If a question doesn't get a response the first time, it probably won't the second time. The chance that several hundred people who are waiting to help you just accidentally deleted or overlooked your message is about the same as the chance of generating the same GUID twice in a row.

The worst thing you can do is to post it again, and prepend an indignant outburst like, "HELLO?! Is anybody out there?". True, this will probably get you a response of some kind, but probably not the kind you're looking for. Worse, it marks you as a whiner who isn't willing to think about why your question wasn't answered, and reduces the chance that someone will take the time to answer even a good question from you in the future.

Think About The Question

The first thing to do is to think about how you asked the question. Did you include enough detail? Did you include too much detail? Have you described what really happened? Frequently when you're in the thick of debugging a problem, and you're thinking in code, it's hard to make the transition back to natural language. It's easy to forget to add enough context to tell the recipient exactly what you're talking about.

So, go ahead and post again. But don't post a copy of the original question. Post a new question, one that acknowledges that you posted before and didn't get a reply, but sheds new light on the problem. You've probably tried a few things that didn't work — tell us about them. They'll tell us what not to suggest, and they might set us thinking in the right direction. Sometimes revealing what didn't work ignites the spark that will tell you what does.

Maybe The Well Is Dry

"I just find it interesting that whenever I post messages about htmlhelp, no one ever takes me up on my queries.
This is either...
1. sod off, find out yourself... (hope not!)
2. i don't know"
—Andrew Truckle, WINDEV, March 2001

There are some very smart people on WinDev. Unfortunately, it seems that omniscient programmers are few and far between, and none of them subscribe to our list. As a result, it's possible that we really don't know how to solve your problem. This is especially true if you're working in a specialized area of Windows (like DirectX, or HTML Help) that many programmers don't get to deal with in their day-to-day lives.

If this is the case, it still might be appropriate to post your question again, with some explanatory comments. Mention similar subsystems to the one with which you're working. Ask for pointers to other resources or books (but search the web yourself first!). And, by all means, if you do find the answer, tell us! Your answer will be assimilated into the Borg-like WinDev Archives, where future generations of Windows programmers can benefit from your hard work.

Acknowledgements

Thanks go out to the hundreds of people who have subscribed to WinDev and contributed over the years. Their questions and answers (both good and bad) have built a community. Special thanks to those who let me use their out-of-context comments as quips here.

Thanks also to Mark McGinty, whose excellent WinDev search archive was useful in researching past questions (and provided some of the quips for this article), and to Serge Wautier for his suggestions and comments on this article.