I noticed while editing your article that there were line breaks in the text which I corrected. These line breaks were actual HTML line breaks (<br/>), so for instance you had the line
For this reason <br/>
it is always better to just do pre increments
which is rendered as:
For this reason
it is always better to just do pre increments
When you say "the preview" do you mean within the WYSIWYG editor, or when you hit the "Preview" button? If the former, then it could be that this line break matched the width of the editor screen so wasn't evident. If the latter then we have a bug!
With "preview" I mean the preview-button. At that time I thought it was very evident. Preview after preview-button was different from the view when the article was pending. ... but hey I did it at 2-ish at night so my mind was mush.
I.e. I think it's a bug, but I wouldn't stake my life on it.
I've tested both on live and on development and can't replicate the issue. It may have been an earlier bug we've since fixed. A few days ago I did reset the document format on a few articles that had been incorrectly set, and we also updated our rendering code.
In any case, if you see it again just let us know.
BTW - you have a ton of outstanding Draft versions of that article you recently published. Would you like me to clean up the debris for you?
* Provide the tool bar the the bottom of Editor. Mostly, when writing new article, the author would generally be writing at the end of editor. So, when author needs to apply some formatting he/she would need to make toolbar visible and then hit appropriate button. But then, the original text would not be visible. I have 22" monitor, and I write on about 150% of zoom in IE9. But toolbar isn't visible.
* Add more shortcuts, Ctrl+D is good, but what about "Formatted" for code? How to switch between HTML and WYSIWYG?
* Most authors don't know additional formatting, like "div=callout", and instead use "Formatted" instead. The parser would read it as text rather than special comment.
* On code pasting, convert tabs to 3-4 tabs, instead of author doing that manually. Also additional lines would come up when pasting.
The HTML of the original (to be edited) article may retain the old style file references (eg src = "MyArticle\MyArticle_Image.png"). In this case, it is necessary, but not obvious that the reference MUST be revised to src = MyArticle_Image.png. You provide a good clue by saying that uploaded files are relative to the article (or something like that). It would be better if that statement was augmented by something like "Check that the HTML references do not contain Directory names" -- hmmm I'm sure you can improve on that!
I do not know that the invalid refs are cleaned up on submission - I never had the guts to try. I do know that the invalid refs are NOT cleaned up on Preview.
I was updating 2 articles and only one showed that problem.
Thanks for the feedback, Jim. We tried to be clear on the submission wizard itself where an example of referencing files is shown within the list of uploaded files, as well as providing "insert" buttons that will do all the work for you.
The trick here is that, underneath it all, we still actually use "MyArticle\file.ext" (though this is now "1234\file.ext" since we've ditched basenames due to uniqueness headaches and just moved to using the article ID). Within the submission wizard editor we strip the "MyArticle\" from the raw HTML, then when you switch to design mode, add it back so the WYSIWYG mode shows the images.
So: it's the same as it always was, but when editing the raw HTML we do some magic so it seems like references are now relative to the directory containing the article.
Further, if you upload a file and reference the file using Directory\file.ext, then it should all still work. If it doesn't, please let me know which article and I'll dig in.
Thanks for the quick reply! I think I will have to look harder for the "Insert" buttons!
The one thing that threw me off is that for some reason when I switched to Html view, the MyArticle\ was not switched off. I was explicitly looking for something like that since my image was not showing in Preview. In the Design view, the older Image was the one displayed. I had deleted that Image file and add/upload a new Image with the same name. The way I fixed both of these problems was to manually strip off the "MyArticle\" from the src = and also from the download files, in Html view of course.
I was making a mod to an old article that I had updated the day before (a mod to a mod). What really irritated me was that I had had the same problem with the first update and didn't note or remember how I had fixed it then - after all, it was only 12 hours between updates - I should have remembered.
Just to make it more confusing, I was doing two articles over the same time period and the first article, of about the same vintage or even older, did not have any of these problems.
Bottom line: The suggestion I made was to address a problem that should not occur.
Should you wish to chase this one, the article's ID is 11654.
I had a quick play and it seems the article is all good now. Having the old MyArticle\ appear is annoying. This most likely happened because of some bad data our end.
Some more background: initially all articles simply referred to downloads in their MyArticle directory without any recording in our database of what was actually in that directory. We fixed this by scanning the directories and recording, and associated, downloads for files.
In some cases we had servers that were out of sync and so this association was inaccurate. When this happens the submission wizard doesn't know how to trim links because it doesn't trust anything other than what the database says.
That error will be triggered anytime a major portion of the template exists in the content.
With the new submission wizard you don't need to publish it to save it. You can hit the Save Draft button and your current work will be saved as a draft. To view drafts, just go to the submission page[^] and you'll see, on the right hand side, your drafts.
Unfortunately I gave you some misinformation: you can change the article type, but only when posting a regular article. You've posted an alternative to an existing article, meaning that your alternative must be the same type as the original article. An alternative to an article is an article, an alternative to a tip is a tip, etc.
Starting today, the "Vote to remove this message" link in forum message won't simply add to the tally of votes to decide if a message should be removed: Abusive or innappropriate messages now lose their authors 20 points. Next week that increase to 20 points x member level, meaning a potential loss of 200 points per message flag.
Previously our article URLs were of the form www.codeproject.com/kb/section/basename.aspx. This worked well and allowed you to easily remember your own articles. My grid control article, for instance, MFC Grid control 2.27, was an easy URL for me to remember.
The issue was that while this naming convention was simple, it was also predicated on each article within a section having a unique basename. With 35,000 articles, this was starting to become a little tricky.
On an unrelated, but nevertheless important note, we strive to ensure our authors' articles are positioned as high as possible within search engine rankings. Search engine ranking depends on an enormous number of variables, up to and including the phase of the moon, but while "http://www.codeproject.com/kb/miscctrl/gridctrl.aspx" is OK, "http://www.codeproject.com/Articles/8/MFC-Grid-control-2-27" is better. And "http://www.codeproject.com/Articles/317712/An-MFC-Chart-Control-with-Enhanced-User-Interface" is even better (from a search engine point of view) than "http://www.codeproject.com/kb/Chart/MFC-Chart.aspx".
And as a final but neat freebie, we have tossed the extension. No more .aspx. A trivial thing, but when Microsoft comes out with the Next Big Thing, or we move to PHP or JSP, then article links will be the same. This should be the last URL change we ever have to do for our articles.
1. Completely revamping the article submission (for everthing) and the display system for tips.
2. Adding new options for articles.
3. A ton of work on Lake Quincy. Our little project is all grown up and has an appetite for developers to match.
4. Machinations and experiments with Quick Answers and the Forums. Some very interesting stuff. The most interesting bit is making it so you guys don't notice anything until there's the "oh - I see!" moment.
Some devs like to make big splashes. I prefer my code to just settle in comfortably into your lives and work without you realising anything.
The upshot of this is that I have zero social life and even less time to hang out in the Lounge. Bah humbug.
One of the features that has generated a lot of debate and suggestions is the way we handle text, HTML and code in the forums. Copying and pasting code - especially web related code - into the message editor can cause problems due to the unintentional posting of HTML tags instead of HTML encoded content.
To help with this we had "When Pasting" options at the bottom of the message posting area that allow you to set defaults on what happens when you paste, but what you want to do changes depending on what you paste. The problem here is that you defaults don't always fit the situation at hand, so we need a way to allow you to change your mind easily.
From today we removed the paste options from below the message and instead show a popup dialog that intercepts the pasted content and tries to figure out what your options are with visual aids to help show what each option will do. The "When pasting" that apply to the paste text are shown in this dialog, and as you hover over each option the pasted text in the message text area is updated, as well as a small preview in the paste dialog to give you a quick peek into what it will look like. If you are pasting text that will look the same whether you're pasting as text or HTML (or mixed) then the options shown are reduced to the minimum set possible, and your default setting will be automatically checked and always shown.
On top of this, as you type, a preview of what your message will look like is now shown at the bottom of the page.
If, after pasting, you are happy with what's shown, or don't want to be bothered, keep typing. The dialog will fade away. This is not the popup dialog you are searching for...
The changes are designed not to simply show you what will happen, but also to give you an ida on how to encode your content to ensure it displays in the manner you intend. The changes are also meant to be as unobtrusive as possible, and text will be pasted initially as per your defaults. We're only adding a simple way to change your mind.
For those who never pick a default, and never touch the popup dialog, the default will always be "Best guess" meaning if it detects code in the pasted text it will wrap in PRE tags, otherwise it will paste and preserve HTML tags (no encoding on paste).
Encode button in the editor
We spared no expense in adding an "encode" button. Highlight some HTML, hit encode, and the text is HTML encoded.
Editor Live preview
Hopefully you waon't even notice (unless it's in a good way) but more content is being pre-cached, speeding up some of our lesser-used pages.
Split Quick Answers / Discussions menus
More admin options
We've armed ourselves with some bigger guns to deal with reported items. Don't worry, this won't hurt a bit.
The forum indicator lines were a small HTML5 experiment I was doing that turned out to be actually useful. The quick version is: when you hover over a message, find that message's parent (if it's on the page), create 2 canvases representing the two segments of the line, and draw. If the parent message isn't on the page, show an arrow tip indicating "over there somewhere". Why not a single canvas? Because IE doesn't support the pointer-events:none style. pointer-events:none allows you to have an element on top of another element (say, a single canvas overlaying the forum) and have that element ignore all pointer (eg mouse) events and instead have those events pass to the underlying controls.
The way around this was to create two canvases that didn't overlap anything mouseable, with a nice byproduct being a healthy speed increase (smaller canvas = faster resizing, repositioning and drawing)
The forum flags in the bugs and suggestions[^] forum (and soon, your article forums) allows me to provide a simple visual feedback on the bugs and suggestions posted. If you find a bug you can scan the page, find a similar (or same) post, and note that it's in progress to being fixed or that it's fixed and will be released next deploy.
The new forum message posting page now incorporates the same editor that's used in Quick Answers. For me this means a single codebase to maintain (yay!). For you it means the auto-code sniffer is now in the forums (yay!). Post some code, the sniffer will try to see if it's code, and if it is it will wrap your pasted code in PRE blocks and assign the language automatically.
Site speed continues to be a focus and we've put in a ton of work to improve caching. Our main database was cruising along at 75% utilisation at peak times and that's bad in anyone's book. We're now down to about 50% simply by tackling the easy jobs, and with a further push to do some fundamental re-architecting, we should again halve that. For the first time in our history we're no longer looking to add database capacity, but are actually now consolidating databases and saving ourselves some SQL licencing fees.
Optimisations to improve site speed have been done on a number of fronts, from simple caching, to the best optimisation of all: not doing the work. An example is our Quick Answers[^] homepage. Previously we were tracking which questions you had viewed and which you hadn't. It turns out there's an excellent technology in place that can do this for us: your browser. You view a link, the link is purple. Why should we override that and add functionality already in place?
Another example is when viewing a question you see the Next / Prev links. Calculating which message is next and previous, based on your interests, the current message, your filters and the waxing or waning of the moon is expensive, yet only a fraction of members will actually click that "Next" link. Those who click it, need it and love it, so the answer isn't to remove it. Instead of calculating the "Next" question on the page that shows you the initial question, we initially have the next button go to a fixed page that will do a single expensive query for you, and then cache a large number of questions in either direction.
Previously when viewing the question you had the hit of calculating the next question. Now, no hit on viewing the initial question, but a small hit when you first click Next. After that the results are cached, and there will be no further delay until you exhaust the cached results.
Plenty new features are simmering away. I'll try to provide more frequent updates.
The indicator lines in forums have been turned off for now after a user reported it was causing Chrome to lock up. I'll dig in and find the cause - or at least find a workaround - and get them back ASAP.
...and they are now back.
The Code Project | Co-founder
Microsoft C++ MVP
modified on Thursday, July 28, 2011 3:31 PM
Last Visit: 31-Dec-99 18:00 Last Update: 2-Jul-15 18:15