FLTK logo

Article #132: fl_connect 0.9
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 Articles | Show Comments | Submit Comment ]

Article #132: fl_connect 0.9

Created at 07:06 Jan 23, 2003 by ken.yarnall

Yet another FLTK callback API supporting member functions, with an optimally easy interface.

[ Download | Home Page | Listing ]

Comments

[ Submit Comment ]

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

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.

Ken
[ Reply ]

From Ken Yarnall, 07:02 Jan 26, 2003 (score=1)

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

Ken
[ Reply ]

From Ken Yarnall, 06:13 Jan 30, 2003 (score=1)

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 ]

 
 

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