draw_cell Method (Fl_Table)?

[Svets]

Hello again.  

Would anyone be able to tell me whether the context argument in the draw_cell method is provided automatically though dependent on what you specify in your constructor?   I can't see how context is passed?

I'm thinking that if I indicate that I want row_header(1) I have therefore indicated that I want row headers____and then at some stage in a certain sequence, each context will be passed to the context argument (such as CONTEXT_ROW_HEADER, CONTEXT_COLUMN_HEADER, CONTEXT_CELL) automatically?

I put a question mark there because I'm not sure. But I'm assuming it works something like this because I can't figure out how the draw_cell method receives the context argument.  Basically I'm asking, is it passed automatically or do I have to specify each context?   

Thanks

[Dmitrij K]

Date: Thu, 3 Jul 2014 05:03:08 -0700
From: svetlana...@gmail.com
To: fltkg...@googlegroups.com
Subject: [fltk.general] draw_cell Method (Fl_Table)?

>  Basically I'm asking, is it passed automatically or do I have to specify each context?   

Hello.

The `contex' will be inserted by basic draw methods automatically in needed places in the parents classes.
You have to realize drawings for the contexts in the User Method's `draw_cell'.

Greg is author that class, and if hi will have a time you get fully details answer to your question.
Also you can look at fltk-1.3.x/examples/table* sources.

--
the best regards

[Svets]

Thanks, but I'm not sure how ..if it context is provided automatically.. how the context is decided.  If certain draw methods will provide the context value then how does it know the difference between the context_column_header and context_cell and provided the right enum constant when needed. 

[Dmitrij K]

Perhaps it occurs like:

InstructorForDrawingTable { // class Fl_Table
// instructor has number rosw/cols & them w/h, enabling headers etc...

for_each_row() {

UserDoNeedDrawRow(CONTEXT_ROW, x, y, w, h) // call user's method draw_cell

for_each_col() {

UserDoNeedDrawCell(CONTEXT_CELL, x, y, w, h) // call user's method draw_cell

}

}

}

Date: Thu, 3 Jul 2014 19:24:12 -0700
From: svetlana...@gmail.com
To: fltkg...@googlegroups.com
Subject: Re: [fltk.general] draw_cell Method (Fl_Table)?

[Dmitrij K]

You can look at "src/Fl_Table.cxx" in method's int Fl_Table::handle(int event) string ~716

