|
1. context : I went to the Lounge, from my taskbar link to CP in Chrome release
2. I entered "Emsisoft" in the search text-entry field, and selected the radio-button option "Messages"
3. that took me to this CP page:[^], which has only one message on it: clicking on that message takes me to:[^]. That is a Lounge thread on page #9926 titled: "Which antivirus."
~ no problem so far ~
4. My goal then was to go back one message page, or more, to find the start of the thread, and look at all the messages.
~ and now, the problem ~
5. clicking "Prev," or clicking the link to page #9925: both take me to the current page #1 of Lounge threads.
I have repeated this same sequence twice, with the same results.
Of course I tried hacking the url for the thread, subtracting #1 from the id, which does not work 
And, of course, this reminded me of the "impossible dream:" that clicking on the pop-up grey-lines that indicate "ancestry" of the currently open message ... in this case, unfortunately, spanning page boundaries ... would take me to at least the parent node of the current message, and that way I could "walk down" the tree to the root, "on foot," as it were
best, Bill
"Singapore no long time." Response of Singapore taxi-driver to me on March 15, 2012, while en-route to the Thai Embassy, when I asked him if it would take a long time to get there, as we were stopped in heavy am traffic.
|
|
|
|
|
The problem is caused by the message being too deep for the message paging to working efficiently, so the paging gets disabled and the links take you back to the homepage.
I need to update the UI to reflect this.
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
The "View Thread" widget works just fine, it doesn't mind you fancying ancient posts.
|
|
|
|
|
Hi Luc,
Good grief ! Have I been unaware of yet another CP feature ?
thanks, Bill
"Singapore no long time." Response of Singapore taxi-driver to me on March 15, 2012, while en-route to the Thai Embassy, when I asked him if it would take a long time to get there, as we were stopped in heavy am traffic.
|
|
|
|
|
You'll be the judge on this matter...
|
|
|
|
|
Luc Pattyn wrote: fancying ancient posts
Is that a euphemism for grave robber?
|
|
|
|
|
This article submission wizard is rather instable: under certain circumstances I can not upload files any more, or IE crashes after a while, etc.
I could live with that when I don't loose all my editings every time. How to get to an article/tip that was under construction while the IE crashed?
The original link returns to the empty data (article is gone, uploaded data is gone, changed title is gone, the publish link changes it's magic number somewhere in the path. Trying to access the publish link does not help neither...
The data is still there, I'm sure, but how to get it "back" into that (st..id) Wizard?
Any help is very much appreciated - also if it says: "nop, that .... is lost!" (then I don't have to search for it).
Cheers
Andi
PS: How do you compose articles in that environment? What tools do you suggest? That Wizard is a pain in the neck - not worth much if the data size exceeds some trivial size... 
|
|
|
|
|
You get back to the wizard by going to Articles -> Submit an Article or Tip, and any auto-saved drafts will be shown.
Which version of IE are you using? Could you run through the steps you tried when it failed? How large are the files you're uploading?
I'm aware of a bug that causes uploads to fail if they are over 4MB. We're working to get a new release out in the next 2 days that will fix this.
What was the title of the article? I'll hunt around and at the very least put something back in the system (assuming I can find it) and leave it in Composing status.
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
Ah, that was it! the list of autosaved articles! Thanks a lot!
I have IE9. The files are tiny (7x about 4KB GIF files, and one 5KB ZIP file).
The effect is intermittent - may be that some files could not be uploaded or that the Add File button has no effect any more after a while (e.g. add a file and try to add another file after a while). Before that happened, I switched forth and back between HTML and raw view, did some Preview to see the line numbers, etc.).
BTW: Independently of the abov: in the HTML view, the line numbering is never visible - and can I start the line numbering at some other number, say 47 instead of 1?
Thanks for your help!
Andi
|
|
|
|
|
Andreas Gieriet wrote: in the HTML view, the line numbering is never visible - and can I start the line numbering at some other number, say 47 instead of 1
You mean line numbering using the "linecount=true" attribute in the PRE block? That's only added as part of syntax colourisation so won't be visible in design mode.
Setting a starting value isn't something we currently support but is something I can certainly add to our TODO.
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
Hello Chris,
Yes, that's what I mean: linecount="on" (as described in Using PRE tags on Code Project[^]).
E.g. <pre lang="cs" linecount="45">...</pre> would have the meaning: line count on and start at 45.
This is especially helpful if you have a source code citations in the document. Starting a 1 is kind of "useless" for this documenting style.
Cheers
Andi
|
|
|
|
|
I agree! until you start asking for a linenumber increment of 10.
PS: do you want linecount="0" to mean off? or start at zero (and "-1" would then be off)? Of course, "on" could be interpreted as "1", and "off" as off.
|
|
|
|
|
See Chris' suggestion below. I think this is what I need. My suggestion was more on the "hack" side  .
|
|
|
|
|
I saw that.
I will upgrade my Using PRE tags on CodeProject tip if and when things get changed.
|
|
|
|
|
Hello Luc,
the feature is in use and works like a charm! See my latest tip update at the far end (in pending state though).
Cheers
Andi
|
|
|
|
|
Andreas Gieriet wrote: and works like a charm
Not really. It may be OK in tips&tricks, it has at least one bug in forum messages: countincrement seems to work, countstart doesn't.
example using <pre linecount="True" countstart="30">
30 Graphics g=e.Graphics;
31 g.FillRectangle((e.State&DrawItemState.Selected)==0?Brushes.White:Brushes.Yellow, e.Bounds);
32 Brush brush=Brushes.Black;
and <pre linecount="True" countincrement="10" countstart="30">:
30 Graphics g=e.Graphics;
40 g.FillRectangle((e.State&DrawItemState.Selected)==0?Brushes.White:Brushes.Yellow, e.Bounds);
50 Brush brush=Brushes.Black;
|
|
|
|
|
I could achieve my goal, i.e. it worked for me.
After tweeking a bit with countstart I think I found that it only works if the <pre... tag is on the same line as the first code line. Otherwise, the count starts at 1.
I did not use countincrement.
Andi
|
|
|
|
|
You may be correct, but then it wouldn't make much sense that countstart has a positional requirements, whereas linecount and countincrement don't.
And yes, I tend to put the PRE tags on separate lines, as it preserves vertical alignment of the code.
|
|
|
|
|
I'd prefer
<pre lang="cs" linecount="true" countstart="10" countincrement="10">...</pre>
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
Looks perfect - my suggestion was not so well thought through.
Cheers
Andi
|
|
|
|
|
This has been done. I'm doing a code deploy tonight (assuming final testing).
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
Hey, that's quick!
Any test support needed?
Cheers
Andi
|
|
|
|
|
Sorry for the delay but our tewting showed some errors the day I wanted to deploy, and we've only just had a chance to redeploy. The feature is now in place so go for it.
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
Hello Chris,
works like a charm! See my latest tip update, at the far end (at the moment, the tip is in pending state though).
Thanks again, it's very useful!
Cheers
Andi
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
