|
Shog9 wrote: Chris could conceivably "autosave" the post you were writing, allowing editing to be resumed if unintentionally interrupted
Perhaps something similar to GMail. From compose window, you can click 'Discard' and then resume back by clicking 'Undo discard'.
|
|
|
|
|
Would it be possible to not remove the javascript events (onclick , onload etc) if the tag begins with < or are in the PRE tags?
Brad
Australian
- unknown PHP Developer on "Job Prospect"
Requirement: * Experience working with XML, XSL, XPath
Comment: and other things starting with X.
|
|
|
|
|
I've had a go at making it more intelligent. Your suggestion of inserting a comment inside the <onX tag didn't work because a comment inside a tag screws things up. Thank Bob for ö.
cheers,
Chris Maunder
CodeProject.com : C++ MVP
|
|
|
|
|
Seams when you search for "HTTP" (in Visual C++ forum) you get a lot of hits. Maybe the search isn't working with this keyword?
|
|
|
|
|
I suggest those two links be combined into one "Inappropriate" link at the bottom of messages.
Having two is just bad UI design and there are a lot of cases where it's just not clear cut which it is.
|
|
|
|
|
I agree. I've found myself wondering which one to choose.
|
|
|
|
|
If both links contribute towards getting the message removed, then I agree, we only need one.
|
|
|
|
|
The degree of reporting matters, I guess. Abuse might be intense and not tolerable. Spam, we got used to it and so Filter-And-Ignore.
|
|
|
|
|
|
It was either a mistake eg, they clicked the submit button twice. Or because they didn't get enough people answering the question or the answer they got wasn't clear.
|
|
|
|
|
Hello all!
www.codeproject.com is a fantastic web site. I am a fan of it. Sometimes I come cross to beautiful questions when I view the forums. However, it is difficult to follow up with answers for such questions. I wish there would be a button attached to posted message for saying "Follow up this" for a specific user (not the one who posts questions) so when I clicked it, I would be informed by emailing for given answers to these questions.
Wouldn't be nice to have such feature?
Thank you.
What a curious mind needs to discover knowledge is noting else than a pin-hole.
|
|
|
|
|
JUNEYT wrote: Thank you.
Care to explain the significance of the wtf smiley after your thanks?
|
|
|
|
|
I hope you are not bothered with it. Nothing special about it just represents how curious I am.
What a curious mind needs to discover knowledge is noting else than a pin-hole.
|
|
|
|
|
That sounds useful. Sort of like declaring yourself to be a "friend" of the OP.
|
|
|
|
|
Have you tried to bookmark any posts ? I think this will be the same.
"A good programmer is someone who looks both ways before crossing a one-way street." -- Doug Linder
coolestCoder
|
|
|
|
|
I think it would be helpful for authors to have the ability to add stickies to their articles' message boards.
This has been suggested before, and I believe Chris rejected the idea. However, I'd like to make the suggestion again.
Here are some uses I would personally use stickies for:
"How to get answers to your questions"
This would be a description of how to get questions regarding an article's content answered. Mainly, it would say that you should post your questions to the message board instead of contacting the author directly so that others may benefit, etc...
"Bug fixes"
A list of bug fixes to an article's code. This would be helpful as it can take some time to implement bug fixes, update an article, and its download. In the meantime, a list of bugs with possible fixes could be listed as a sticky.
"Interim updates"
Something like, "Hey, here is version 1.3 of my library. You can download it from my website. Consider it a beta. When it gets stable, I'll update my article here at Code Project as well as the download. Let me know if you have any problems."
"Faq"
Just a small faq about an article's content. Sometimes you get the same questions over and over. They get buried several pages deep in the message board. A sticky could put them front and center.
"References"
A list of other sources both here at Code Project and elsewhere that relate to an article's subject matter.
And I'm sure I can think of other uses. It would, of course, be up to each author to add these stickies and manage them. I know if I had this feature, I would definitely take advantage of it.
|
|
|
|
|
Hello Leslie,
This is my opinion, but all of those items you mention can easily be put in as sections within the article. I'd think people would spot that more easily than they would spot a sticky thread.
|
|
|
|
|
That was my first thought too... but you know, one of the problems with it is that once an article has been edited, there's no way to instantly slap a note on it. Stickies (and maybe one per article forum would be enough) would provide a nice stand-in while you're waiting for an editor to update things for you.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
|
|
|
|
|
Nishant Sivakumar wrote: This is my opinion, but all of those items you mention can easily be put in as sections within the article.
That's a good point. However, the sections I described can be volatile in that they change often. For example, you may get a few bug reports over the course of a month or two. Keeping track of them in a sticky would be nice rather than sending in an article update for each one. Then eventually you could update the article and sticky.
Nishant Sivakumar wrote: I'd think people would spot that more easily than they would spot a sticky thread.
Another good point. It can be frustrating, though. In one of my articles, I specifically added a section called "Dependencies" describing the assemblies my project depended on and which you would need to compile it [edit]and providing a link to those assemblies[/edit]. The very first message I get posted is someone complaining about not being able to compile the project because of missing assemblies.
I've since taken another approach to the dependency problem that I hope will solve it for good. I guess my point is that sometimes even if a problem is explained in the article, some people will overlook it. Stickies would be another way to communicate important info that will hopefully make the users' and author's life a little easier.
|
|
|
|
|
Nishant Sivakumar wrote: I'd think people would spot that more easily than they would spot a sticky thread.
My personal experience suggests otherwise.
I suggested the sticky post feature eons ago for exactly that reason, but it was rejected.
Cheers,
Vikram.
The cold will freeze our stares
We won't care...
|
|
|
|
|
I agree that stickies might be useful. However, I also agree with what Nish said - the examples you give should really be sections in your article, not tacked on as an afterthought. Maybe a more compelling example would get this suggestion onto Chris's ToDo list.
|
|
|
|
|
Hans Dietrich wrote: Maybe a more compelling example would get this suggestion onto Chris's ToDo list.
I think I've given it my best shot. All I can do is reiterate why I think stickies would be appropriate for the examples I've given. I'll go through them again:
"How to get answers to your questions"
Is this really something that should be in the article itself? Should an author address the problem of getting contacted privately regarding an article's content when it would be more appropriate if he/she was contacted through the message board? If so, I'll add a section to each of my articles stating it. It's an issue that needs to be addressed somewhere.
"Bug fixes"
Well, ideally an author doesn't get a lot of bug reports regarding their article and its code download, but it happens. Should an article update be sent in for every report and fix? Seems to me a sticky would be nice so that you could catalog them and eventually fix them in one update.
"Interim updates"
This is another one that seems perfect for a sticky to me. Currently, I'm in the process of rewriting one of my articles. It's taking some time, though; it's a long article and the new update represents a major change. However, I'm offering the updated code early so that users can get their hands on it in the meantime. I've posted this to my messageboard, but it's easy to miss because it's already got a couple threads above it.
"Faq" and "References" - well, here I can see how these would belong in the article. However, a sticky for these could be a work in progress. Something that an author can work on between updates and get feedback on. Eventually they'd find their way into an article.
I don't know what else to say. If this change represents a major inconvenience as far as implementing it, then I can totally understand that. But if not, I see no reason why authors shouldn't have this feature.
|
|
|
|
|
I have reconsidered this, and I now strongly recommend that this suggestion should be implemented, for two reasons:
1. it gives authors (and I'm assuming only authors will be able to create sticky posts for their articles) more control and better communication with the readers.
2. in some situations there is no substitute. Example: suppose your article's code depends on a third-party library, like boost. If you discover that a new release of the library breaks your code, you want to communicate that as quickly as possible, and let people know that you are working on a fix, work-around, etc., and when you expect to have a solution. In this case. a regular post might not be noticed, and of course is subject to scrolling.
Thanks for your persistence!
|
|
|
|
|
Hans Dietrich wrote: Thanks for your persistence!
You're welcome! And thank you for considering my viewpoint. You've made my day.
|
|
|
|
|
Remove the email link in every message that's posted. I'm not saying remove it entirely, just not on every message that's posted. We can still have the email link in the users profiles. This should cut down on the "unsolicited" emails we all keep getting from people who feel the need to suddenly move the discussions off the forums.
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|