[ANN] SSG_ListBox 1.0

Summary
SSG_ListBox is a replacement for the Xojo ListBox. It is not a subclass, but a full replacement, written entirely in Xojo. It implements many of the key features of the Xojo ListBox and will implement the rest of them in future releases. There is a demonstration video on YouTube. SSG_ListBox was developed with Xojo 2012r2, and works nicely with both Xojo and Real Studio 2012r2.1.

Current Key Features
• Display: Customizable border and grid, cells. Solid color background. Picture background, stretched and tiled. Custom background via event handler.
• Scrolling: Pixel and cell based.
• Selection: Single row, multiple row, single column, multiple column, single cell, multiple cell.
• Tags: Row, column, and cell.
• Sorting: By columns, plus event to get cell values for sorting.
• Performance: 2000 rows, no problem, not a memory hog. 64 column limit can be increased by changing a constant.

Read our API documentation (pdf).

Future Features
• Drag and drop rows, columns, cells.
• User column resizing by dragging vertical gridlines or heading resize tabs.
• Hierarchical listbox.
• Editable text, checkbox, and progress cell types.

Availability and Pricing
SSG_ListBox is included as part of Studio Stable Graphics, a license for which is which is available for $69.95 from StudioStable.com. The license purchase comes with full source Xojo code to SSG_ListBox, and includes updates for as long as we support the product. The source code license is restricted. You may, of course, use the source in your own projects. You may not sublicense, create derivative source code works, or otherwise redistribute the source code. Source code for the Studio Stable Graphics plugin is not included. SSG_ListBox uses this plugin for image resizing. Pre-built demonstration apps for Mac, Windows, and Linux, as well as API documentation, will be available for free download from our download page.

Got Questions?
This is a great place to ask!

Could you add these functionalities

  1. Column reorder by mouse dragging of column header
  2. Setting visible / invisible of rows or allowing row height to zero
  3. changing Header height

Column reordering/manipulation is something I really miss on the standard Listbox.
I also opened a FR for that: <https://xojo.com/issue/23842>

Column reordering is a great idea, both programmatically and via dragging. So is setting the header height (and font and size) separately from body row height. I have put these on the list for my next batch of features.

What’s the use of setting row height to zero, rather than just removing the row? Having all rows the same height makes scrolling simple and drawing very crisp.

I was asking for the feature row visible or invisible. If that is not possible then make the row height to zero so that the row wont be visible.

why did u want to hide the row??

[quote=26829:@KMEFIC Kuwait]I was asking for the feature row visible or invisible. If that is not possible then make the row height to zero so that the row wont be visible.
[/quote]

I think I understand what you’re asking for. It makes the basic functionality (drawing and scrolling) more complicated. So I’m trying to figure out why you want to do this and if there might be a way to accomodate what you’re really trying to do. For example, what if you could “save” a row in some object, remove from list, reinsert later from the saved object? Would that accomplish what you’re trying to do?

its actully a user request for he want to deselect some rows using check box in the row. then when he needs to show it back. If its very complicated then i will use your approch to save the listbox content to dictionary and show accordingly.

What about variable row height for wrapping text?
Ability to resize row height via horizontal gridlines?
Visual indicators for additional data in a cell (related to above)

An example would be an activity report query. Columns would be Date, Type, Salesperson, Activity. Activity may have a couple of words or several paragraphs. I would like to be able to either autofit the row height based on the largest cell in the row (wrapped text) or give a set row height and have the ability to resize individual rows to wrap the available text.

Another option would be scrolling cells (scrollbar) or via mouse wheel with visual indication (arrowheads).

When do you expect variable width columns to be implemented?

I like the idea of showing one line in the row but the ability to make it multiple line and also indicator to show there are more text in the cell.

Variable height rows… Like I said above, that complicated makes drawing and scrolling. Multiline text is something you can do easily, just like with the Xojo ListBox. Set text/font, then set defaultRowHeight to accomodate multiple rows and padding. Draw each cell in CellTextPaint.

Mouse resizing of columns isn’t done, but variable width columns works great and you can set them to resize proportionally – something you can’t do with Xojo ListBox.

brad, any code to show how can i accomplish that?

With Xojo ListBox, something like this:

[code]dim lst as ListBox

lst.TextFont = “System”
lst.TestSize = 20
lst.defaultRowHeight = 60 // you could make a more accurate guess

Event CellTextPaint(g as graphics, row as integer, column as integer, x as integer, y as integer) as boolean
g.DrawText(x, g.textAscent, g.width - x) // assumes 3 lines.
end event[/code]

so the text which is wider that the column width will be wrap??

How i do it in the xojo listbox is manually wrap the text into a string array ( one line per array element) respecting embedded line brakes, calculate the lines that will fit into the space and draw each line separately (which lets me control ling spacing and handle justification if need be)… if there is more text than space i put an ellipsis on the last line so indicate more text.

wow…sound cool

That is how I do it in my mergable Cell listbox as well.

Writing a routine that that takes a string a graphics object, text and width , and outputs a string array is a very usual utility.

The problem with setting a default row height is all the wasted space for rows that don’ t need it. Think 17 rows that only need one line and 3 rows that need 12. You end up with 240 lines in height where you only need 53.

I use the same same system as Karen for print previews and printing. Having an array makes justification trivial.

karen… never done that before… would love to do more with listbox.

Peter, I get that. What we have here is conflicting requirements. when rows and dividers are all the same size, drawing, calculating bounds, scrolling, etc. on the y-axis are (using this term loosely, CS majors, note the quotes) “O(1)” operations. When rows can be arbitrary heights, these operations become “O(n)” operations. Even if you cache intermediate sums, they still end up being “O(n)” operations (amortized) if you have any dynamism in your list contents. Probably not a perceptible problem for 50 or 100 rows. But scaling could be rough. Needless to say, it’s a feature request that goes to the fundamentals of what a list box needs to do, not just an add-on feature.