In my program (for Windows) I display log information in a TListBox. But that has some severe drawbacks/bugs:

1.) If one of the displayed strings exceeds the right margin there is no horizontal slider to shift the text to the right so the user can see the invisible text.

2.) If the number of rows exceeds the height of the TListBox window there is a vertical slider to move up and down. But for certain widget-sets (recently applied to our workstations at work) this slider is not displayed. Instead, some remnant from previously displayed text appears in the place where the slider should be (if you guess where the slider is, it still works but it looks ugly and is awkward).

So I decided to switch to TStringGrid (with one column). This *has* a slider in case the right margin is exceeded. It is also much more flexible as I can add columns easily if needed. But now I still cannot move the (one and only) column to make text on the right visible, even though the slider is there! Is that a bug too?

I am stuck again. How can I make long (wide) text visible in a restricted window?

J?rgen Hestermann wrote

I am stuck again. How can I make long (wide) text visible in a restricted window?

Use a TMemo, and set its ScrollBars property to ssAutoBoth?

Okay, yet another approach. I will try it. Thanks. Though each change of object type requires me to apply all the anchor settings of all visible objects in the form again, because most of them are anchored to the list. Quite a lot of work.

Still I am wondering why nobody seems to miss a horizontal shift for TListBox and TStringGrid (especially because a slider is shown for TStringGrid but does not work). Are these bugs which nobody discovered since years? I can't believe it.

TListBox is based on the underlying OS widget for each platform, and offers the common features of the supported widgetsets (any restrictions are noted on the Restricted page of the Object Inspector). Lack of a widgetset feature is simply that: a missing feature in the widgetset. It is not a Lazarus bug.
Another alternative to provide scrolling for components that do not have it built-in, is to place the component on a scrolling container which is what TScrollBox (Additional page of the component palette) is designed for.

In a proper design it should be a matter of enabling the scrollbars of the component, and specifying the virtual (full) extent of the component. See e.g. TScrollBox. When a component doesn't have implemented such functionality, you can wrap it into a TScrollBox, and set its virtual extent to the actually required width and height.

AFAIR Windows and Delphi only offer multi-column listboxes, where the listbox items are arranged in grid style, with a row count according to the component height, and excess items shown in additional (scrollable) columns. This won't help in your case, though.

DoDi

--- El mi? 24-abr-13, J?rgen Hestermann escribi?:

Do you know if is there a bug report about it?, if not, please feel free to submit one (I'm talking about the TStringGrid).

Jesus Reyes A.

As others told me these are all limitations of the underlying widgetset (in this case Win32 GUI) so it cannot be fixed within Lazarus.

TMemo solves my problem for now (thanks again to Howard for the tip). And another tip was TScrollBox which I did not test yet but will try together with TStringGrid if I need more than one column of text.

But AFAIK one can enforce a horizontal scroll bar for a list box. This can be seen here for example:
http://www.delphitricks.com/source-code/components/show_a_horizontal_scrollbar_in_a_listbox.html So one might need to adjust the TListBox implementation to support this as well (and I simply assume for now that the other widgetsets also support a horizontal scrollbar in a list box...).

Regards,
Sven

Afair in lazarus TListBox.ScrollWidth := Canvas.textWidth(longeststring)
works (at least with qt widgetset).

z.

I looked at the code. The Win32 implementation does exactly what is mentioned in the link and an GTK2 implementation exists as well. Only Carbon does not seem to be implemented.

So for the majority of the widgetsets this seems to be implemented already.

Regards,
Sven

El 25/04/2013 7:10, J?rgen Hestermann escribi?:

Hello,

Or use a ListView (in report mode) or set the ListBox "ScrollWidth" property to the length of largest string, ...

I think I played already with this but nothing changed (I set TListBox.ScrollWidth to arbitrary high values).

And even if it works, would I have to scan all string widths after each change to find the widest string and then set TListBox.ScrollWidth to it? That would be very awkward.

El 25/04/2013 17:01, J?rgen Hestermann escribi?:

Hello,

That's exactly what the operative system do in autosize columns, but usually only in additions, so you only store the largest one and the one that would add, if the new one is larger, scroll is adjusted, if smaller, nothing is done until a full autosize is requested.