[Stale links 2023-11-11] fl_connect 1.5

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.

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

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

wid->user_data(foo);

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.

Ken
[ 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.

Articles

Comments

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

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

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

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

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