Bugs and Suggestions

9-Jun-10 5:50

I just tried reproducing that locally and couldn't. Let us know if you see this happen again.

Highlighting Problem

Hans Dietrich8-Jun-10 10:24

8-Jun-10 10:24

Sometime recently, what happens when you double-click a word to highlight it has changed. Previously only the word was highlighted; now the word plus the following space is highlighted. This becomes a problem when you want to underline a word: the word plus the following space are underlined, if you double-click and then hit the U button. (I am talking about forum posts here.)

Would it be possible to not underline the following space?

Best wishes,
Hans

Chris Maunder8-Jun-10 10:34

Chris Maunder

8-Jun-10 10:34

We can't control a what your mouse highlights when you double click, but we can do something like trim the selection of whitespace. However, last week we had a situation where Luc specifically want to highlight a word and it's preceding whitespace so being overly clever to help you would bring done the unyielding Wrath of Luc.

cheers,
Chris Maunder

The Code Project | Co-founder
Microsoft C++ MVP

Hans Dietrich8-Jun-10 10:39

8-Jun-10 10:39

Chris Maunder wrote:
We can't control a what your mouse highlights when you double click

Obviously you can, because something changed, and now it works differently.

Best wishes,
Hans

Re: Highlighting Problem [modified]

Chris Maunder10-Jun-10 4:34

Chris Maunder

10-Jun-10 4:34

You're welcome to review the javascript yourself and try and find the new function that automatically, each time you make a selection, adjusts the selected text to include the traling space for no reason other than to annoy you.

Maybe - just maybe - a browser upgrade or patch changed things, or maybe it's one of those things that you've just noticed because you're doing something different.

cheers,
Chris Maunder

The Code Project | Co-founder
Microsoft C++ MVP

Luc Pattyn8-Jun-10 12:09

8-Jun-10 12:09

I'm honored to feature in your considerations, however I did report the exact same problem a couple of days ago.

I also discovered and described the behavior of spaces getting swallowed under some conditions (see here[^]) [*], however the two issues are quite distinct.

The current issue can be described like this:
- if the caret is somewhere in a word, and a double click is applied, the entire word plus the trailing space, if any, get selected. That seems normal behavior of TextBoxes and the like. I don't want the CP web site to change that (assuming it could).
- when the mouse is dragged (or shift-arrow key combinations are typed), anything can be selected.
- the problem arises when one of the style widgets (bold, italics, small, ..., and mostly underline) is then clicked. This applies the style to whatever is selected.

Our shared suggestion/plea is to unselect the trailing space when present. So you should not remove the trailing space, all that would be required is to consider it not part of the selection, resulting in it not getting bolded/italicized/.../underlined.

Smile | :)

PS: no Wrath is imminent, a little grumble maybe.

{ADDED}
[*] it is unrelated to CP, seems to be normal HTML interpretation of multiple spaces.
{/ADDED}

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read formatted code with indentation, so please use PRE tags for code snippets.

I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).

modified on Tuesday, June 8, 2010 7:50 PM

Hans Dietrich9-Jun-10 4:39

9-Jun-10 4:39

Exactly! In other words, undo the change.

Best wishes,
Hans

Luc Pattyn9-Jun-10 4:44

9-Jun-10 4:44

I'm not convinced anything has changed, actually. When I "solved" the space highlighting problem, all I did was improve my observations and come up with a plausible theory; I don't think Chris modified anything at all around that time, but then, one never knows.

AFAICT the trailing-space-being-underlined bug has always existed, but then I'm not so sure as I used to not use the widgets much until recently, and I seldom use underline. Now, if it were fixed, I'd use it more.

Smile | :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read formatted code with indentation, so please use PRE tags for code snippets.

I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).

Hans Dietrich9-Jun-10 5:09

9-Jun-10 5:09

I don't know exactly when it changed, but I DO know that it did. When I noticed this several weeks ago, this caught my eye immediately, and I thought, How awful! This is such a typographical faux pas that not even apprentice typesetters would make.

Yes, you don't need to tell me that I'm way too picky about such things. Probably a left-over from one of my first projects, when I worked on a commercial typesetting system.

Best wishes,
Hans

Luc Pattyn9-Jun-10 5:14

Tip & Trick formatting problem

9-Jun-10 5:14

Hans Dietrich wrote:
I'm way too picky

I'm saying no such thing, and in fact, you are not IMO. All opportunities to improve things should be considered, big or small, doesn't matter. Small-and-easy should just be done with.

Smile | :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read formatted code with indentation, so please use PRE tags for code snippets.

I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).

Johnny J.8-Jun-10 5:19

Re: Tip & Trick formatting problem [modified]

8-Jun-10 5:19

I just tried to add a tip containing code in VB where some of the code was class attributes enclosed in < and > . That doesn't work at all when you wrap it in pre tags.

I'll try to post the lines here to see what happens:

With pre tags:

<ToolboxBitmap(GetType(Label))> _
Public Class TransparentLabel

Without pre tags:

<toolboxbitmap(gettype(label))> _
Public Class TransparentLabel

EDIT: Nope, neither of the code snippets show properly - the attribute line is disappearing - Editors that can see this post in edit mode will see what I mean...

Luc Pattyn8-Jun-10 5:29

