We do not want or have text wrapping for the node text.
However, if there is not enough space for the text, it gets moved down underneath the expand symbol.(when expanded) and if collapsed it does not move down but an emply line gets inserted between the collapsed node and the next node underneath it.
Is there a way to prevent this? As we do not want the text to wrap, we simple want the text to remain to the right, regardless of whether it is collapsed or expanded AND without an empty space underneath it?
Thanks.
Hello JJB ,
i'm just following up to see whether you need any further assistance with this issue.
If so please let me know.
Best Regards,
Maya Kirova
Developer Support Engineer
Infragistics, Inc.
http://ko.infragistics.com/support
Hi,
Thanks for the sample. Our situation is quite different in that (for a start) we do not want a horizontal scrollbar, because we have a splitter bar. (implemented using a table and capturing appropriate mouse events, rather than the infragistics control) I'm not sure if the behaviours I reported are simply the result of not having the horizontal scrollbar or caused by some other complexity in our implementation? Are you able to confirm if this behaviour happens in a simple case of disabling the horizontal scrollbar? If not then I will try an isolate the problem.
Regards.
Hello JJB,
It’s indeed related to the scrollbar not appearing. I tested this by setting overflow:hidden for all the items and that reproduces the mentioned misbehavior.
I suggest you wrap the items text in this case. For example by setting a css class for the tree nodes:
.wrap
{
white-space:pre-wrap;
}
Let me know if I can further assist you in any way.
As explained in my first post, we do NOT want wrapping. I want the text to be clipped/truncated at the separator bar, which it is doing but I do not want the behaviours mentioned. Is this an Ingragistics Bug and can it be resolved? I have tried using a horizontal scrollbar but this causes all sorts of other display issues.
Thank you for your patience while I was looking into this.
I found out why the node gets scrolled to the right when you click on it.
It’s related to the Activation changing and more specifically to a call to an internal function _scrollToNode which sets the scroll position. However in your case since you’ve disabled the scrollbars this results in an unexpected result. The easiest way to resolved this seems to be to overwrite this function and just not chnage the scrollbars position in it. For example:
<script type="text/javascript">
$(document).ready(function () {
// debugger;
$IG.WebDataTree.prototype._scrollToNode = function (node, scrollElement) {
var styleEl = node.get_styleElement();
if (styleEl == null) return;
scrollElement.scrollLeft += 0;
scrollElement.scrollTop += 0;
};
});
</script>
Since by default it seems that the WebDataTree needs the scrollbar when there’s an overflow this doesn’t seem to be a bug.
I’m attaching a sample with my suggestion for your reference. Let me know if you have any questions or concerns.
Thanks. That seems a step in the right direction. It resolves the issue with the webdatatree. Unfortunately the tree is within a webexplorerbar group and the group header appears to have the same issue, in that it gets moved to the left off the page.
Do you know if there is an equivalent solution for the webexplorerbar?
I did try copying the above function and replacing $IG.WebDataTree with $IG.WebExplorerBar but that had no affect.
Regards,
Really Its very useful. I applied this CSS for WebExplorerBar to avoid text wraping and its working awesome. Thank you very much Maya Kirova.
The WebExplorerBar uses the same function: $IG.WebDataTree.prototype._scrollToNode
I’ve tested it and the function fires when I select an item from the explorer bar as well . That’s probably because both controls inherit the web navigator and have some functions in common.
I’ve tried to reproduce your scenario by disabling the white space setting for the explorer bar. By default it wraps the text to fit the container. I didn’t notice a misbehavior when I selected ExplorerBarGroup element . I did note a slight scrolling right for the normal ExplorerBarItem when it gets selected which seems to get resolved by adding the overriding for scrollToNode.
Refer to the attached sample and let me know if I’ve missed something from your scenario.