FLTK logo

STR #3018

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features | Roadmap 1.3 | Post Text | Post File | SVN ⇄ GIT | Prev | Next ]

STR #3018

Application:FLTK Library
Status:4 - Pending
Priority:3 - Moderate, e.g. unable to compile the software
Scope:3 - Applies to all machines and operating systems
Subsystem:Core Library
Summary:Selects unclicked cells/rows/cols in the Fl_Table.
Version:1.3-current
Created By:kdiman
Assigned To:greg.ercolano
Fix Version:Unassigned (SVN: v10104)
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]
Name/Time/Date Filename/Size  
 
#1 kdiman
13:18 Dec 15, 2013
Fl_Table.patch
1k
 
     

Trouble Report Comments:

Post Text ]
Name/Time/Date Text  
 
#1 kdiman
13:18 Dec 15, 2013
Dear devs.

I have patch for the Fl_Table, which is
correcting next errors:

1) If a cell will have Fl_Choice widget, and you click
on 2/3/5/last ? items of that, you get selected rows
or cols without clicking on them.

2) Some my cells has hidden widgets such as Fl_Calendar,
(with called method's override()) and when I am clicking
on the cell for show the calendar, then is happpening
FL_DRAG event by which selects other cells.


The patch is attached.

link on video with problem (good quality):
https://www.youtube.com/watch?v=17MNHAFi9JA

--
regards.
 
 
#2 greg.ercolano
22:37 Feb 15, 2014
Assigning to me to investigate, assigning to core..  
 
#3 greg.ercolano
01:24 Feb 16, 2014
Applied the patch to SVN r10104. (Some code reformatting and comments refer to this STR)

In case this STR is reviewed in the future and the youtube video no longer available:

For item #1, it seems that with an Fl_Choice, if one navigates its menu in such a way
that on release, the mouse ends up being over a header (row or column), a complete
row or column selection will occur (as if one clicked the row/col header).

For item #2, if one has an Fl_Table which shows the selection state of its cells,
one can drag out a selection even if one double-clicks to initiate the drag,
arguably it shouldn't change the selection unless the drag starts with a single click.

More might be needed here:
I think in the case of item #1, an FL_RELEASE over the headers will still trigger
Fl_Table's callback() (e.g with a CONTEXT_XXX_HEADER context) which it probably shouldn't.
Any kind of FL_RELEASE that wasn't started with an FL_PUSH on the table should be ignored.
 
 
#4 ianmacarthur
03:11 Sep 05, 2014
Are we in a position to close this one?  
 
#5 greg.ercolano
16:38 Oct 27, 2014
@Ian: I think the last paragraph of comment #3 is reason to leave this open, as it's related.  
 
#6 greg.ercolano
16:42 Oct 27, 2014
I don't think this should hold up 1.3.3 release,
as the important bits from the OP have been addressed.

Therefore, lowering the priority from 4 -> 3
to allow release of 1.3.3 with this open (as per the CMP).
 
     

Return to Bugs & Features | Post Text | Post File ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.