Context sendings by events in `handle' method ...

strings: 747, 765 ...

[Svets]

Thanks for looking at that.  I had a good look at this too and think the context is somehow derived when the row_header() or col_header indicates that there should be a row and column header.  The code then applies row and column header context to context for the first row and column.  

I suppose the main thing here is that I understand that I am not passing the row or column header context myself.  It is in fact generated from the code.  From line 278-305 in the Fl_Table source file this seems to be where row_header context is generated from.   

Anyway, I've pasted that section below just for reference.

Fl_Table::TableContext Fl_Table::cursor2rowcol(int &R, int &C, ResizeFlag &resizeflag) {
  // return values
  R = C = 0;
  resizeflag = RESIZE_NONE;
  // Row header?
  int X, Y, W, H;
  if ( row_header() ) {
    // Inside a row heading?
    get_bounds(CONTEXT_ROW_HEADER, X, Y, W, H);
    if ( Fl::event_inside(X, Y, W, H) ) {
      // Scan visible rows until found
      for ( R = toprow; R <= botrow; R++ ) {
        find_cell(CONTEXT_ROW_HEADER, R, 0, X, Y, W, H);
        if ( Fl::event_y() >= Y && Fl::event_y() < (Y+H) ) {
          // Found row?
          //     If cursor over resize boundary, and resize enabled,
          //     enable the appropriate resize flag.
          //
          if ( row_resize() ) {
            if ( Fl::event_y() <= (Y+3-0) ) { resizeflag = RESIZE_ROW_ABOVE; }
            if ( Fl::event_y() >= (Y+H-3) ) { resizeflag = RESIZE_ROW_BELOW; }
          }
          return(CONTEXT_ROW_HEADER);
        }
      }
      // Must be in row header dead zone
      return(CONTEXT_NONE);
    }

[Greg Ercolano]

> ..if it context is provided automatically..

    Yes, when talking about draw_cell(), the context is provided
    "automatically". See the draw_cell() docs for a list of the
    contexts to expect and what they mean:
    http://www.fltk.org/doc-1.3/classFl__Table.html#a3f1f1ccc017d9159c1c98f6f7268bf6d

    When the widget wants you to draw different parts of the table,
    it calls draw_cell(), passing the context to tell you which part
    of the table it wants you to draw, as different parts of the table
    should be handled differently.

    R + C will be the row and column, XYWH the size of the area
    you should draw over, and the context value will be  (from the draw_cell() docs):

Fl_Table::CONTEXT_STARTPAGE	When table, or parts of the table, are about to be redrawn. Use to initialize static data, such as font selections. R/C will be zero, X/Y/W/H will be the dimensions of the table's entire data area. (Useful for locking a database before accessing; see also visible_cells())
Fl_Table::CONTEXT_ENDPAGE	When table has completed being redrawn. R/C will be zero, X/Y/W/H dimensions of table's data area. (Useful for unlocking a database after accessing)
Fl_Table::CONTEXT_ROW_HEADER	Whenever a row header cell needs to be drawn. R will be the row number of the header being redrawn, C will be zero, X/Y/W/H will be the fltk drawing area of the row header in the window
Fl_Table::CONTEXT_COL_HEADER	Whenever a column header cell needs to be drawn. R will be zero, C will be the column number of the header being redrawn, X/Y/W/H will be the fltk drawing area of the column header in the window
Fl_Table::CONTEXT_CELL	Whenever a data cell in the table needs to be drawn. R/C will be the row/column of the cell to be drawn, X/Y/W/H will be the fltk drawing area of the cell in the window
Fl_Table::CONTEXT_RC_RESIZE	Whenever table or row/column is resized or scrolled, either interactively or via col_width() or row_height(). R/C/X/Y/W/H will all be zero. Useful for fltk containers that need to resize or move the child fltk widgets.

    You must at least handle CONTEXT_CELL, as this draws all the cells in the different
    row + columns.

    You should handle CONTEXT_ROW_HEADER and CONTEXT_COL_HEADER
    if you have headers enabled.

    STARTPAGE and ENDPAGE can be ignored; useful only if there's something you
    want to do before the table starts being redrawn, or after (such as a database
    open/close operation, so you can access table data from a database).

    RC_RESIZE is just a hint that the table is being resized, and can also be ignored.

> I'm not sure how [..] the context is decided.

    As a user of the widget, one shouldn't have to be concerned
    with the inner details of how the context is decided.

    Suffice it to say that when the widget wants to redraw the table,
    it breaks the table up into sections (row headers, col headers, and cells),
    and it calls you draw_cell() method to draw each section, passing you
    CONTEXT_CELL if it wants you to draw one of the cells,
    CONTEXT_ROW_HEADER if it wants you to draw one of the row header cells, etc.

    If you need to visualize what the table might be doing internally,
    consider what Fl_Table is doing is simply managing the UI (scrolling
    and window size), and calls your code to draw the data that needs
    updating.

    Let's say you have a table with 10,000 rows and 10,000 columns.

    So if the user has the table window scrolled to row 100, column 100,
    and due to the size of the window,  20 rows and 10 columns are "visible",
    when Fl_Table wants to redraw that window, it's going to call your draw_cell()
    method to draw only the cells between rows 100..120, and cols 100..110.

    How it knows this, and how it decides which it's drawing shouldn't matter,
    as the complexities of screen management are what the table is meant
    to shield you from having to deal with.

>     >  Basically I'm asking, is it passed automatically or do I have to specify each context?  

    For the case of the draw_cell() method, the context is passed to you.
    Let me know if the docs are somehow not clear on this; it is an input value.
    If it were an output value, it'd have to be a reference argument.

    There are other methods that also use the TableContext values; some examples:

        do_callback() -- the TableContext tells you what part of the table caused the callback
        find_cell() -- you set the TableContext value to tell Fl_Table which part of the table you're querying info for
    etc..

    Hopefully between the docs for Fl_Table and the "examples/table-simple.cxx" you'll understand
    how it works. Fl_Table is an odd widget in that it doesn't manage your data at all, it just
    manages the UI. The reason it doesn't manage the data is tables can be huge, so it's
    better to leave data management to your own code, as you may not even want the
    table's entire data to even be in memory, you might want to pull it from a database
    in realtime, just the data area the user has scrolled to view.

[Svets]

Thank you very much for the help.  I understand now. 

I suppose I just wanted to understand its inner workings as I want to use the table widget allot. Now I have a good grasp.

This will be  a really useful widget, unique too.

I thought the docs were a little unclear on the context argument for draw_cell that's all.   But your explanation has cleared this up well. 

[Greg Ercolano]

On 07/04/14 20:05, Svets wrote:
> Thank you very much for the help. I understand now.
>
> I suppose I just wanted to understand its inner workings
> as I want to use the table widget allot. Now I have a good grasp.

That's a good reason to know it better.

I've done that myself with other widgets I used a lot (like Fl_Browser
back when it was new to me). It helped to look at the code for the widget.
This helped me not only use the widget(s), but also helped me write new ones.

> I thought the docs were a little unclear on the context argument for draw_cell
> that's all. But your explanation has cleared this up well.

Guess I'll try to flesh it out.
I thought I did, but that might have been Fl_Tree..

Both Fl_Tree and Fl_Table are relatively new and somewhat complex
widgets. They're pretty evolved, but they're still going through
a growing process.