News : The level of daily SPAM has reached insane proportions, all registrations are now manual. I ask you to send me an e-mail (john (at) murga (dot) org), to confirm that you want me to create an account for you.


Post Reply  Post Thread 
Clearing up an incorrect asumption ...
Author Message
JohnMurga
Administrator
*******


Posts: 381
Group: Administrators
Joined: Apr 2007
Status: Offline
Reputation: 2
Post: #1
Clearing up an incorrect asumption ...

Hi,

A while ago Juergen posted the following :

Juergen Wrote:
I didn't look into the code, but when I saw the double quotes in the original example it looked like you are compiling a binary chunk and calling it later.

I have an alternative suggestion. A few weeks ago I did a small user_data replacement implementation in pure Lua:

Code:
Fl_Button.udata={}


Fl_Button.user_data_old=Fl_Button.user_data

function Fl_Button:user_data(...)
local arg={...}
if #arg<1 then return self.udata[self]
   else self.udata[self]=arg[1]
end
end


It is simple, works with all values (also functions or tables). I guess it isn't hard to do it in C++ with some metatable magic and hide the table somewhere.

Juergen


I wanted to clear this up, as it is potentially very dangerous ...

When you reference "self" in this way for murgaLua FLTK objects you are referring to the "UserData" that represents the instance of the Object you are looking at. The problem is that in murgaLua I use lightweight versions that just provide a reference back to the original instance ...

Note that I said they "provide" as reference as to "being" a reference, the difference is important, as Juergen is assuming that every time he gets his hands on the same widget the "self/UserData" will be same ... But it most likely won't ...

The underlying reference will be, but the "UserData" that provides it won't be.

I am surprised someone hasn't realized this doesn't work, as under any kind of strain this kinda code would break.

However, I understand what Juergen is trying to do, and it is actually a very good idea, with this in mind I have provided a "serial()" method, that returns a representation of the underlying reference and CAN be used as uniquely identifying key for a widget table.

The new menu example shows the UserData behaviour I have described here, as well as the use of the "serial()" method.

As for extending widgets ... I'll write a tutorial soon ;-)

Cheers
JohnM

This post was last modified: 02-27-2008 08:29 AM by JohnMurga.

02-27-2008 08:23 AM
Visit this user's website Find all posts by this user Quote this message in a reply
Post Reply  Post Thread 

Messages In This Thread
Clearing up an incorrect asumption ... - JohnMurga - 02-27-2008 08:23 AM

View a Printable Version
Send this Thread to a Friend
Subscribe to this Thread | Add Thread to Favorites

Forum Jump: