Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>LINQ to XML is indeed the way here:</p> <pre><code>var textArray = topElement.Elements("L") .Select(x =&gt; x.Value) .ToArray(); var text = string.Join(" ", textArray); </code></pre> <p>EDIT: Based on the comment, it looks like you just need a single-expression way of representing this. That's easy, if somewhat ugly:</p> <pre><code>result = (from indexentry in source.Elements(entryLevel) select new IndexEntry { EtiologyCode = indexentry.Element("IE") == null ? null : indexentry.Element("IE").Value, //some code to set other properties in this object Note = string.Join(" ", indexentry.Elements("NO") .Descendants() .Select(x =&gt; x.Value) .ToArray()) }; </code></pre> <p>Another alternative is to extract it into a separate extension method (it has to be in a top-level static class):</p> <pre><code>public static string ConcatenateTextNodes( this IEnumerable&lt;XElement&gt; elements) { string[] values = elements.Select(x =&gt; x.Value).ToArray(); // You could parameterise the delimiter here if you wanted return string.Join(" ", values); } </code></pre> <p>then change your code to:</p> <pre><code>result = (from indexentry in source.Elements(entryLevel) select new IndexEntry { EtiologyCode = indexentry.Element("IE") == null ? null : indexentry.Element("IE").Value, //some code to set other properties in this object Note = indexentry.Elements("NO") .Descendants() .ConcatenateTextNodes() } </code></pre> <p><strong>EDIT: A note about efficiency</strong></p> <p>Other answers have suggested using <code>StringBuilder</code> in the name of efficiency. I would check for evidence of this being the right way to go before using it. If you think about it, <code>StringBuilder</code> and <code>ToArray</code> do similar things - they create a buffer bigger than they need to, add data to it, resize it when necessary, and come out with a result at the end. The hope is that you won't need to resize too often.</p> <p>The <em>difference</em> between <code>StringBuilder</code> and <code>ToArray</code> here is what's being buffered - in <code>StringBuilder</code> it's the entire contents of the string you've built up so far. With <code>ToArray</code> it's <em>just</em> references. In other words, resizing the internal buffer used for <code>ToArray</code> is likely to be cheaper than resizing the one for <code>StringBuilder</code>, <em>particularly</em> if the individual strings are long.</p> <p>After doing the buffering in <code>ToArray</code>, <code>string.Join</code> is hugely efficient: it can look through <em>all</em> the strings to start with, work out <em>exactly</em> how much space to allocate, and then concatenate it without ever having to copy the actual character data.</p> <p>This is in <a href="https://stackoverflow.com/questions/585860/string-join-vs-stringbuilder-which-is-faster/585897#585897">sharp contrast to a previous answer I've given</a> - but unfortunately I don't think I ever wrote up the benchmark.</p> <p>I certainly wouldn't expect <code>ToArray</code> to be significantly slower, and I think it makes the code simpler here - no need to use side-effects etc, aggregation etc.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload