Guidelines Thread

WaltP · #1 08-Jul-2006, 21:52

Thanks to fhj52 for taking the time to respond...

Quote:

Originally Posted by fhj52

@WaltP
Since you asked, as one also a new member here, I suggest adding "BEFORE POSTING," in front of the "Read This" .

The "Read This >>> Guidelines for posting requests for help -"
could be:
"BEFORE POSTING, Please Read This Post! "

Thanks -- I'll pass this on to the moderator...

Quote:

Originally Posted by fhj52

The additional info "Guidelines ...blah.", as helpful as it might be to some, will actually cause others NOT to read it. Some people think they already know the rules so will ignore it.

(ithink the red&yellow colors & bold are good but I cannot repo that here...)

True. Many people just know too much -- before they find out otherwise

Quote:

Originally Posted by fhj52

Also, in the Guidelines text body, perhaps a short example(shorter than this!) of what the tagindicator is and why it is might help.
...
OF COURSE you will want to use a shorter example. That just happened to be some that I was looking at recently...

Good point, but we do want to keep the text a short as possible. Adding examples will IMO deter people from reading the info because of the length of the post.

Quote:

Originally Posted by fhj52

The KEY part seems to be that you need to state:
"REPLACE the "CODE" word in the code block tag with the appropriate language tag: C/C++/CPP, JAVA, CSS, etc... "
Because that is what you really want, correct?

Yes...

Quote:

Originally Posted by fhj52

Part " 1.A.d. " lists the code types but apparently c, c++, and cpp are all the same so the statement " using c, c++ or cpp are all the same " might be worthwhile.
Also, that seems to be missing XML and related... Is there no parser for XML and associated types? What about PERL or other languages(BASH, etc...)?
IOW, the list of language types should mention those that are not supported and what the poster should do when posting one of those other types of code.

Why clutter up the post with unnesessary info. If you're using C you'll add the C tag. C++ you add the C++ tag. When you figure out the tags are the same, use whichever one you want...

As for missing parsers, we don't have a forum for XML, PERL, BASH.... Don't need a parser... Use CODE.

Quote:

Originally Posted by fhj52

And, PHP and HTML already have code tags to be used so that info, in part 1.A.d., is not needed, right? That makes it confusing: ' does one do what Walt needs or use the built-in tags? ' If you do want people to use the built-in tags, then say such; if not then state that too.

Yes it's needed, to explain that tagindicator is to be replaced with one of the appropriate codes. Otherwise people add [tagindicator] around their code. I kid you not! I may have missed your point here.

Quote:

Originally Posted by fhj52

As you might know, people tend to take the shortest route possible which means putting an extra, non-clickable tag requires effort and forethought. Some might forget the tagindicator too since preoccupation with the problem is quite likely.
So, perhaps modify the bar to add that to the "tagindicator" code block as part/one of the clickable elements. The HTML and PHP widgets are there so C, C++, XML, etc... could be there too. A drop-down selection box would be nice...

This has been discussed but has not been implemented AFAIK. We had a problem coming up with a keystroke for C/C++ since Ctrl-C is already taken.

As for forgetting, Guideline 3 solves that problem quite nicely...

And you mention "non-clickable tag requires effort and forethought" -- we have to read their post and if we can't read it easily, is it OK to ignore the post? Forethought: "I want a response, so I'd better make my question as readable and understandable as possible." Maybe?

Thanks for the time and the thoughts. You have some good points.

cable_guy_67 · #2 09-Jul-2006, 20:01

Quote:

Originally Posted by WaltP

Thanks to fhj52 for taking the time to respond...

Quote:

Originally Posted by fhj52

@WaltP
Since you asked, as one also a new member here, I suggest adding "BEFORE POSTING," in front of the "Read This" .

The "Read This >>> Guidelines for posting requests for help -"
could be:
"BEFORE POSTING, Please Read This Post! "

Thanks -- I'll pass this on to the moderator...

I like the idea of reworking the "hook" text. If anyone wants to weigh in with any other suggestions for this please do. I'll give anyone a week for this purpose before making the next set of changes.

Quote:

Originally Posted by WaltP

Quote:

Originally Posted by fhj52

And, PHP and HTML already have code tags to be used so that info, in part 1.A.d., is not needed, right? That makes it confusing: ' does one do what Walt needs or use the built-in tags? ' If you do want people to use the built-in tags, then say such; if not then state that too.

