Hello and welcome to the MSDN Visual Basic Language Forums.
These forums are both a Question & Answer system for VB.Net related questions as well as a Discussion board for VB.Net Language related topics.
The following three guidelines will help you both to create a thread that is likely to be read and responded to by the many talented community members who volunteer their services to help others, and to build a knowledge base of information from which others can learn and find answers.
You may also wish to visit the official MSDN Forums Help Wiki for additional information including how-to articles for using the forum interface.
Guideline #1: Create the correct kind of thread.
When you create a new thread (click the Ask a Question button) you have two options at the top of the Start a New Question or Discussion page. Be sure to select the appropriate option to either ask a question or to start a discussion. The difference is that "ask a question" enables the Q&A system allowing contributors to suggest answers and allowing you to close the thread when your question is answered. A Discussion is an open-ended conversation whose topic is not expected to have a specific answer.
When you create a new question, be sure to use the "Mark as Answer" link to close your thread after the question has been answered. There can be more than one post marked as answer in a single thread, so mark whatever posts directly answered your question. Always select at least one post as answer once you are finished with the thread.
You can also mark a post as helpful (whether or not is answers your question) by clicking the "Vote as helpful" link under the name of the person who made the post.
Guideline #2: Write a good post.
Writing a good post means that you first create a descriptive title for your thread. Never use titles like "Help Me" or "I Need Help" or "Please Help!!!" Always use titles that briefly describe the question at hand, or the topic to be discussed e.g. "Creating Controls at Runtime", "How do I draw and move a picture on my form?", "Looking for advice on how to (do something)". Never try to post your entire question in the title. Ensure that the title is brief and to the point.
At this point you could be done before you even write your question. As you move focus to the Body editor in the new post, the page will attempt to find links to other questions similar to yours. You should take a moment to right click and open in a new tab, or window, any links that look like they could be relevant.
If none of the suggestions help answer your question, then you can continue to use the Body editor to create your post.
When writing your post, be sure take the time to explain yourself as best you can, and edit yourself for punctuation and grammar. If people have to work very hard to decipher what you are trying to ask then they may misunderstand and answer something other than what you were asking, or they might simply give up and go look for a post that the user took their time to create. In this forum, you will often find that the level of effort you receive is directly proportional to the level of effort you put in.
Never use text-message abbreviations when writing a complete sentence (you can use LOL and the like of course, but don't make people try to read things like "c u l8r!").
Always include the message text of an Exception (error) if one is occurring in your code.
Whenever possible, try to include a brief example of the code in question. Always indicate which line or lines contain the problem or cause the exception. Always use the Insert Code button in the editor (looks like a box with lines and <> in it). Paste your code into the dialog that opens and select the VB Language from the dropdown at the top. If you find that blank lines are lost after you submit your post, put a space on each blank line in the editor before clicking the Insert button.
Guideline #3: Be polite and patient.
The vast majority of the contributors of this site are all volunteers who enjoy sharing their knowledge and helping others solve problems. While you will see Microsoft Staff (and Contingent Staff) from time to time, most of the replies to this forum come from people who do this because they want to, not because they are paid to.
Obviously being a jerk rarely gets you anywhere with other people. So there probably isn't much to say about being polite.
You should allow up to three days for a response to your question. The practice of "bumping" is discouraged and generally unnecessary as the site offers filters to view unanswered questions or questions with no response. If no one replies to your post after three days, consider editing the post. Make sure you've followed the guideline on writing a good post and try to add more detail if you can.
Never make duplicate posts or post the same question in different forums. When found, duplicates will be merged or deleted depending on the existing replies.
By following these three guidelines you can ensure the best possible response to your inquiry and can help to create a valuable repository of useful information.
If you have comments about, or suggestions for, this thread please start a new discussion titled "RE: How to Use this Forum" (or something similar) and provide your feedback.
Reed Kimble - "When you do things right, people won't be sure you've done anything at all"
Tuesday, January 08, 2013 11:44 PMModerator
- Edited by Reed KimbleMVP, Moderator Monday, May 27, 2013 1:25 AM add wiki link
I am not sure of the exact words to use but here are several ideas.
- Prepare your question. Think it through. Hasty-sounding questions get hasty answers, or none at all. The more you do to demonstrate that you have put thought and effort into solving your problem before asking for help, the more likely you are to actually get help.
- Have you read MSDN documentation of items relating to your issue.
- Specify version of Visual Studio and targeted Framework if applicable.
- After writing your title many times there are suggestive post you can check out provided.
- Post only relevant code as it relates to the issue at hand to assist with resolving a problem.
- When posting code please use the code button.
- If code spans files then consider uploading your project to SkyDrive, provide a link in your post.
Many years ago I found a document on the web that was for helping people write questions in forums such as this one. The information below came from this document. This document is fairly long with many more sections than listed below. If anyone would like a copy I can upload it to SkyDrive.
Be precise and informative about your problem
- Describe the symptoms of your problem or bug carefully and clearly.
- Describe the environment in which it occurs (machine, OS, application, whatever).
- Describe the research you did to try and understand the problem before you asked the question.
- Describe the diagnostic steps you took to try and pin down the problem yourself before you asked the question.
- Describe any recent changes in your computer or software configuration that might be relevant.
Describe your problem's symptoms in chronological order
The most useful clues in figuring out something that went wrong often lie in the events immediately prior. So, your account should describe precisely what you did, and what the machine did, leading up to the blowup. In the case of command-line processes, having a session log (e.g., using the script utility) and quoting the relevant twenty or so lines is very useful.
If the program that blew up on you has diagnostic options (such as -v for verbose), try to think carefully about selecting options that will add useful debugging information to the transcript.
If your account ends up being long (more than about four paragraphs), it might be useful to succinctly state the problem up top, then follow with the chronological tale.
Be explicit about the question you have
Open-ended questions tend to be perceived as open-ended time sinks. The people most likely to be able to give you a useful answer are also the busiest people (if only because they take on the most work themselves). People like that are allergic to open-ended time sinks, thus they tend to be allergic to open-ended questions.
You are more likely to get a useful response if you are explicit about what you want respondents to do (provide pointers, send code, check your patch, whatever). This will focus their effort and implicitly put an upper bound on the time and energy a respondent has to put in to helping you. This is good.
To understand the world the experts live in, think of expertise as an abundant resource and time to respond as a scarce one. The less of a time commitment you implicitly ask for, the more likely you are to get an answer from someone really good and really busy.
So it is useful to frame your question to minimize the time commitment required for an expert to field it — but this is often not the same thing as simplifying the question. Thus, for example, "Can you give me a pointer to a good explanation of X?" is usually a smarter question than "Would you explain X, please?". If you have some code that isn't working, it is usually smarter to ask for someone to explain what's wrong with it than it is to ask someone to fix it.
Enjoy lifeFriday, March 08, 2013 12:32 PMModerator
I am excited to announce the availability of the following FAQ paper which lists some of the questions frequently asked by the Visual Basic .NET General forum members. Although it’s far from complete, but this is the first attempt our forum support team has been trying to make to help development community members find the answers to their questions much easier and fast, and it’s always the top priority for our team to make the MSDN forum a good place for developers to ask questions, talk about technologies etc. With time goes on, this thread will be enhanced with more FAQs and content, so we really welcome and appreciate any feedback or suggestion on how to improve it.
On behalf of the whole forum support team, we owe sincere thanks to Deborah Kurata, Jamie Plenderleith, Rob Teixeira and Hector Minaya, who provided excellent and insightful technical review comments on this paper. And finally I want to thank all the Visual Basic .NET forum members who actively participate in this forum and help other.
ClickOnce and Setup Deployment
Reed Kimble - "When you do things right, people won't be sure you've done anything at all"Wednesday, May 22, 2013 3:15 PMModerator