Multi-line cells in lists: showVerticalTabs property?

[FourthWorld]

Well without vGrid you would need to ensure all your data fit within the tabstops to make sure it stayed aligned. If you did that you could I think use hGrid and draw two vertical line graphics for vGrid look.

I don't think I understand. Isn't drawing vertical lines what vGrid does?

[monte]

I don't think I understand. Isn't drawing vertical lines what vGrid does?

Yes, what I'm saying is it appears to be easy to give you the behavior you want as long as you leave vGrid off. If you need the vGrid look that's what the graphic lines would be for. Turning vGrid on messes with it and from what @runrevmark said I think to resolve that would require some substantial refactoring of paragraph layout.

[FourthWorld]

Hmmmm...I'd have to consider the implications.

Let me complicate this further: in the use case I need this for, the field needs to contain multiple fields interspersed with regular paragraphs. Moreover, each of the table sections need to have their own column widths.

Does that much up the possibility of a quickie solution?

[monte]

Does that much up the possibility of a quickie solution?

There's already a paragraph level tabStops property so it should work fine.

[LCMark]

@FourthWorld:

I 'm glad you're confident about it. I'm still digesting the implications of Mark's post.

Hehe - sorry - I did go off on a tangent slightly... It was a essentially a brain-dump of my thought process in how an option to turn on and off handling of explicit line-breaks.

So, to summarise and condense what I said above back to what you were originally asking:

• There is no longer any reason for the current behavior of setting dontWrap to false in a listBehavior field - i.e. you should be able to turn it off and on. That's easy to fix.
• I can see no issue with introducing a property to control whether VT is treated as an explicit line breaks (something like allowExplicitBreaks) since it fits naturally into a generalized process for breaking (which was what most of the verbiage in my above post was about). This wouldn't be too hard to add.
• I can see no issue with separating wrapping from explicit breaking - explicit breaking is step (1) of the process above, wrapping is step (2) to (3) and they are logically independent processes. This again is relatively easy to achieve.
• I think it would be better the display of control characters (such as VT, TAB, LF, CR etc.) were done with a 'showNonPrintableChars' property rather than as a side-effect of the OS happening to render glyphs for those chars (which only happens, I believe on Mac generally). [ This is perhaps a little trickier to implement - however, if I read between the lines, it seems that this isn't important for the project you are talking about, but more for the ability to see the content of strings in coding contexts more easily (such as the message box) ]

So this would give you listBehavior fields in which individual rows could have explicit line breaks in them...

This, then leaves us with the issue of vGrid working at the very least with explicit breaks. Now with this, I can definitely see an implementation strategy for MCLine (which is essentially the representation of a broken/wrapped paragraph) that will enable us to support this (and more besides, such as right-to-left languages) - however, since this would involve rewriting MCLine, this is quite a big thing to engineer. The question that has been floating around in my mind since my last post is whether it would be possible to get explicitBreaks to work in vGrid context in the current architecture - the answer is possibly... I need to do some more staring at the code.

[FourthWorld]

Hehe - sorry - I did go off on a tangent slightly... It was a essentially a brain-dump of my thought process in how an option to turn on and off handling of explicit line-breaks.

You never need to apologize for erring on the side of completeness. In the absence of being able to have these conversations with you at the pub, this is a welcome second.

[*]There is no longer any reason for the current behavior of setting dontWrap to false in a listBehavior field - i.e. you should be able to turn it off and on. That's easy to fix.
[*]I can see no issue with introducing a property to control whether VT is treated as an explicit line breaks (something like allowExplicitBreaks) since it fits naturally into a generalized process for breaking (which was what most of the verbiage in my above post was about). This wouldn't be too hard to add.
[*]I can see no issue with separating wrapping from explicit breaking - explicit breaking is step (1) of the process above, wrapping is step (2) to (3) and they are logically independent processes. This again is relatively easy to achieve.
[*]I think it would be better the display of control characters (such as VT, TAB, LF, CR etc.) were done with a 'showNonPrintableChars' property rather than as a side-effect of the OS happening to render glyphs for those chars (which only happens, I believe on Mac generally). [ This is perhaps a little trickier to implement - however, if I read between the lines, it seems that this isn't important for the project you are talking about, but more for the ability to see the content of strings in coding contexts more easily (such as the message box) ][/list]

So this would give you listBehavior fields in which individual rows could have explicit line breaks in them...

Wonderful! By Tuesday then?

This, then leaves us with the issue of vGrid working at the very least with explicit breaks. Now with this, I can definitely see an implementation strategy for MCLine (which is essentially the representation of a broken/wrapped paragraph) that will enable us to support this (and more besides, such as right-to-left languages) - however, since this would involve rewriting MCLine, this is quite a big thing to engineer. The question that has been floating around in my mind since my last post is whether it would be possible to get explicitBreaks to work in vGrid context in the current architecture - the answer is possibly... I need to do some more staring at the code.

Would it simplify things to get that working without Unicode first, and do a more complete implementation later? I respect that Unicode is critically important for many developers, but the engine is adding Unicode support in phases so perhaps that wouldn't be so bad?

[LCMark]

Would it simplify things to get that working without Unicode first, and do a more complete implementation later? I respect that Unicode is critically important for many developers, but the engine is adding Unicode support in phases so perhaps that wouldn't be so bad?

Well, the restructuring of MCLine would enable right-to-left language support to be implemented - it would be something that could be plugged in subsequent to getting the new implementation working. Apart from that, Unicode has no impact on the difficulty of either getting the current implementation to allow explicit breaks in cells, or the restructuring of MCLine.

[FourthWorld]

Would it simplify things to get that working without Unicode first, and do a more complete implementation later? I respect that Unicode is critically important for many developers, but the engine is adding Unicode support in phases so perhaps that wouldn't be so bad?

Well, the restructuring of MCLine would enable right-to-left language support to be implemented - it would be something that could be plugged in subsequent to getting the new implementation working. Apart from that, Unicode has no impact on the difficulty of either getting the current implementation to allow explicit breaks in cells, or the restructuring of MCLine.

So Tuesday is a reasonable expectation for a first-pass implementation?

Or in more practical terms: Since you seem to agree on the usefulness of this enhancement, what might be a reasonable expectation in terms of implementation timeline?

I know you're up to your armpits in a hundred other tasks, and I wouldn't expect this to take priority unless it were convenient to fold into something you're already working on.

[LCMark]

@FourthWorld:

So Tuesday is a reasonable expectation for a first-pass implementation?

Well it seems @monte is quite up for doing some of what's been discussed (and I'm happy to help where I can, as always)...

Or in more practical terms: Since you seem to agree on the usefulness of this enhancement, what might be a reasonable expectation in terms of implementation timeline?

That I cannot say - I might be able to find some time to at least look into what it would take (and if it would be possible without jumping through hoops!) to get the current architecture to bend to vGrid + explicit line breaks and post my thoughts here...

[monte]

Yeah I'm happy to do it up to the point of re-implementing MCLine which is much better left to the people paid for the pleasure

[LCMark]

Yeah I'm happy to do it up to the point of re-implementing MCLine which is much better left to the people paid for the pleasure

Hehe - that's fair enough

The field object is a bit of a beast - I'm sure its at least a small part of why I have less hair now than I used to