HLC cannot work without a height. You must either assign one (hlc.setHeight), or the parent layout must assign one (VerticalLayoutData must have a non -1 height). Other parent container can assign a height on their own.
This is by design, due to how the HLC works. Both HLC and VLC are built to a) assign height and width to all children, so it must b) be given a height/width by the parent.
As mentioned in another thread recently, you may be able to use the CssFloatLayoutContainer here in place of the HLC - it sounds like you want *only* widths assigned, some fixed percentages to use up the whole width, or perhaps let each child be given a certain amount of space (and so should wrap if there isnt enough room). Heights may not be assigned with the CssFloatLC, which seems to be what you are after.
I was hoping to use HBoxLayoutContainer, and when that wasn't working, I was thinking I should try this. Sounds like GXT 3.0.3 will fix a defect in HBoxLayoutContainer and then I should be able to use that. For now, I'm using GWT's HorizontalPanel and that seems to be rendering just fine. I am trying to address other issues mixing components, but there doesn't seem to be an issue here using the GWT component.
HBoxLC does indeed have a defect, which we've determined the fix for. HBoxLC is the superclass of ToolBar and ButtonBar, so as a widget, it needs to be capable of drawing without a width assigned (and only should consume the height of its contents in those cases, else it wouldn't be a very effective toolbar/buttonbar).
In order to do its work, with all of the options it can be given, HBoxLC and VBoxLC has to make two passes, measuring all items both times, and modifying various sizes (causing a reflow) between them, as well as setting sizes at the end. HBoxLC optionally can take a third pass. These Box layouts take only the child a bit of layout config information, but otherwise read sizes from the dom, expecting children to have sizes already.
HLC makes one or two passes, depending on your configuration, and *only* reads sizes from -1 elements in the first pass, and writes sizes/positions to each element on the second pass. It isn't nearly as configurable - it either works, or it doesn't - and is only intended to function correctly when given a size. It can handle percentages, or pixels, or can ask the child for its size if needed, so fulfills a different purpose than HBoxLC.
GWT's HorizontalPanel is closer to HBoxLC - limited ability to specify arbitrary sizes, but on the other hand works bottom-up - it assumes that the children have sane sizes, and work from there to take up its own space.
I am not aware of plans to modify HLC from its current behavior - and from the sounds of your case, HBoxLC, CssFloatLC, or GWT's HorizontalPanel are more correct. HBoxLC and the others should be able to support the case where it has no size, but HLC really isn't designed to do that.
By the same token, VLC really isn't built to support all children having a height of -1, or a width of -1, but since the HTML/CSS languages are really built for flowing text, we happen to get lucky there, and it doesn't misbehave. It isn't meant to be used that way, but it happens that browsers like stacking blocks on top of each other better than they like stacking them side by side, and getting the right results.