We've had a number of complaints that a member will spend a great deal of time crafting a response to a question in Quick Answers[^] only to hit the post button and find the question was deleted or closed while they were answering it.
In a perfect world everyone would agree on what's suitable for answering and what's suitable for closing, but our world is far from perfect. Effective today we've added a feature that will re-open a question that's been closed if someone posts an answer to that question.
We could have implemented question locks, but locks are messy.
We've launched a small change to Quick Answers[^]. When posting a question you get the usual "Subject" and "describe the problem" boxes, but we've also added a "What have you tried?" box that must be filled in before you can post your question.
It makes it harder to post a question (barely) by forcing the poster to think a little about what they've done so far. It allows those answering to avoid things already tried and suggest new ideas. It will also, possibly, act as a self-identifier of those too lazy to explain their problem to those eager to help.
Thanks Chris, Its really good move. It helps questions to become more self-explanatory and avoid same solution that already tried by OP, Additionally it avoid spam post and lazy questions. Most of the time in CP, I have seen questions with title "Please solve it urgently" or "error in c# application" with same description as title. (though I tried to "IMPROVE" it but due to less description, it remains unclear)
Members should take its benefits and can improve the question quality to help them resolve quickly.
Finally "More time to explain question will help to reduce time to resolve it"
As far as the links are concerned (copy/pasting the link). I would recommend, instead of sending a request to get the title. You should leave that to server when poster is done editing the post to update the content of that link to a title (if from CodeProject). Like Markdown! It would make it a lot better. Plus, it would give you an opportunity to add link titles for posts from other sites by reading their <title> tag.
For example, just to edit this messages for you, I have sent like 15 requests with 1kb+ size. For me, it doesn't matter, but for someone with a metered connection, it does. This size also increases with the increase of characters. (Right now it is 2.3kb and growing for each request).
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
The reason we do Ajax calls for formatting is because we want to ensure the colourisation is done properly. We could simply skip the formatting, or use something like syntaxhighlighter to do some rough colourising. It's been discussed many times.
If you're worried about postback size then uncheck the "Show a live message preview as you type (not available < IE9)" checkbox in your Settings[^] (under the Forums tab)
With regret we've abandoned using CommonMark to render our messages.
CommonMark is meant to fix the issues inherent in other Markdown implementations while being true to the core ideas of Markdown. Basically: it should just work, there should be no surprises, and it should work with existing HTML. Markdown / CommonMark handles the main gruntwork of text formatting and when you need some fine tuning just throw in some HTML and you're good to go.
Unfortunately CommonMark handles PRE (i.e. Preformatted) blocks in a manner that simply doesn't work for us. A PRE block should (at least in my book) allow you to enter text and have the formating maintained as-is. On CodeProject we cheat a little[^] and allow things like B, EM and U tags for those who want to highlight sections of code, but beyond that what is entered is what appears.
In CommonMark a PRE block that contains text that is indented 4 spaces will trigger the creation of a <pre><code> pair that wraps the indented block as if it were a code sample. Code samples are often are indented, so whenever you paste code into a PRE block then you'll more than likely get nested PRE blocks.
This just doesn't work for us. We love what CommonMark is doing to provide consistency, but that's just seems an odd decision. For now we're disabling Markdown in Quick Answers and reverting back to MarkdownSharp.
This makes me sad.
We announced the introduction of Markdown[^] into the forums and Quick Answers a while ago, but we were never truly happy with the implementation of the Markdown processor in use. Ambiguities, lack of standards, and poor performance of the Markdown transformer were niggling annoyances.
The syntax is slightly different[^] to that of Markdown, but the changes are small enough that it should, hopefully, not cause any problems. As always if you do come across issues let me know and we'll season to taste.