Yes it's needed, to explain that tagindicator is to be replaced with one of the appropriate codes. Otherwise people add [tagindicator] around their code. I kid you not! I may have missed your point here.

Quote:

Originally Posted by fhj52

As you might know, people tend to take the shortest route possible which means putting an extra, non-clickable tag requires effort and forethought. Some might forget the tagindicator too since preoccupation with the problem is quite likely.
So, perhaps modify the bar to add that to the "tagindicator" code block as part/one of the clickable elements. The HTML and PHP widgets are there so C, C++, XML, etc... could be there too. A drop-down selection box would be nice...

This has been discussed but has not been implemented AFAIK. We had a problem coming up with a keystroke for C/C++ since Ctrl-C is already taken.

Walt's not kidding. At least when someone uses the [tagomdicator] incorrectly we know they made an attempt and really did read the Guidelines Sticky. I'll discuss this with Admin to perhaps get the buttons added to the editor. I won't promise anything but I realize that when someone uses the [php][/php] indicators in the c or c++ forums it's because they most likely used the button in the editor.

Quote:

Originally Posted by WaltP

Thanks for the time and the thoughts. You have some good points.

I second that thank you. While many people may just ignore it even if it said, "Free Money inside" enough do read it and it shows in their postings. Some members here are more likely to help if they don't have to sort out what is going on in a long, unformatted bit of code that was demolished by not being wrapped in tags. Any and all efforts to help that along are most appreciated.

Chime in anyone if you think you may have some ideas to help this along. Next weekend I'll sum things up and get the changes applied.

Mark

fhj52 · #3 10-Jul-2006, 12:10

Thanks for being so considerate. It is difficult to make suggestions because one never knows how they will be construed. Mine are always _suggestions_ and only that because I recognize that there are always factors that I may know nothing about. Just trying to help where I can. blah...

Anyway, the reason I post now is because after chiming in on the other thread, which has been moved here, I was looking for "Forum Rules" (found, sort-of: in "FAQ") and found an old post called, coincidentally, "Guidelines". Location:
GIDForums > Site Info and Feedback > GIDNetwork™ > GIDForums™ > Guidelines
( Started by WaltP 23-Nov-2005, last post in December '05 ... until last week, anyway.

)

I made some more specific suggestions when I found it:
http://www.gidforums.com/showthread.php?p=46331#post46331

Perhaps this new "Guidlines" thread and the old one should be combined, don't you think?

c-ya

fhj52 · #4 10-Jul-2006, 12:46

Quote:

Originally Posted by cable_guy_67

[snip]
I'll discuss this with Admin to perhaps get the buttons added to the editor. I won't promise anything but I realize that when someone uses the [php][/php] indicators in the c or c++ forums it's because they most likely used the button in the editor.
[snip]

Would not ask for more. Thanks.

...
In general, I agree that the key to getting information across is to as brief and to the point as possible but when that does not work, visual example(s) usually do.
Since there has been confusion, a brief "Hello World!" example might alleviate the necessity to keep explaining the issue.
[e.g.]

Properly formatted & parsed code will look similar to this:

CPP / C++ / C Code:

main()  { 
    printf("hello, world"); 
}

but not this:

Code:

main()  { 
    printf("hello, world"); 
}

The appropriate title on the code, "CPP / C++ / C Code" in the above example, is really important for anyone that might want to assist you. The forum will automagically add that for you by just using the correct tag.

[/e.g.]

Or if that original K&R code just plain sux,

, take your choice from here: http://www.gnu.org/fun/jokes/helloworld.html

If you want to use some other language, try here, http://en.wikipedia.org/wiki/List_of_hello_world_programs, where there are over 200 "Hello World!" code examples.
I like this

CPP / C++ / C Code:

#include <stdio.h>

int main(void)
{
   printf("Hello, world!\n");
   return 0;
}

but it does take up a few(4) more lines of space.

c-ya

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Rate This Thread
Rate This Thread:

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Thread	itch	C++ Forum	7	10-May-2006 15:10
Monitoring Thread Size	mark343	MS Visual C++ / MFC Forum	0	04-May-2006 09:09
Sending message to GUI thread that ISNT the main thread	mpviii	MS Visual C++ / MFC Forum	1	20-Apr-2005 12:49
reading from comm port and displaing in editbox using MFc	ib_alam	MS Visual C++ / MFC Forum	9	02-Feb-2005 18:57

Guidelines Thread

Re: Guidelines Thread

Re: Guidelines Thread

Re: Guidelines Thread