FLTK logo

[Stale links 2023-11-11] fl_connect 1.5

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 
 Back To Listings  ]
Name:[Stale links 2023-11-11] fl_connectPopularity:19%
Author:Ken YarnallEMail:yarnall
Created:Jan 23, 2003
Updated:Nov 12, 2023
Home Page:http://cscdev.lvc.edu/fl_connect (6494 visits)
Download:http://cscdev.lvc.edu/fl_connect (3400 visits)

Yet one more callback API for FLTK that supports member functions and exhibits type safety.  You connect a widget to a callback with a call like

   fl_connect(wid, foo, &Foo::cb, dptr);
There are overloads to handle member or non-member functions, and callbacks taking 0, 1, or 2 parameters.  There is also an fl_disconnect() that disconnects a given widget.

The pointers needed to execute the callback are stored in the Widget;  however, no non-compatible changes have been made to Fl_Widget --- the old callback system still works, and interacts nicely with the new system, allowing for easy migration to the new style.

Version 1.3 brings compatibility with fltk 1.1.5rc2.  Also, I applied the new callback system to Fl_Menu_Item, which I'd originally not done.

Also provided is a class, Fl_Timeout, that wraps FLTK's timeout callbacks in an easy to use, typesafe and flexible interface.

Another class, Fl_Idle, provides a wrapper for idle callbacks.  This class is similar to Fl_Timeout, without the concept of repeating or a period.

Fl_Timeout and Fl_Idle require a real C++ compiler (they use member templates); however, they are completely separate from the rest of the patch, so if you don't want/can't use them, simply ignore them.

There is complete documentation via doxygen comments, and a total of 4 test programs to examine. 


Submit Article | View All ]
ID Title Last Modified Comment(s)  
  330fl_connect 1.5Oct 24, 20040  

I've had a report of some difficulty building fl_connect with VC++, even version 7.  It's difficult for me to access this platform, so it's hard for me to identify and fix the problem.  Anyone willing to help (just by trying to compile and sending...

  322fl_connect 1.4Sep 30, 20046  

Version 1.4 is the same as v 1.3, except that it's been built off of fltk 1.1.5rc3.  The web site contains the patch, and prepatched source and rpm files.

  312fl_connect 1.3Aug 22, 20040  

Version 1.3 of the patch that adds a modern, typesafe, member-function-capable callback system.  This version extends the system to Fl_Menu_Item (an oversight before; I was fixated on menu items becoming real widgets in fltk 2.0), and is built agains...

  250fl_connect 1.2Jan 13, 20040  

version 1.2 of fl_connect is available.  This version adds no new functionality, but updates the patch to work with fltk 1.1.4.

  146fl_connect 1.1Mar 03, 20031  

Also, the test code for Fl_Timeout is much improved, and a new test program for Fl_Idle has been added.



Submit Comment ]

From Ken Yarnall, 18:12 Jan 27, 2003 (score=3)

I posted a slightly modified version on the web page this evening.  The documentation is improved, and the files now contain proper copyright and license info.

Reply ]

From Ken Yarnall, 07:01 Jan 26, 2003 (score=3)

The one obvious feature missing from fl_connect is the ability to attach a new "user data" pointer after the initial connection (well, you can do this by just calling fl_connect() again, deleting the old connection and establishing a new one, but that is a little bit of a time waste).

I can add support for this (a function called something like fl_connect_data() or something).  The design I've sketched out would allow you to replace the current pointer, so long as the type of the replacement is compatible with the type established at connection time.

Question is, would anyone need this facility?  I personally don't use the user data pointer;  I find that using a member function as a callback obviates any need for such a beast (extra data I might need is available in the object receiving the callback).

Reply ]

From Ken Yarnall, 06:42 Jan 30, 2003 (score=2)

Oops;  I lied.

It doesn't look like resetting the user_data by itself is plausible (without lots of nastiness that no one would really want), at least not type-safely. 

The problem is that the type of the data is encoded in the derived type of the connection object that the system has stored, but that type is hidden behind a base class.  Getting to it at compile time seems impossible;  the best I could do is detect a type mismatch at runtime and throw an exception.

I'm not going to do that at the moment, of course.  For now, simply re-connect the widget to the same callback, with a new data pointer.  This isn't that expensive.  It will work so long as you know what the callback is when you want to reset the user data.  Again, since I never seem to have use for the user data pointer, I don't really know whether this is bothersome or not.
Reply ]

From Ken Yarnall, 11:14 Feb 13, 2003 (score=2)

I thought this deserved followup, since the implementation has changed so much since I wrote that message.

The user data pointer is now stored in the Widget, and if you call


that will reset the pointer that is passed to the callback next time (if the callback that was set expects to receive a callback;  if not then user_data is ignored).

HOWEVER, this is not typesafe at all.  user_data() doesn't do any type-checking;  it just casts foo to void* and stores it.  If foo is not compatible with the previously set user_data type, then Bad Things will certainly happen.  Cross your fingers and close your eyes.

This is not worse than FLTK's original behavior, nor is it better. 

To keep this from happening, always call fl_connect if you need to reset the data pointer.  I can see situations where this would be undesirable (since you have to pass the callback as well as the widget and the user data, so you have to have all that info available), but there's no way around it that I can see that doesn't require fairly significant overhead.

Reply ]

From Ken Yarnall, 07:11 Mar 07, 2003 (score=2)

Andre Fornacon has created a version of the patch suitable for the efltk fork of FLTK.  There's a link to this patch on the fl_connect web page.

Thanks Andre!

Reply ]


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