8-Jun-10 5:29

In general you have to ~~espace~~ escape those characters that make parts of your code look like HTML tags.
In a forum like this one, you'd have to replace < by < to prevent the HTML monster from potentially eat it all.

Here is actual proof it works both inside and outside PRE tags, the previous sentence really contains:
replace < by &lt; to prevent

replace &lt; by &amp;lt; to prevent

AFAIK in Q&A and T&T editor, if your piece of code is pasted and gets recognized as code (which means it gets PRE tags added automatically), then it will also be "HTML encoded", preventing any such problems.

If OTOH you explicitly told it not to recognize code, or you pasted a lot of text toghether with some code in one big swoop, or you entered the < signs without pasting at all, then it is your responsibility in Q&A/T&T to escape them as indicated earlier.

Smile | :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read formatted code with indentation, so please use PRE tags for code snippets.

I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).

modified on Wednesday, June 9, 2010 7:14 AM

Johnny J.8-Jun-10 5:32

8-Jun-10 5:32

It did actually get encoded, but I thought it was a mistake in this case (thought that the pre tags in this case required the real code) and changed it back, duh!

Thanks

Test:

<ToolboxBitmap(GetType(Label))> _
Public Class TransparentLabel

Henry Minute9-Jun-10 0:28

Henry Minute

9-Jun-10 0:28

Luc Pattyn wrote:
In general you have to espace those characters

Why on earth would Johnny J want to carry his characters around in an overpriced French People Carrier?

Henry Minute

Do not read medical books! You could die of a misprint. - Mark Twain
Girl: (staring) "Why do you need an icy cucumber?"
“I want to report a fraud. The government is lying to us all.”
Why do programmers often confuse Halloween and Christmas?
Because 31 Oct = 25 Dec.

Johnny J.9-Jun-10 0:55

9-Jun-10 0:55

Luc Pattyn9-Jun-10 1:18

9-Jun-10 1:18

maybe so you can see them very well and learn from them, isn't that the main idea behind the T&T section?

Thumbs Up | :thumbsup:

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read formatted code with indentation, so please use PRE tags for code snippets.

I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).

PompeyBoy39-Jun-10 1:19

PompeyBoy3

9-Jun-10 1:19

Message of the Day by a country mile methinks

Thiru Thirunavukarasu8-Jun-10 5:30

8-Jun-10 5:30

Angle brackets are always interpreted as html tags. If you want them to be visible escape (< for < and > for >). Which is what I've done below

<ToolboxBitmap(GetType(Label))> _
Public Class TransparentLabel

Johnny J.8-Jun-10 5:32

Re: Tip & Trick formatting problem [modified]

8-Jun-10 5:32

Great, thanks to you too Thiru

Luc Pattyn8-Jun-10 5:39

8-Jun-10 5:39

Thiru Thirunavukarasu wrote:
Angle brackets are always interpreted as html tags

I slightly disagree. It is my guess there often (maybe always) is an attempt to interpret them, however it often fails gracefully.

Behavior is rather inconsistent, my below example holds comparisons with a numeric constant "10" and a numeric variable "n"

// comparing with 10
for(int i=0; i<10; i++) // no escape used, "tag" doesn't start with a digit, so it works just fine
for(int i=0; i<10; i++) // escape used
// comparing with n
for(int i=0; i<n; i++)  // no escape used, "tag" starts with a letter, gets eaten
for(int i=0; i< n; i++)  // no escape used, "tag" starts with a space, and it works fine
for(int i=0; i<n; i++)  // escape used

BTW: always escaping them works fine, so that is still the recommended way!

Smile | :)

PS: the example also illustrates some syntax coloring odities that have been reported before (and aren't all that important)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read formatted code with indentation, so please use PRE tags for code snippets.

I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).

modified on Tuesday, June 8, 2010 11:45 AM

Thiru Thirunavukarasu8-Jun-10 10:00

8-Jun-10 10:00

Yep correct. What I kind of meant to say is that our editor doesn't try to do anything special with the angle brackets so it's up to the browser to render as it sees fit.

Luc Pattyn8-Jun-10 10:09

8-Jun-10 10:09

are you saying the earlier observations are in accordance with the HTML specs, hence all browsers (should) treat them the same; or are you suggesting each browser can do as it sees fit, hence we authors would better always escape correctly?

FWIW: when I try and keep my web site W3C compliant, and use its check tool, I have to escape them.

Smile | :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read formatted code with indentation, so please use PRE tags for code snippets.

I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).

Thiru Thirunavukarasu8-Jun-10 10:36

8-Jun-10 10:36

Luc Pattyn wrote:
are you saying the earlier observations are in accordance with the HTML specs, hence all browsers (should) treat them the same

Nope

Luc Pattyn wrote:
or are you suggesting each browser can do as it sees fit, hence we authors would better always escape correctly

Yes since it's non-standard each browser will have a different implementation.

Escaping is definitely best!

Luc Pattyn8-Jun-10 10:43

8-Jun-10 10:43

Thanks. That is very good to know, as having it look good on my browser (FF) no longer is a guarantee then it will look good on most.

Thumbs Up | :thumbsup:

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read formatted code with indentation, so please use PRE tags for code snippets.

I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).

Thiru Thirunavukarasu8-Jun-10 10:51