FLTK logo

STR #2980

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 #2980

Application:FLTK Library
Status:5 - New
Priority:1 - Request for Enhancement, e.g. asking for a feature
Scope:2 - Specific to an operating system
Summary:Fl::event_text() returns no meaningful value for FL_DND_ENTER and FL_DND_DRAG on Windows
Created By:jlp2
Assigned To:Unassigned
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]
Name/Time/Date Filename/Size  
#1 jlp2
15:06 Sep 09, 2013

Trouble Report Comments:

Post Text ]
Name/Time/Date Text  
#1 jlp2
15:06 Sep 09, 2013
Using the current FLTK 1.3.2 release, the Fl::event_text() function has no meaningful value for the FL_DND_ENTER or FL_DND_DRAG event under Windows. I'm not sure if this is intended or if it's a bug. I attached a .diff file that shows the changes I made to get the value for these events, too. Maybe someone who knows the code better could verify if this solution is correct.  
#2 ianmacarthur
15:45 Mar 11, 2014
This STR mirrors the OSX STR #2998 also.

I would note that I don't think I'd expect event_text() to have anything useful for a FL_DND_ENTER or FL_DND_DRAG event, I think I'd only expect it to have something useful to read in response to a FL_KEYUP, FL_KEYDOWN, FL_PASTE, and FL_DND_RELEASE.

Can the OP describe what was anticipated?
#3 jlp2
14:00 Mar 12, 2014
According to the documentation, you seem to be right. But I don't really see a reason why event_text() should not give a meaningful value for FL_DND_ENTER or FL_DND_DRAG events. The system provides the value, of course. So I guess it is reasonable to assume that you can access this value using event_text(). This can be useful for an application to give the user feedback on if the dragged content can be handled by the application, while the user is still dragging it over the application (e.g. different cursors for the cases that the DND operation will be accepted or rejected).  
#4 AlbrechtS
03:15 Sep 25, 2014
Reduced priority to 1 (RFE).

The OP confirmed that FLTK works according to the documentation, so this is really a feature request and may be considered later.

Thanks for the report.

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'.