Re: [Foxgui-users] Rendering issue with Buttons/Checkboxes as FXTableItems

[JVZ <je...@fo...>]

On Tue, 24 Jan 2017 07:38:22 -0500
Scott D'Vileskis <sdv...@sg...> wrote:

>Greetings--
>Item 1)
>I'm experiencing a rendering problem when subclassing FXTableItem to 
>place Buttons and/or Checkboxes into an FXTable. If I have more cells 
>than will fit in a window (e.g. 10 rows in a window big enough for only 
>7) and I scroll with the scroll bar, some of the the button/check cells 
>get overlapped and out of alignment with the rest of their rows. I 
>apologize I'm unable to post a screenshot of what I'm referring, but It 
>seems only a subset of the cells get a call to the drawContent() method. 
>If I have a larger table with ~100 rows with each button numbered, I see 
>buttons labeled as 0,1,several obscured, 8,22,27,37,78,79,then 87-100 
>rendered properly, but not aligned with the columns.
>Similarly, if my button cells are in the last column, and I scroll 
>horizontally left to obscure part of a rendered button table item, the 
>table item gets snapped to the edge of the table and overlaps the 
>adjacent text columns. If I scroll to the right, clipping seems to be 
>applied correctly.
>
>I'm creating a ButtonTableItem by passing in an FXButton as follows:
>
>ButtonTableItem::ButtonTableItem(FXButton *obj, void *userData): 
>FXTableItem(FXString:null, 0, userData), button(obj) {
>//In the constructor, I save off my button's target and ID and remap 
>them to the table item's
>//so I can rethrow button's SEL_COMMAND event as if it came from the 
>derived TableItem instead of the FXButton
>}
>
>I'm overriding the drawContent(const FXtable *table, FXDC &dc, FXint 
>x...) method and simply calling
>button->position(x,y,w,h) to render it.
>
>In drawContent(), I added some debug output to print the x,y,w,h, as 
>well as the dc's clipV/Y/Height/Width. I'm not entirely sure how I might 
>utilize the other data available to me (e.g. drawing context's clip 
>properties); However, It seems that when I grab the scroll bar and 
>scroll the image, only a few of the cells actually get a call to 
>drawContent, and the cells that haven't been clipped seem to stay in 
>place, while clipped cells seem to snap to the bottom or top, without 
>regard for the row's actual offsets
>
>Item 2)
>We are currently using Fox 1.6.51, though a migration to 1.7.x is 
>planned at some point. There have been many bugfixes to the 1.7.x 
>codebase; What migration concerns will we have migrating from 1.6 to 
>1.7? Obviously this depends on the classes and methods we are using in 
>1.6, but is 1.7 expected to be a drop in replacement for 1.6?
>
>Item 3)
>Do you have a suggestion for adding tooltips to an FXTable, either on a 
>cell-by-cell basis, or perhaps just the row/column headers? We've been 
>able to add context menus, and override double click handlers in some of 
>our table implementations, but I'm not exactly sure where to start 
>regarding tooltips.
>
>Thank You in advance for continuing to support this toolkit!
>
>-- 
>Scott D'Vileskis

1)

When you make subclassed FXTableItem, you can overload the drawing
and metrics calculations, and/or the control to edit it:

a) Redefining the "look" of a cell only, override:

	draw(), drawBorders(), drawContent(), drawBackground(),
	or maybe drawPattern().

	Most people would want to override drawContent(), or maybe
	just drawBackground().

	If the size of the content of a cell will be calculated differently,
	(due to the way it looks), you will probably want to override

	FXTableItem::getWidth() and FXTableItem::getHeight() as well; the
	default implementations calculate the dimensions of a cell based on
	the cell-layout options, text and icon within the cell, and so on.

b) Redefining the way a cell is edited is done by overriding:

	getControlFor() and setFromControl() member functions.  The getControlFor()
	of the FXTableItem is called when the cell is about to be edited; it creates
	a widget to be used for setting the cell's value.  Normally, this is an
	FXTextField widget.

	The setFromControl() API is used to collect the data from the control used to
	edit the cell, and populate the cell with this information.

Its important to keep in mind that FXTable, at any point in time, has at most one 
edit-control active.

As you scroll the table, this control is moved to stay above the appropriate cell.

To recap, table items are not widgets, this is good in the sense that you can have
a lot of them without usurping a lot of window handles.  Its bad in that you can 
only place widgets over them while the cells are being edited.

2)

Moving up to 1.7 will require some work, but its not a *lot* of work.  Some things
have been renamed for clarity, a few API's are changed, however.  Most importantly,
time is now defined in terms of nanoseconds; also, there are more non-GUI features
such as parallel programming support, JSON and XML parsing, and more.

3) 

In 1.7, FXTable implements SEL_QUERY_TIP message handler, which you can of course
catch to provide a custom tooltip; FXTableItem also supports a getToolTip() API
to return a per-item tooltip.


Hope this helps,

				-- JVZ


	

+----------------------------------------------------------------------------+
| Copyright (C) 13:30 01/24/2017 Jeroen van der Zijp.   All Rights Reserved. |
+----------------------------------------------------------------------------+