Passing userdata to callbacks

Pick 'Em
Monday Night
Survivor

[Htbaa]

A neat feature for me would be that when using callbacks I'd have the possibility to pass userdata (of the type Object) to the callback.

Something like this:

Code:

SetCallBack(func(gadget:ifsoGUI_Base, id:Int, data:Int, iMouseX:Int, iMouseY:Int, userData:Object), userData:Object = Null)

So when doing this:

Code:

Local stream:TStream 'Just an example, could be anything
window.SetCallBack(myCallBack, stream)

I'd be able to work on the stream data passed to the callback. Why would I need this? Well, imagine an editor of some sort. About 10 gameobjects of the same type are on screen, clicking on them opens a window which allows me to edit properties of the object directly. For all I care for every object a property window could be open. When doing this I figure I can't use the "traditional" event queue. So when using callbacks I'd like to pass this object to the callback so I can modify it from the callback.

I understand this changes the callbacks' signature which can be a pain for those who are already using it. However, it does enable you to directly interact with an object and gives great flexibility.

[TaskMaster]

I do a similar thing with my editor where events are passed and I want them act on a selected gadget.  But, I just keep track of the selected gadget.

I bet you could cheat and get the address of your object and put it into the data field (integer).  Then, in your callback function, convert that integer back to an object address.

[Htbaa]

But when using HandleFromObject() I have to manually call Release on it afterwards, which is not what I want. It's going to be a pain to manage all those memory pointers. So I prefer an extra parameter of the type Object that can be used to pass userdata.

[TaskMaster]

OK, just got to thinking about this a little more.

You are setting the object to be passed for the Window's callbacks.  You could easily just put that stream in the window's property tree using SetProperty.

Then when you get an event, just use GetProperty to get the Window's stream.

[Htbaa]

I think that'll do :-) Didn't knew it existed, haha.

[TaskMaster]

I think that'll do :-) Didn't knew it existed, haha.

It was added in v1.05.  I think it was requested by Samah.

[Htbaa]

I've only be using ifsoGUI since 1.11

A big-ish problem for me is that most documentation is on the wiki. Not that the wiki is a bad format, but I'm used to have the documentation BlitzMax style like the rest of the BlitzMax modules. I wonder though, isn't it a bit of a pain to keep the wiki up to date with the modules?

[TaskMaster]

I've only be using ifsoGUI since 1.11

A big-ish problem for me is that most documentation is on the wiki. Not that the wiki is a bad format, but I'm used to have the documentation BlitzMax style like the rest of the BlitzMax modules. I wonder though, isn't it a bit of a pain to keep the wiki up to date with the modules?

Yeah, but I figured people would want it.  Since it is done, all I have to do is update it for the small changes that get made, so not that big of a deal.

What would need to be done to the ifsoGUI source to make it do BlitzMax documentation style?

[Htbaa]

For example you might want to take a look at one of my modules: http://github.com/Htbaa/xmlrpc.mod
If you put a intro.bbdoc (http://github.com/Htbaa/xmlrpc.mod/blob/master/doc/intro.bbdoc) in the doc folder of every module (extended gadgets) then you could put  specific module info in there, just like you do on the wiki.

I'm not saying you should move the documentation to it, but it would be neat if it was included. The biggest pro is that documentation will be automatically generated. I'm not sure how these wiki's work (I never tried editing a page) but keeping it all together seems like a lot of work. But then again, most of it is in it already :-).

[TaskMaster]

For example you might want to take a look at one of my modules: http://github.com/Htbaa/xmlrpc.mod
If you put a intro.bbdoc (http://github.com/Htbaa/xmlrpc.mod/blob/master/doc/intro.bbdoc) in the doc folder of every module (extended gadgets) then you could put  specific module info in there, just like you do on the wiki.

I'm not saying you should move the documentation to it, but it would be neat if it was included. The biggest pro is that documentation will be automatically generated. I'm not sure how these wiki's work (I never tried editing a page) but keeping it all together seems like a lot of work. But then again, most of it is in it already :-).

The ifsoGUI source has the bbdoc: and about: stuff in it already.  Does there have to be a intro.bbdoc file?  Is that all that is missing?

[Htbaa]

Only for every gadget/module I suppose. Each gadget has it's own events ImageButton uses others than FileSelect for example. This is the kind of stuff that could go into a module specific intro.bbdoc.

In the intro.bbdoc for ifsogui.gui I'd mention the events as described here: http://wiki.ifsogui.com/index.php/Events. Or use bbdoc also on constants so they show up in the documentation. Like this:

Code:

Rem
bbdoc: Event mouse down
End Rem
Const ifsoGUI_EVENT_MOUSE_DOWN:Int = 7

My IDE (BLIde) pops them up with auto-complete but not all IDE's have that. And when no internet connection is available checking a Wiki is going to be though.

[TaskMaster]

Hmmm, I think it will take a bit more understanding of the bbdoc system.  I will add it to my todo list.

If life would quit getting in the way, I could get some of this stuff done. 

[TaskMaster]

All of the modules now create documentation.  99% of the Functions/Methods are documented.  There could be some more documentation in some of the files, but what we have now is better than nothing. 

[Corum]

All of the modules now create documentation.  99% of the Functions/Methods are documented.  There could be some more documentation in some of the files, but what we have now is better than nothing.  

Uh?! Maybe written in the wrong thread, but sweet news anyway!
Waiting for updated library files.
Cheers!

EDIT: Oops. You were talking about wiki docs. Sorry.