[wizzard]

I think there should be a way to get lines in the ChatBox so I can implement my own copy and pasting functionality.
It would also be nice to have a callback for when a line is right-clicked.

[wizzard]

Also, a way to remove lines so I can enforce a line limit.

[texus]

I could add the following functions:

sf::String getLine(unsigned int lineNumber);
void removeLine(unsigned int lineNumber);

Maybe I should add this as well?

void setLineLimit(unsigned int maxLines);

But the right click is a bigger change. I was trying to delay that until I was going to add a PopupMenu widget (probably not in v0.6).

[wizzard]

Those three are a nice start. I'd eventually like the callback feature but there is no rush.

[wizzard]

P.S. a popup menu would be awesome to mix with that right click feature

[texus]

The three functions have been added.

[wizzard]

The speed at which I can request something and it becomes reality is awesome.

Thanks again!

[wizzard]

Hm. How should I go about combining the multiple, split lines into the original string given to addLine?

Edit: I suppose I can keep track of added lines in a separate container,
but this is sort of what I was hoping for with the line accessors.

[wizzard]

Maybe addLine should return the number of lines the string was split to.

Edit:
Either that or internally map the text widgets to lines and use that in getLine and removeLine instead of literal line numbers.
Line numbers in Notepad++ with word wrap enabled are like this.
The actual lines are not counted, just the newline character is counted.

For example, when getLine is called, a map looks up a list of text widgets depending on the index.
The text of those widgets is then recombined and returned.

I think that even though getLine and removeLine would be changed, that setLineLimit should remain the same.
At least, setLineLimit would be the same from the user's point of view (counting actual lines on the screen).
Eh... now that I think about it, that'd just be confusing.

[wizzard]

The number of lines is also needed for iterating.

Edit: This is becoming a rather large request, but I think its all good stuff for later
because it will make the right-click callback easier to implement after lines are exposed nicely.

[texus]

For now, I'll let addLine return the numbers of lines.

The other option is better, but requires a bit more work (e.g. make sure that a newline in a label has the same spacing as the lines that I manually place below each other).
I'll implement it somewhere soon, but for now you'll have to do with the first option.

Edit:
With the Notepad++ way, what do you expect that happens when the string that you pass to addLine has a '\n' character? Should it count as two lines or should everything passed to addLine count as a single line?
I'm thinking of something like skype. In your message you could still add newlines, and it would be nice that the whole message could be treated as a whole. But on the other hand, it also makes sence that when encountering a newline means that the lines are split.

[wizzard]

This is a really small issue and I see reason to go either way,
but I think I vote for NOT counting the new line character as a new line.
My reasoning is that because if you do this automatically, you can't revert to the other way,
and if you don't do it automatically, it can be manually implemented.

[texus]

The changes have been made.

addLine no longer returns anything, everything passed to addLine is considered to be a single line.

[wizzard]

I do still need to know the number of current lines for iterating.

After that, this is enough to implement copy and paste without keeping track of added lines in a separate container!

[texus]

Ok, it now has a getLines function which will return the amount of lines in the chat box.