|
So where's option #5 - Tech enough... if by "tech" you mean "VB gushing"?
Oh, and why is this in the suggestions forum? 
I think it's cool that Shog's coding johnson is longer than everyone elses
-- JoeSox 10/8/03
|
|
|
|
|
Shog9 wrote:
Oh, and why is this in the suggestions forum?
Er... it's a suggestion for a weekly poll. 
Cheers,
Simon
sig ::
"Don't try to be like Jackie. There is only one Jackie.... Study computers instead.", Jackie Chan on career choices.
article :: animation mechanics in SVG blog:: brokenkeyboards
|
|
|
|
|
|
Nishant S wrote:
5. I cannot go, as it's held in the US and I am not in the US
That would be #6. #5[^]
|
|
|
|
|
Nishant S wrote:
5. I cannot go, as it's held in the US and I am not in the US
AFAIK, neither is SimonS... 
I think it's cool that Shog's coding johnson is longer than everyone elses
-- JoeSox 10/8/03
|
|
|
|
|
Nope. He's a Saffa. 
We have quite a few MSDN Essential workshops and other Microsoft events here in Johannesburg. I used to work in the building right next door to Microsoft so we used to just walk to the events. 
Despite the high cost of living, it remains popular.
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
|
|
|
|
|
I once went to an MS 'event' in South Africa. It was the introduction/presentation of Windows XP. Not really tech but still quite interesting.
Paul 
That demands capital punishment!! Death by a herd of marauding Bobs! - Ryan Binns
modified 18-Jul-18 11:59am.
|
|
|
|
|
How about a discussion area dedicated to UML Modeling?
Paul Watson wrote:
"At the end of the day it is what you produce that counts, not how many doctorates you have on the wall."
George Carlin wrote:
"Don't sweat the petty things, and don't pet the sweaty things."
Jörgen Sigvardsson wrote:
If the physicists find a universal theory describing the laws of universe, I'm sure the a**hole constant will be an integral part of that theory.
|
|
|
|
|
|
I third it and our UML designer fourths it.
I support two teams: the Canucks and whoever is playing the Leafs!
|
|
|
|
|
A significant percentage of newbie posters systematically forget to check this option on, so that their snippets of code are unreadable. My proposal tries to remedy this while having the least impact on more seasoned users:
- This option is a user profile dependent config option.
- Existing users keep their status quo (i.e. the option is initially set off
for them.) - Starting from the date the patch is applied, new users will have the option set on by default.
- Every time an user posts a message, the option used (set on/set off) gets saved to her profile as the default for subsequent posts.
What do you think of this? Regards
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
good idea
for me the best solution would be that the parser will not handle html tags inside the <pre> and <code> sections
|
|
|
|
|
I wouldn't like to be deprived of the possibility of embedding tags inside <pre> sections. It allows me to write things like:
Change the function declaration to
extern object clone(<font color=ff0000>const</font> object& x);
Furthermore, newbies usually paste the code without any <pre> (they probably don't know this can be used.)
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
|
|
...a Bob bobble head doll!
WHAT a treasure! (And highly collectable, as well.) 
Ya gotta do it - ya just gotta! Dave, Chris, trust me on this one! It`s gonna be GrrrrrrrrrrrrreeeeaaaTTTT!
|
|
|
|
|
Already checked into pricing.
All I can say is: 
cheers,
Chris Maunder
|
|
|
|
|
Maybe if you order 500,000 of them, the price per unit should definitely come down
Sonork 100.11743 Chicken Little
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
Within you lies the power for good - Use it!
|
|
|
|
|
Maybe I've already overlooked them in my haste, but I haven't seen any forums devoted to DirectX, OpenGL, or other API's of the like. What happens when someone has a question about a DirectX project they're working on but they're doing it in VB. Yes they can take it to the VB forum, but there's also a lot of people who know DirectX in the C++ part as well. The opposite would be true as well. A few ideas on how to work this:
-One forum devoted to API's as a whole
-Separate forums for the most popular API's
-Subforums for the API's under the respective languages ( C#->API )
-Subforums for the different API's under the language forums ( VB->DirectX, C++->OpenGL, etc )
Any thoughts?
Always Fear the Man with Nothing to Lose
Jeryth
|
|
|
|
|
IMHO, the current approach - focusing more on the task than on a potential tool - is better in most cases. However, it would be nice in certain situations to have a very granular API forum - being able to group questions & answers by a specific API (all random data for SetWindowPos()) could come in handy were it used correctly.
Still, the CP search function does quite well for this last use, and given the potential for abuse (users cross-posting when they can't decide on a correct forum) seems like it may be an acceptable compromize for the time being.
Shog9 -- Exchanging a walk-on part in the War for the lead role in a Cage
|
|
|
|
|
Maybe I understood your post a little differently than you intended, but this might serve to clarify it for others. I didn't mean to employ all four ways I listed, but to select one that might work and use that and forget the others.
Always Fear the Man with Nothing to Lose
Jeryth
|
|
|
|
|
Currently, there is one "Result" bar that displays readers' feedback about an article with regards to how they rate it.
A good idea would be to add a second "Result" bar to reflect readers' evaluation of the same article (and it's sample code) if the author should update the work. The general idea is that after an article has been posted, many times the author will respond by improving his/her work due to the feedback received. It would be good for the general readership, when they see two "Result" bars, to know that the work has been updated, and can judge whether it was done for the better or the worst (because of the new evaluation responses the community would be giving).
Looking at the situation the way it is now, if an article (and its accompanying code) started out poorly and duly received poor rating, but due to the feedback the original article received, the author may have tremendously improved its quality and contents, hardly anyone would know if it was improved for the better or the worst. One "Result" bar does not accurately reflect the new reception the upgraded and improved work would be (deserving of) getting. A second "Result" bar would.
If the thought is that a single "Result" bar adequately does the job (and would continue doing it) if the work is improved (because readership would then start giving it improved rating), is exactly the point, but it would be mixed in with the old rating that reflected the poor quality it was before. That poor rating (the original "Result" bar would show), may just discourage a new reader from reading what has been markedly improved. A second "Result" bar would leave no doubt to those who see a second bar, that it may just worth their while to review the improved version of the article (which may just turn out to be to the reader's benefit but which ONLY would have happened because he/she saw a second "Result" bar).
If after a while, the second bar start showing the same level of rating as the original one, the other members would know it's not even worth their time to give the article a second glance. (The appearance of a second bar came through beneficially again.)
William
Fortes in fide et opere!
|
|
|
|
|
A second bar doesn't seem to scale well, do you add a third bar if the article is revised a second time?
A different way to address the same problem might be to just let people change their vote. That was my instinctive desire when faced with an article that had been improved with a revision or two.
--
-Blake (com/bcdev/blake)
|
|
|
|
|
No, you don't add a third bar, nor a fourth, nor a fifth (etc.) every time the article is revised. There will ALWAYS be just two bars; one representing the current rating, and the other representing the previous rating, with the readership getting to vote anew every time the article gets updated. That ability to vote anew only becomes doable when the article is revised.
The idea of being able to vote anew with only one "Result" bar present, is that it would invalidate (or corrupt) the previous rating for the work (as it existed) prior to it being updated, leaving the general readership without a means of knowing whether the updated work was better, worst, or of the same quality (whatever that might be) prior to it being updated.
The second bar simply adds a comparative means to the prospective reader in deciding whether to do a second reading of the work or simply pass it over.
William
Fortes in fide et opere!
|
|
|
|
|
The problem with having a fixed two bars tied to the current edit and the last one is that a simple typo correction would roll things over. Hmm, perhaps in conjunction with some sort of 'Is this a minor or major edit?' prompt when saving changes.
--
-Blake (com/bcdev/blake)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
