wxlua-users — wxLua list for users and developers

[Wxlua-users] bakefile & /NODEFAULTLIB problem

[Francesco M. <f18...@ya...>]

Hi,
    I've grepped all my wxLua (and wxArt2d) updated CVS repositories and 
I did find only one occurrence of the "/NODEFAULTLIB" string:

in app_wxlua, Win32 debug:

# ADD LINK32 /VERBOSE:LIB /NODEFAULTLIB:MSVCRT.lib wxluadebug.lib 
wxluasocket.lib wxlua.lib

is it right ? or I'm missing some other occurrences ?
Also, is someone so kind to explain me (maybe just quoting the text from 
other mails) why that setting is so dangerous ?

Thanks a lot,
Francesco

Re: [Wxlua-users] Corrupt .dsp files in MSDev 7.1?

[Francesco M. <f18...@ya...>]

Hi,


  > I did a cvs co. I had a suggestion to change the line endings from 
Linux
> to DOS. I will try that today...
yes, at 99% this is because of linux line endings.
You can use "unix2dos" utility to fix them.
On CVS you are required to do that; on file releases this won't be 
necessary.

Francesco Montorsi

		
___________________________________ 
Yahoo! Messenger with Voice: chiama da PC a telefono a tariffe esclusive 
http://it.messenger.yahoo.com

[Wxlua-users] Re: wxLua on Linux

[Francesco M. <f18...@ya...>]

Hi all,

    I'm finally back from my last exams (crossing fingers waiting 
results  :))

 >I tried to compile on Linux. ( wxWidgets 2.6.2 with contrib installed
 >and static libs last installed ).
 >So wx-config gives static libs when asking for --libs.)
 >But i have several problems.
 >How does one configure to become static or dynamic libs?
 >
 >First i get warnings like this.
 >./wxlua/src/wxlstate.cpp:314:5: warning: "WXWIN_COMPATIBILITY_24" is
yes, I get these, too.
Maybe someone with more wxLua knowledge could fix these...


 >Eventually it compiles, but when i call make install, the result is >this.
 >I have no idea what is going on here.
I know what the problem is: bakefile 0.9 doesn't have good 
install/uninstall support.

John and all other wxLua admin: I made a patched version of Bakefile 
(0.2.0) with a lot of additional features which would fix, among others, 
also install and uninstall targets.
Should I upgrade wxLua bakefiles to 0.2.0, while we wait that my 
additional features (which I also submit to bakefile project as patches) 
are applied and official 0.2 is released ?

My bakefile 0.2.0 is available at:
  www.geocities.com/f18m_cpp217828/frm-bakefile.tar.gz

 >I tried configure --enable-wxlua-app,
 >this does not do anything it looks.
IIRC something like wxluasetup.h was supposed to be created and the 
WXLUASETUP_DIR & WXLUABINDLIB_DIR options should be used somewhere in 
bakefiles.
Anyway --enable-wxlua-app should work. I'll look into this.


 >Assuming i do something wrong and all this should work.
 >How does one find the wxLua settings?
 >Is there a wxlua-config ---libs --include etc. ?
I think it would be a little overkill create a wxlua-config script; 
wouldn't be better to create a wxlua.pc file for pkg-config, so that one 
could use

        pkg-config wxlua --libs

or

        pkg-config wxlua --cflags


?

 >I need to detect wxLua, i am trying to this from Cmake currently by
 >setting a WXLUA var.
 >But if there will be wxlua-config , that would be the solution.
I propose to use a pkg-config template file just because it's ultra easy 
to build one. Basically the wxlua.pc.in file would look as:

prefix=@prefix@
exec_prefix=@exec_prefix@
libdir=@libdir@
includedir=@includedir@

Name: @PACKAGE_NAME@
Description: wxWidgets lua wrappers
Version: @PACKAGE_VERSION@
Requires:
Libs: -L${libdir} -lwxlua
Cflags: -I${includedir}/lua


Just let me know...
Francesco Montorsi



PS: wxLua currently doesn't compile on my AMD64 linux box.
This is because in a lot of places some (int) casts are used to cast 
memory pointers. In a 64 bit environment pointers are 64 bit wide and 
thus I replaced all those (int) with (long). Then wxLua compiled.
Should I commit these changes ?

PS2: I subscribed wxlua-users mailing list to Gmane. I hope this is not 
a problem to anyone ;)

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it

Re: [Wxlua-users] bugs in namespace bindings?

[k. h. <kla...@nl...>]

And is i reverse the registration of the binding like this:

    // Register bindings
    wxLuaBindingList::Node *node;
    for (node = M_WXLSTATEDATA->m_bindings.GetLast(); node; node = 
node->GetPrevious() )
    {
        wxLuaBinding* binding = node->GetData();
        binding->RegisterBinding(L, registerTypes);
    }

It is calling wxlCanObj::GetPaperSize, so the opposite, but still wrong.

5:30:44: class wxlCanObj function GetPaperSize
15:30:56: wxLua_lua_getTableFunc 'GetPaperSize' pClass 11310688, 
userdata 1, lightuserdata 0, ttag 4, class_tag 4 lua_State 26287736 
wxLuaStateRefData 26278328


Klaas

k. holwerda wrote:

> Hi,
>
> I think there is someting wrong with the whole binding registration, 
> and that because of that things get mixed up.
>

-- 
Unclassified

[Wxlua-users] bugs in namespace bindings?

[k. h. <kla...@nl...>]

Hi,

I think there is someting wrong with the whole binding registration, and 
that because of that things get mixed up.

In wxLuaBinding::RegisterGeneratedClasses() i enabled the print
wxLogDebug(wxT("RegisterGenClasses %d '%s'\n"), iTag, 
lua2wx(pClass->name).c_str());

And i see that my object becomes registrated, but with the same itag as 
the wx binding.
I don't know if this is what casuing it??

14:14:15: RegisterGenClasses 4 'wxlCanObj'
14:14:31: RegisterGenClasses 4 'wxPageSetupDialogData'

Later on i run the next lua script from a file:

blah = wx.wxPageSetupDialogData()
blah:GetPaperSize()

canobj = wxluacan.wxlCanObj()
canobj:Draw( bitmapDC,  0, 0 )

The canobj is really constructed ( breakspoint in C++), but function 
Draw is called on the wrong object, in fact it is called on the wx 
namespace object  with the same iTag being 4.
So the first function is oke, but the second fails. And that is because 
the pclass is the one of the wxPageSetupDialogData, and not of the 
wxlCanObj.

wxLua_lua_getTableFunc(lua_State *L) in the end is able to print the 
function called, and the output indictaes that soemthing is wrong indeed:

14:53:30: class wxPageSetupDialogData function GetPaperSize
14:53:43: wxLua_lua_getTableFunc 'GetPaperSize' pClass 11590824, 
userdata 1, lightuserdata 0, ttag 4, class_tag 4 lua_State 26287736 
wxLuaStateRefData 26278328

14:53:51: class wxPageSetupDialogData function Draw
14:53:52: wxLua_lua_getTableFunc 'Draw' pClass 11590824, userdata 1, 
lightuserdata 0, ttag 4, class_tag 4 lua_State 26287736 
wxLuaStateRefData 26278328

This is all easy to reproduce on the sample i made. This evening i will 
upload this one, with the right rules and wxluacan.i file.
It looks like the namespace is skipped or it is not legal to have 
classes with the same iTag??
What is this Itag??

This is the stack when ariving at 14:53:43:

wxLua_lua_getTableFunc(lua_State * 0x01911e78) line 137
luaD_precall(lua_State * 0x01911e78, lua_TObject * 0x01912118) line 260 
+ 18 bytes
luaD_call(lua_State * 0x01911e78, lua_TObject * 0x01912118, int 1) line 
311 + 13 bytes
callTMres(lua_State * 0x01911e78, const lua_TObject * 0x0191e718, const 
lua_TObject * 0x019120c8, const lua_TObject * 0x0199a398) line 105 + 21 
bytes
luaV_getnotable(lua_State * 0x01911e78, const lua_TObject * 0x019120c8, 
lua_TObject * 0x0199a398, int 0) line 140 + 21 bytes
luaV_execute(lua_State * 0x01911e78) line 518 + 25 bytes
luaD_call(lua_State * 0x01911e78, lua_TObject * 0x019120b8, int -1) line 
313 + 9 bytes
f_call(lua_State * 0x01911e78, void * 0x015bf9f0) line 672 + 22 bytes
luaD_rawrunprotected(lua_State * 0x01911e78, void (lua_State *, void *)* 
0x006624a1 f_call(lua_State *, void *), void * 0x015bf9f0) line 88 + 13 
bytes
luaD_pcall(lua_State * 0x01911e78, void (lua_State *, void *)* 
0x006624a1 f_call(lua_State *, void *), void * 0x015bf9f0, int 144, int 
0) line 416 + 17 bytes
lua_pcall(lua_State * 0x01911e78, int 0, int -1, int 0) line 685 + 32 bytes
wxLuaState::LuaDoFile(const wxString & {...}) line 2218 + 15 bytes
wxLuaState::RunFile(const wxString & {...}) line 919 + 12 bytes
MyFrame::OnRunScript(wxCommandEvent & {...}) line 265 + 18 bytes

This is the stack when ariving at 14:53:52:

wxLua_lua_getTableFunc(lua_State * 0x01911e78) line 137
luaD_precall(lua_State * 0x01911e78, lua_TObject * 0x01912118) line 260 
+ 18 bytes
luaD_call(lua_State * 0x01911e78, lua_TObject * 0x01912118, int 1) line 
311 + 13 bytes
callTMres(lua_State * 0x01911e78, const lua_TObject * 0x0191e718, const 
lua_TObject * 0x019120c8, const lua_TObject * 0x0199a3d8) line 105 + 21 
bytes
luaV_getnotable(lua_State * 0x01911e78, const lua_TObject * 0x019120c8, 
lua_TObject * 0x0199a3d8, int 0) line 140 + 21 bytes
luaV_execute(lua_State * 0x01911e78) line 518 + 25 bytes
luaD_call(lua_State * 0x01911e78, lua_TObject * 0x019120b8, int -1) line 
313 + 9 bytes
f_call(lua_State * 0x01911e78, void * 0x015bf9f0) line 672 + 22 bytes
luaD_rawrunprotected(lua_State * 0x01911e78, void (lua_State *, void *)* 
0x006624a1 f_call(lua_State *, void *), void * 0x015bf9f0) line 88 + 13 
bytes
luaD_pcall(lua_State * 0x01911e78, void (lua_State *, void *)* 
0x006624a1 f_call(lua_State *, void *), void * 0x015bf9f0, int 144, int 
0) line 416 + 17 bytes
lua_pcall(lua_State * 0x01911e78, int 0, int -1, int 0) line 685 + 32 bytes
wxLuaState::LuaDoFile(const wxString & {...}) line 2218 + 15 bytes
wxLuaState::RunFile(const wxString & {...}) line 919 + 12 bytes

Hope this is enough to find the bug, i don't know how to solve it myself.

regards,

Klaas

-- 
Unclassified

Re: [Wxlua-users] new wxluacan sample

[k. h. <kla...@nl...>]

Ooh yes, lua is no with debug info ( in Cmake ).
A lot easier to follow, and actually fun to see what is happening internal.
Maybe i will find my problem now ;-)

I think that bakefile is not used to non graphical application, and that 
is why lua has no debug and there is the switch problems.

regards,

Klaas

klaas.holwerda wrote:

> I forgot, using Cmake there is no "/NODEFAULTLIB:MSVCRT.LIB" needed.
>
> I think bakefile is doing something wrong.
>
> Klaas
>
>

-- 
Unclassified

Re: [Wxlua-users] new wxluacan sample

[klaas.holwerda <kho...@xs...>]

I forgot, using Cmake there is no "/NODEFAULTLIB:MSVCRT.LIB" needed.

I think bakefile is doing something wrong.

Klaas

klaas.holwerda wrote:

> Hi,
>
> I made a sample to demo how to use wxLua in an application.

[Wxlua-users] new wxluacan sample

[klaas.holwerda <kho...@xs...>]

Hi,

I made a sample to demo how to use wxLua in an application.
It is a simple canvas + nested objects being a container for circle and 
rect object.
It is rendered non flicker etc., and not optimized like wxArt2D.
It has a commandprocessor, with undo and redo of moving objects, which 
can be easily extended if we want.
There is also a wxlCanObjScript, which i have in mind to be draw by a 
lua script string.
And that is not workling yet ;-)
The idea is to make lua script to add object to the canvas and to define 
new objects being drawn by lua.
The first i think i know how, the second not yet.

For the rest it is all Cmake generated project files, which you need to 
generate using Cmake.
Please build outside the wxLua tree itself, since that is what i do.

http://www.xs4all.nl/~kholwerd/tmp/wxLua2.tgz

Is anyone against if i add the sample to CVS + the Cmake files for 
building using Cmake?
Next we can extend it to demo all ins and outs of wxLua integration into 
an App.

Only tested with VC6 yet.
Please let me know if there is any trouble with building it.

regards,

Klaas

[Wxlua-users] namspaces problem

[k. h. <kla...@nl...>]

Hi John,

After searching for a long time, i realize that the namespace is my problem.

The situation is like this, i have one library containing the wrapping 
for wxArt2D, and a second part is wrapped inside the application based 
on wxArt2d.
Both wrapping are generated seperate using genwxbind.bat, each with its 
own rules file, and its own namespace.
Choosing the same namespace for both is a problem, since it result in 
eqaul named C++ code.

The problem start when a derived class in my application is wrapped, 
while the baseclass is wrapped inside the wxArt2D wraplibrary. The one 
in my application has namespaceX and the baseclass has  namspace Y.
And the classes and methods etc. in name space X do not know the ones in 
namespace Y.
Maybe this is exactly how it was meant, but for me it is not usable, and 
i think that it is in general the case.
As long as one does not drive classes in his own application, which need 
to be wrapped, it is oke.
But as soon one wants this, (e.g. derive from a wxWidgets class, and  
wrapped that class into wxlua,  this  wrapped  class gets its own 
namespace. And that simply does not work.
The derived class in lua, will not know there is a baseclass or at least 
it does not know it has methods.
( a forward decleration trick is not enough, or maybe is causing the 
problem?? ).

So i think we need something to extend a binding Y_Binding ( generated 
with genwxbind.bat ), with another X_binding which not creates a new set 
of binding classes, but extend an existing binding class. Or at least 
extends an existing namespace table, and not start a new one.

Another solution might be to extend wrapped classes/tables in one 
higher  namespace somehow with its baseclasses/tables from a lower 
namespace. I think this is what it is in C++, and would be best for 
wxLua too.
But still if this was already the case, it would still be good to have a 
way to extend a namespace.

To be sure the above is my problem, i put all my binding into the 
application and into one namespace, and all works well.

How and where are baseclasses actually coupled to its derived classes?  
Maybe it is not so hard to couple classes in one namespace/binding to 
its baseclasses in another namespace?
Actually it looks like this is done in wxLuaState::RegisterBindings(), 
but somehow its not working correctly.

Hope you see what can be done, or what i am missing,

regards,

Klaas

 


-- 
Unclassified

Re: [Wxlua-users] Possible coroutine fixes

[klaas.holwerda <kho...@xs...>]

John Labenski wrote:

>>If several lua_State need to share data, that can be done using a second
>>Smart Pointer inside wxLuaState.
>>    
>>
>
>You still need a way to associate many lua_States with a single group
>of data structures. I'm not sure how a smart pointer would help here.
>  
>
The idea of smart pointers is that there are many Smart pointers 
pointing to the same data structure.
How many the count is,  is held within that data structure by the refcount.
So the idea is exactly that the same structure/class instance  is 
referenced/shared by several other objects,  which hold a smart pointer 
to that  structure/class as a member .
So if it would be possible to couple each new lua_State to a wxLuaState, 
where the last has a smart pointer to the shareddata structure/class, 
that  would  be oke.
This is i think you had in mind too, but doing it using refcounting the 
wxWidgets way, which is i think harder.
 

>>It will be cleared properly if all wxLuaStates's are released ( no more
>>smart pointers to it ).
>>I used hierarchies of smart pointers for storing drawing objects, and it
>>works great.
>>    
>>
>
>Deletion is not so much a problem, I will look back at your smart
>pointers. Another reason to have the wxObject ref mechanism is that
>you can have a delayed construction, eg. make a wxLuaState a member of
>a class and then Create it as necessary or not at all.
>  
>
Same with smart pointers i think. It initializes to zero, and once it is 
assigned a wxLuaState object, it will hold it. In principle a smart 
pointer acts almost like a normal pointer in mnay cases, only it deletes 
the object pointed to only when there or no more references. We have 
another even smarter pointer, which is able to reset all other smart 
pointers pointing to the same object. ( the object pointed to, has a 
list of all Smart pointer pointing to it. )
So it depends on what is needed.

>  
>
>>What is exactly the reason you choose the current form of ref counting?
>>    
>>
>
>So that when you pass a wxLuaState to a wxLuaCallback (a handler for a
>wxEvent) and then close the lua_State you want the wxLuaCallback to
>know that the lua_State has been closed.
>
That sounds like the smarTer pointer version;-)

> It's a simple way to let
>anyone who's given a wxLuaState that the lua_State is good or not. If
>you just use pointers to the lua_State you have to track them all and
>NULL them to avoid someone trying to use them. This can happen with
>delayed window deletion in wxWidgets.
>  
>
I see, i recognize this, often had that problem in wxWidgets.
Who is normally deleting a created lua_State? Is wxLua able to notice 
this event?

Hope it helps a little to decide what is best,

Klaas

Re: [Wxlua-users] Possible coroutine fixes

[John L. <jla...@gm...>]

> I hardly understand the problem. I do understand that there are two
> lua_State at the same time.
> While there is only one wxLuaState.
> What would be the problem if there would be two wxLuaStates too?

Because the rest of the variables in the wxLuaStateRefData must be
shared between the two lua_States. You only know which lua_State you
want to use from lua calling the C function.

> And what would be the solution if the new lua_State became part of every
> new wxLuaState, and that
> was passed around using a Smart Pointer to it, instead of the current
> ref counting mechanism.
> If several lua_State need to share data, that can be done using a second
> Smart Pointer inside wxLuaState.

You still need a way to associate many lua_States with a single group
of data structures. I'm not sure how a smart pointer would help here.

> It will be cleared properly if all wxLuaStates's are released ( no more
> smart pointers to it ).
> I used hierarchies of smart pointers for storing drawing objects, and it
> works great.

Deletion is not so much a problem, I will look back at your smart
pointers. Another reason to have the wxObject ref mechanism is that
you can have a delayed construction, eg. make a wxLuaState a member of
a class and then Create it as necessary or not at all.

> What is exactly the reason you choose the current form of ref counting?

So that when you pass a wxLuaState to a wxLuaCallback (a handler for a
wxEvent) and then close the lua_State you want the wxLuaCallback to
know that the lua_State has been closed. It's a simple way to let
anyone who's given a wxLuaState that the lua_State is good or not. If
you just use pointers to the lua_State you have to track them all and
NULL them to avoid someone trying to use them. This can happen with
delayed window deletion in wxWidgets.

> I do not know how and why wxLua is organized as is yet, so don't get mad
> if i am talking nonsense ;-)

It's not too difficult, but there are some subtle intricacies.

Regards,
    John Labenski

Re: [Wxlua-users] Possible coroutine fixes

[k. h. <kla...@nl...>]

Hi John,

John Labenski wrote:

>
>e) ?
>  
>
I hardly understand the problem. I do understand that there are two 
lua_State at the same time.
While there is only one wxLuaState.
What would be the problem if there would be two wxLuaStates too?
And what would be the solution if the new lua_State became part of every 
new wxLuaState, and that
was passed around using a Smart Pointer to it, instead of the current 
ref counting mechanism.
If several lua_State need to share data, that can be done using a second 
Smart Pointer inside wxLuaState.
It will be cleared properly if all wxLuaStates's are released ( no more 
smart pointers to it ).
I used hierarchies of smart pointers for storing drawing objects, and it 
works great.

I guess what i am trying to say can Smart pointers help here, as a more 
convenient way to share data.
For sure Smart pointer code is much easier to follow in C++ code.

What is exactly the reason you choose the current form of ref counting?

I do not know how and why wxLua is organized as is yet, so don't get mad 
if i am talking nonsense ;-)

Regards,

Klaas



-- 
Unclassified

[Wxlua-users] Possible coroutine fixes

[John L. <jla...@gm...>]

There is a problem with coroutines currently. The issue is that when
lua creates a coroutine a new lua_State is created by lua and wxLua
correctly associates the new lua_State with the original wxLuaState so
that it can get the ref data (where the bindings and C++ variables are
stored). This is all fine, however when you try to run some lua code
in a coroutine, lua calls the function "int LUACALL
wxLua_lua_getTableFunc(lua_State *L)" to find out about a bound
function. It needs to look up the wxLuaState (for the ref data) and
though the proper ref data IS found, subsequent calls to functions
like wxLuaState::ttag use the lua_State of the wxLuaState and not the
coroutine one and so it fails.

Solutions:

a) Remove all the ttag and other functions from the wxLuaState and
make them standalone 'C' functions that only take a lua_State* L. This
would require that the wxLuaState (and it's ref data) would have to be
incessantly looked up, this is how it was previously.

b) Add a parameter lua_State* L =3D NULL to the end of functions like
ttag (and EVERY function that would be called by a 'C' function called
by lua) that would either use the given lua_State passed in if !NULL
or use the lua_State of the wxLuaState. This is easy to do, but may be
a little confusing.

c) Make the ref data, the C++ data for the lua_State itself ref data.
     wxLuaState : wxObject
        -> wxLuaStateRefData (the wxObjectRefData)
                members are lua_State* and wxLuaStateData
     wxLuaStateData : wxObject
        -> wxLuaStateDataRefData (the wxObjectRefData)
                members are the rest of what is currently in the
wxLuaStateRefData

So that if you do "wxLuaState wxlState(lua_State* L)" it finds the
wxLuaStateRefData for the given lua_State, but since the
wxLuaStateData is also ref counted two or more wxLuaStateRefData can
share the same data, which is what coroutines require.

d) Make wxLuaState NOT ref counted and keep a list of pointers to them
for looking them up from the lua_State*. As a member it would have a
ref counted wxLuaStateData class, similar to the one outlined above.

e) ?

I'd appreciate any thoughts on this. In my effort to make the
wxLuaState more robust, I missed this important detail.

Regards,
    John Labenski

Re: [Wxlua-users] forward declarations

[John L. <jla...@gm...>]

> >>I see many *.i files, which have things in it which are not forward
> >>declared?
> >>Does  genwxbind.lua parse the headers included with %include?
> >>That would explain it, but i got the feeling it is not doing anything
> >>with %include, it is just for putting it in the  C++ generated code?
> >
> >genwxbind.lua reads all the .i files in an generates a list of all the
> >classes that were defined. Any class not defined will generate an
> >error.
> >
> >
> I see, so if i understand well, each call to genwxbind.lua
> should be one a set of *.i files which are selfcontained. Meaning all cla=
ss names should be somewhere in there.
> What if one uses classes from an other  module/library, e.g derived class=
es. The base class is wrapped already (with a seperate call to genwxbind.lu=
a) , the baseclass of the derived class in the new module needs to be know =
too.
> So in that case one needs the empty class defenition as a sort of forward=
 declaration right?
>
> What i conclude from this is that we need soem sort of *.ih files for mod=
ule, being a header of know types from another module. Something like filli=
ng the list of know types.
>
> Maybe we should have a %forward class classname, to achieve the next from=
 the rules file, but from a *.i file.
>
> dataTypes["wxCursor"] =3D AllocDataType("wxCursor", "class", false)
>
> Did would make it a bit more moduler.

Yes it would, there is a DataTypes.Cache.lua file created in the
bindings/wxwidgets directory that can be used for this, but I haven't
been able to look into it. You're right that some sort of
"precompiled" header from a set of .i files should be generated to
take the burden off of other bindings.

I will look into the DataTypes.Cache.lua file to understand how and if
it's actually used.

Regards,
    John Labenski

Re: [Wxlua-users] what to do on static

[k. h. <kla...@nl...>]

John,

It works perfect now,

Thanks,

Klaas

John Labenski wrote:

>. I have changed it to use a wxModule now. Regenerate
>all the bindings and let me know if it works for you.
>
>  
>
>

-- 
Unclassified

Re: [Wxlua-users] forward declarations

[k. h. <kla...@nl...>]

John Labenski wrote:

>On 1/4/06, klaas.holwerda <kho...@xs...> wrote:
>  
>
>>I see many *.i files, which have things in it which are not forward
>>declared?
>>Does  genwxbind.lua parse the headers included with %include?
>>That would explain it, but i got the feeling it is not doing anything
>>with %include, it is just for putting it in the  C++ generated code?
>>    
>>
>
>genwxbind.lua reads all the .i files in an generates a list of all the
>classes that were defined. Any class not defined will generate an
>error.
>  
>
I see, so if i understand well, each call to

genwxbind.lua

should be one a set of *.i files which are selfcontained. Meaning all class names should be somewhere in there.
What if one uses classes from an other  module/library, e.g derived classes. The base class is wrapped already (with a seperate call to genwxbind.lua) , the baseclass of the derived class in the new module needs to be know too. 
So in that case one needs the empty class defenition as a sort of forward declaration right?

What i conclude from this is that we need soem sort of *.ih files for module, being a header of know types from another module. Something like filling the list of know types.

Maybe we should have a %forward class classname, to achieve the next from the rules file, but from a *.i file.

dataTypes["wxCursor"] = AllocDataType("wxCursor", "class", false)

Did would make it a bit more moduler.

regards,

Klaas



-- 
Unclassified

Re: [Wxlua-users] what to do on static

[John L. <jla...@gm...>]

On 1/4/06, klaas.holwerda <kho...@xs...> wrote:
> Hi John,
>
> You did not react on this one, maybe you missed it amougst all the
> questions,
> or you simply did not have time yet.

Sorry, I forgot. I have changed it to use a wxModule now. Regenerate
all the bindings and let me know if it works for you.

Regards,
    John Labenski


> http://sourceforge.net/mailarchive/message.php?msg_id=3D14327913
>
> But currently i have to remove the static initialization from  the
> bindings  the next parts:
>
> class teto_BindingInit
> {
> public:
>     teto_BindingInit()
>     {
>         m_binding.GetBindingList()->Append(&m_binding);
>     }
>     teto_Binding m_binding;
> };
>
> teto_BindingInit s_teto_BindingInit;
>
> since else there is a problem in order of initialization.
> And next initialize in the wxAppOnInit.
>
> bool MyApp::OnInit(void)
> {
>     wxart2d_Binding binding1;
>     binding1.GetBindingList()->Append(&binding1);
>     teto_Binding binding;
>     binding.GetBindingList()->Append(&binding);
>
> I don't mind about initializing them myself, but removing is not a soluti=
on.
> So or we must make this XXX_BindingInit optional, or we must go for the
> wxModule solutions.
>
> What do you think,
>
> Klaas
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Wxlua-users mailing list
> Wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>

Re: [Wxlua-users] forward declarations

[John L. <jla...@gm...>]

On 1/4/06, klaas.holwerda <kho...@xs...> wrote:
> I see many *.i files, which have things in it which are not forward
> declared?
> Does  genwxbind.lua parse the headers included with %include?
> That would explain it, but i got the feeling it is not doing anything
> with %include, it is just for putting it in the  C++ generated code?

genwxbind.lua reads all the .i files in an generates a list of all the
classes that were defined. Any class not defined will generate an
error.

Regards,
    John Labenski

Re: [Wxlua-users] wxLua on Linux?

[John L. <jla...@gm...>]

T24gMS82LzA2LCBrLiBob2x3ZXJkYSA8a2xhYXMuaG9sd2VyZGFAbmwudGhhbGVzZ3JvdXAuY29t
PiB3cm90ZToKPiBIaSBBbGwsCj4KPiBJIHRyaWVkIHRvIGNvbXBpbGUgb24gTGludXguICggd3hX
aWRnZXRzIDIuNi4yIHdpdGggY29udHJpYiBpbnN0YWxsZWQKPiBhbmQgc3RhdGljIGxpYnMgbGFz
dCBpbnN0YWxsZWQgKS4KPiBTbyB3eC1jb25maWcgZ2l2ZXMgc3RhdGljIGxpYnMgd2hlbiBhc2tp
bmcgZm9yIC0tbGlicy4pCj4gQnV0IGkgaGF2ZSBzZXZlcmFsIHByb2JsZW1zLgo+Cj4gSG93IGRv
ZXMgb25lIGNvbmZpZ3VyZSB0byBiZWNvbWUgc3RhdGljIG9yIGR5bmFtaWMgbGlicz8KClNvcnJ5
LCBJIGRvbid0IGtub3cuIFRoZSBNYWtlZmlsZXMgdXNlIHd4LWNvbmZpZyBob3dldmVyIGFuZCBt
YXliZQp0aGV5J2xsIHdvcmsgZm9yIHlvdT8KClJlZ2FyZHMsCiAgICBKb2huIExhYmVuc2tpCgo+
IEZpcnN0IGkgZ2V0IHdhcm5pbmdzIGxpa2UgdGhpcy4KPgo+IC4uLy4vYmstZGVwcyBnKysgLWMg
LW8gd3hsdWFfbGliX3d4bHN0YXRlLm8gLUkuLy4uL21vZHVsZXMKPiAtSS91c3IvbG9jYWwvbGli
L3d4L2luY2x1ZGUvZ3RrMi1hbnNpLWRlYnVnLXN0YXRpYy0yLjYKPiAtSS91c3IvbG9jYWwvaW5j
bHVkZS93eC0yLjYgLURfX1dYREVCVUdfXyAtRF9fV1hHVEtfXwo+IC1EX0ZJTEVfT0ZGU0VUX0JJ
VFM9NjQgLURfTEFSR0VfRklMRVMgLURfTEFSR0VGSUxFX1NPVVJDRT0xCj4gLUROT19HQ0NfUFJB
R01BIC1nIC1PMCAtV2FsbCAtV3VuZGVmIC1Xbm8tY3Rvci1kdG9yLXByaXZhY3kKPiAuL3d4bHVh
L3NyYy93eGxzdGF0ZS5jcHAKPiAuL3d4bHVhL3NyYy93eGxzdGF0ZS5jcHA6MzE0OjU6IHdhcm5p
bmc6ICJXWFdJTl9DT01QQVRJQklMSVRZXzI0IiBpcyBub3QKPiBkZWZpbmVkCj4KPiAuLi8uL2Jr
LWRlcHMgZysrIC1jIC1vIHd4YmluZF9saWJfYXBwZnJhbWUubyAtSS4vLi4vbW9kdWxlcwo+IC1J
L3Vzci9sb2NhbC9saWIvd3gvaW5jbHVkZS9ndGsyLWFuc2ktZGVidWctc3RhdGljLTIuNgo+IC1J
L3Vzci9sb2NhbC9pbmNsdWRlL3d4LTIuNiAtRF9fV1hERUJVR19fIC1EX19XWEdUS19fCj4gLURf
RklMRV9PRkZTRVRfQklUUz02NCAtRF9MQVJHRV9GSUxFUyAtRF9MQVJHRUZJTEVfU09VUkNFPTEK
PiAtRE5PX0dDQ19QUkFHTUEgLWcgLU8wIC1XYWxsIC1XdW5kZWYgLVduby1jdG9yLWR0b3ItcHJp
dmFjeQo+IC4vd3hiaW5kL3NyYy9hcHBmcmFtZS5jcHAKPiBJbiBmaWxlIGluY2x1ZGVkIGZyb20g
Li93eGJpbmQvc3JjL2FwcGZyYW1lLmNwcDoyMzoKPiAuLy4uL21vZHVsZXMvd3hiaW5kL2luY2x1
ZGUvd3hiaW5kLmg6MTI3OjY6IHdhcm5pbmc6ICJ3eFVTRV9XQVZFIiBpcyBub3QKPiBkZWZpbmVk
Cj4gLi8uLi9tb2R1bGVzL3d4YmluZC9pbmNsdWRlL3d4YmluZC5oOjMyODo1OiB3YXJuaW5nOgo+
ICJ3eExVQV9VU0Vfd3hDcml0aWNhbFNlY3Rpb24iIGlzIG5vdCBkZWZpbmVkCj4gLi8uLi9tb2R1
bGVzL3d4YmluZC9pbmNsdWRlL3d4YmluZC5oOjUwNjo1OiB3YXJuaW5nOgo+ICJ3eExVQV9VU0Vf
d3hDcml0aWNhbFNlY3Rpb25Mb2NrZXIiIGlzIG5vdCBkZWZpbmVkCj4gLi8uLi9tb2R1bGVzL3d4
YmluZC9pbmNsdWRlL3d4YmluZC5oOjkxOTo1OiB3YXJuaW5nOgo+ICJ3eExVQV9VU0Vfd3hDcml0
aWNhbFNlY3Rpb25Mb2NrZXIiIGlzIG5vdCBkZWZpbmVkCj4gLi8uLi9tb2R1bGVzL3d4YmluZC9p
bmNsdWRlL3d4YmluZC5oOjEwMzg6Njogd2FybmluZzogInd4VVNFX1dBVkUiIGlzCj4gbm90IGRl
ZmluZWQKPiAuLy4uL21vZHVsZXMvd3hiaW5kL2luY2x1ZGUvd3hiaW5kLmg6MTMxMDo1OiB3YXJu
aW5nOgo+ICJ3eExVQV9VU0Vfd3hDcml0aWNhbFNlY3Rpb24iIGlzIG5vdCBkZWZpbmVkCj4gLi8u
Li9tb2R1bGVzL3d4YmluZC9pbmNsdWRlL3d4YmluZC5oOjE5MDk6NTogd2FybmluZzoKPiAid3hM
VUFfVVNFX3d4Q3JpdGljYWxTZWN0aW9uTG9ja2VyIiBpcyBub3QgZGVmaW5lZAo+IC4vLi4vbW9k
dWxlcy93eGJpbmQvaW5jbHVkZS93eGJpbmQuaDoyMDY3OjY6IHdhcm5pbmc6ICJ3eFVTRV9XQVZF
IiBpcwo+IG5vdCBkZWZpbmVkCj4gLi8uLi9tb2R1bGVzL3d4YmluZC9pbmNsdWRlL3d4YmluZC5o
OjI0NTU6NTogd2FybmluZzoKPiAid3hMVUFfVVNFX3d4Q3JpdGljYWxTZWN0aW9uIiBpcyBub3Qg
ZGVmaW5lZAo+IC4vLi4vbW9kdWxlcy93eGJpbmQvaW5jbHVkZS93eGJpbmQuaDoyNzM2OjU6IHdh
cm5pbmc6Cj4gInd4TFVBX1VTRV93eENyaXRpY2FsU2VjdGlvbkxvY2tlciIgaXMgbm90IGRlZmlu
ZWQKPiAuLy4uL21vZHVsZXMvd3hiaW5kL2luY2x1ZGUvd3hiaW5kLmg6Mjc1ODo1OiB3YXJuaW5n
Ogo+ICJ3eExVQV9VU0Vfd3hDcml0aWNhbFNlY3Rpb24iIGlzIG5vdCBkZWZpbmVkCj4KPgo+IEV2
ZW50dWFsbHkgaXQgY29tcGlsZXMsIGJ1dCB3aGVuIGkgY2FsbCBtYWtlIGluc3RhbGwsIHRoZSBy
ZXN1bHQgaXMgdGhpcy4KPiBJIGhhdmUgbm8gaWRlYSB3aGF0IGlzIGdvaW5nIG9uIGhlcmUuCj4K
PiBbZGIzNDhAczE1OTc0OSB3eEx1YV0kIG1ha2UgaW5zdGFsbAo+IChjZCAuL21vZHVsZXMvICYm
IG1ha2UgKQo+IG1ha2VbMV06IEVudGVyaW5nIGRpcmVjdG9yeSBgL2hvbWUvZGIzNDgvd3hMdWEv
bW9kdWxlcycKPiBtYWtlWzFdOiBOb3RoaW5nIHRvIGJlIGRvbmUgZm9yIGBhbGwnLgo+IG1ha2Vb
MV06IExlYXZpbmcgZGlyZWN0b3J5IGAvaG9tZS9kYjM0OC93eEx1YS9tb2R1bGVzJwo+IChjZCAu
L3V0aWwvICYmIG1ha2UgaW5zdGFsbCkKPiBtYWtlWzFdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9o
b21lL2RiMzQ4L3d4THVhL3V0aWwnCj4gLi4vLi9iay1kZXBzIGdjYyAtYyAtbyBhdXRvY29uZi91
dGlsX2JpbjJjX2JpbjJjLm8gLWcgLU8wIC1XYWxsIC1XdW5kZWYKPiAuL2JpbjJjL2JpbjJjLmMK
PiAuL2JpbjJjL2JpbjJjLmM6IEluIGZ1bmN0aW9uIOKAmGR1bXDigJk6Cj4gLi9iaW4yYy9iaW4y
Yy5jOjMwOiB3YXJuaW5nOiBzdGF0ZW1lbnQgd2l0aCBubyBlZmZlY3QKPiAuL2JpbjJjL2JpbjJj
LmM6NTM6IHdhcm5pbmc6IHRvbyBtYW55IGFyZ3VtZW50cyBmb3IgZm9ybWF0Cj4gLi9iaW4yYy9i
aW4yYy5jOjU0OiB3YXJuaW5nOiB0b28gbWFueSBhcmd1bWVudHMgZm9yIGZvcm1hdAo+IC4vYmlu
MmMvYmluMmMuYzo5MDoxMjogd2FybmluZzogIi8qIiB3aXRoaW4gY29tbWVudAo+IC4vYmluMmMv
YmluMmMuYzogQXQgdG9wIGxldmVsOgo+IC4vYmluMmMvYmluMmMuYzoxMTM6IGZhdGFsIGVycm9y
OiBvcGVuaW5nIGRlcGVuZGVuY3kgZmlsZQo+IGF1dG9jb25mL3V0aWxfYmluMmNfYmluMmMuZDog
Tm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQo+IGNvbXBpbGF0aW9uIHRlcm1pbmF0ZWQuCj4gbWFr
ZVsxXTogKioqIFthdXRvY29uZi91dGlsX2JpbjJjX2JpbjJjLm9dIEVycm9yIDEKPiBtYWtlWzFd
OiBMZWF2aW5nIGRpcmVjdG9yeSBgL2hvbWUvZGIzNDgvd3hMdWEvdXRpbCcKPiBtYWtlOiAqKiog
W2luc3RhbGxdIEVycm9yIDIKPgo+IFdoZW4gdGhpcyB3b3VsZCBoYXZlIGFsbCB3b3JrZWQsIGkg
bWlnaHQgaGF2ZSBiaW4gYWJsZSB0byBhbHNvIGNvbXBpbGUKPiB0aGUgd3hMdWEgYXBwbGljYXRp
b24sIGJ1dCBhdCB0aGlzIG1vbWVudCwKPiB3aXRob3V0IHRoZSBpbnN0YWxsIGl0IGRvZXMgbm90
LiBJIHRyaWVkIGNvbmZpZ3VyZSAtLWVuYWJsZS13eGx1YS1hcHAsCj4gdGhpcyBkb2VzIG5vdCBk
byBhbnl0aGluZyBpdCBsb29rcy4KPgo+IEFzc3VtaW5nIGkgZG8gc29tZXRoaW5nIHdyb25nIGFu
ZCBhbGwgdGhpcyBzaG91bGQgd29yay4KPiBIb3cgZG9lcyBvbmUgZmluZCB0aGUgd3hMdWEgc2V0
dGluZ3M/Cj4gSXMgdGhlcmUgYSB3eGx1YS1jb25maWcgLS0tbGlicyAtLWluY2x1ZGUgZXRjLiA/
Cj4KPiBJIG5lZWQgdG8gZGV0ZWN0IHd4THVhLCBpIGFtIHRyeWluZyB0byB0aGlzIGZyb20gQ21h
a2UgY3VycmVudGx5IGJ5Cj4gc2V0dGluZyBhIFdYTFVBIHZhci4KPiBCdXQgaWYgdGhlcmUgd2ls
bCBiZSB3eGx1YS1jb25maWcgLCB0aGF0IHdvdWxkIGJlIHRoZSBzb2x1dGlvbi4KPgo+IFJlZ2Fy
ZHMsCj4KPiBLbGFhcwo+Cj4KPgo+Cj4gLS0KPiBVbmNsYXNzaWZpZWQKPgo+Cj4KPiAtLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gVGhpcyBT
Ri5uZXQgZW1haWwgaXMgc3BvbnNvcmVkIGJ5OiBTcGx1bmsgSW5jLiBEbyB5b3UgZ3JlcCB0aHJv
dWdoIGxvZyBmaWxlcwo+IGZvciBwcm9ibGVtcz8gIFN0b3AhICBEb3dubG9hZCB0aGUgbmV3IEFK
QVggc2VhcmNoIGVuZ2luZSB0aGF0IG1ha2VzCj4gc2VhcmNoaW5nIHlvdXIgbG9nIGZpbGVzIGFz
IGVhc3kgYXMgc3VyZmluZyB0aGUgIHdlYi4gIERPV05MT0FEIFNQTFVOSyEKPiBodHRwOi8vYWRz
Lm9zZG4uY29tLz9hZF9pZHYzNyZhbGxvY19pZBY4NjUmb3BjbGljawo+IF9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gV3hsdWEtdXNlcnMgbWFpbGluZyBs
aXN0Cj4gV3hsdWEtdXNlcnNAbGlzdHMuc291cmNlZm9yZ2UubmV0Cj4gaHR0cHM6Ly9saXN0cy5z
b3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vd3hsdWEtdXNlcnMKPgo=

Re: [Wxlua-users] Native callbacks in wxLua?

[Chris M. <ch...@ma...>]

John Labenski wrote:
> On 1/8/06, Chris Marrin <ch...@ma...> wrote:
> 
>>A while ago, John and I discussed the changes I made to the older
>>version of wxLua I was using. My big issue was being able to run the
>>wxApp event loop in a separate thread from Emma. Because of this I could
>>not call Lua functions that had been connected because they would run in
>>the wrong thread. So I came up with a native callback mechanism. This
>>basically used the same Connect() model that wxLua uses, but it uses a
>>form that registers a C++ callback rather than a Lua function. wxLua
>>would call this callback and my native function would send a message to
>>the thread running the Lua interpreter to execute the Lua function.
>>
>>All this inter-thread comm is done in my app, so all wxLua needs is the
>>ability to register native callbacks. I discussed adding this to this
>>latest incarnation of wxLua with John. It does not look like that was
>>ever added.
> 
> 
> I think, if I understand correctly, that the same can be implemented
> by just making the wxLuaCallback::CallFunction virtual
> (modules/wxlua/include/wxlcallb.h). In your program you will have your
> own ConnectEvent function, similar to the one you added in
> wxLuaInternals.cpp, but instead you'll create a new wxMyLuaCallback
> class with CallFunction overridden to do as you please. Does this
> sound like it'll work? There's nothing wrong with your method, but I
> think just making wxLuaCallback::CallFunction virtual is a little
> cleaner and simpler, but maybe it's not workable for you?

I have no problem with subclassing, as long as I also override, for 
instance, wxCallback::CallFunction() as well. Then I can override it.

-- 
chris marrin                ,""$,
ch...@ma...          b`    $                             ,,.
(650) 941-9040          mP     b'                            , 1$'
M1      ,.`           ,b`    ,`                              :$$'
      ,|`             mP    ,`                                       ,mm
    ,b"              b"   ,`            ,mm      m$$    ,m         ,`P$$
   m$`             ,b`  .` ,mm        ,'|$P   ,|"1$`  ,b$P       ,`  :$1
  b$`             ,$: :,`` |$$      ,`   $$` ,|` ,$$,,`"$$     .`    :$|
b$|            _m$`,:`    :$1   ,`     ,$Pm|`    `    :$$,..;"'     |$:
P$b,      _;b$$b$1"       |$$ ,`      ,$$"             ``'          $$
  ```"```'"    `"`         `""`        ""`                          ,P`
"As a general rule,don't solve puzzles that open portals to Hell"'

Re: [Wxlua-users] Native callbacks in wxLua?

[John L. <jla...@gm...>]

On 1/8/06, Chris Marrin <ch...@ma...> wrote:
>
> A while ago, John and I discussed the changes I made to the older
> version of wxLua I was using. My big issue was being able to run the
> wxApp event loop in a separate thread from Emma. Because of this I could
> not call Lua functions that had been connected because they would run in
> the wrong thread. So I came up with a native callback mechanism. This
> basically used the same Connect() model that wxLua uses, but it uses a
> form that registers a C++ callback rather than a Lua function. wxLua
> would call this callback and my native function would send a message to
> the thread running the Lua interpreter to execute the Lua function.
>
> All this inter-thread comm is done in my app, so all wxLua needs is the
> ability to register native callbacks. I discussed adding this to this
> latest incarnation of wxLua with John. It does not look like that was
> ever added.

I think, if I understand correctly, that the same can be implemented
by just making the wxLuaCallback::CallFunction virtual
(modules/wxlua/include/wxlcallb.h). In your program you will have your
own ConnectEvent function, similar to the one you added in
wxLuaInternals.cpp, but instead you'll create a new wxMyLuaCallback
class with CallFunction overridden to do as you please. Does this
sound like it'll work? There's nothing wrong with your method, but I
think just making wxLuaCallback::CallFunction virtual is a little
cleaner and simpler, but maybe it's not workable for you?

> John, any resolution on adding this? If there is still interest, I will
> switch over to your version of wxLua, make my changes there and make
> them available to you. My goal, of course, is to use a stock version of
> wxLua!

I hope I can help and we can get this to work. I'll have some time
tonight to fix the linking problem that Klaas was having.

Regards,
    John Labenski

Re: [Wxlua-users] Corrupt .dsp files in MSDev 7.1?

[Chris M. <ch...@ma...>]

k. holwerda wrote:
> Hi Chris,
> 
> I have no problem with the project files for Vc6, will try it with NET 
> this evening.
> The files or generated using bakefile, nad you can do it your self too.
> using bakefile_gen.
> 
> You say you have snagged an CVS image, you mean you did checkout 
> properly? Or are you looking at a dump of the CVS repository?

I did a cvs co. I had a suggestion to change the line endings from Linux 
to DOS. I will try that today...

-- 
chris marrin              ,""$, "As a general rule,don't solve puzzles
ch...@ma...        b`    $  that open portals to Hell" ,,.
         ,.`           ,b`    ,`                            , 1$'
      ,|`             mP    ,`                              :$$'     ,mm
    ,b"              b"   ,`            ,mm      m$$    ,m         ,`P$$
   m$`             ,b`  .` ,mm        ,'|$P   ,|"1$`  ,b$P       ,`  :$1
  b$`             ,$: :,`` |$$      ,`   $$` ,|` ,$$,,`"$$     .`    :$|
b$|            _m$`,:`    :$1   ,`     ,$Pm|`    `    :$$,..;"'     |$:
P$b,      _;b$$b$1"       |$$ ,`      ,$$"             ``'          $$
  ```"```'"    `"`         `""`        ""`                          ,P`

Re: [Wxlua-users] Corrupt .dsp files in MSDev 7.1?

[John L. <jla...@gm...>]

On 1/9/06, k. holwerda <kla...@nl...> wrote:
> Hi Chris,
>
> I have no problem with the project files for Vc6, will try it with NET
> this evening.
> The files or generated using bakefile, nad you can do it your self too.
> using bakefile_gen.
>
> You say you have snagged an CVS image, you mean you did checkout
> properly? Or are you looking at a dump of the CVS repository?

Make sure the line endings are correct from your CVS checkout.

Regards,
    John Labenski

Re: [Wxlua-users] Corrupt .dsp files in MSDev 7.1?

[k. h. <kla...@nl...>]

Hi Chris,

I have no problem with the project files for Vc6, will try it with NET 
this evening.
The files or generated using bakefile, nad you can do it your self too.
using bakefile_gen.

You say you have snagged an CVS image, you mean you did checkout 
properly? Or are you looking at a dump of the CVS repository?

regards,

Klaas

Chris Marrin wrote:

> Anyone else experiencing this?
>

-- 
Unclassified

[Wxlua-users] Native callbacks in wxLua?

[Chris M. <ch...@ma...>]

A while ago, John and I discussed the changes I made to the older 
version of wxLua I was using. My big issue was being able to run the 
wxApp event loop in a separate thread from Emma. Because of this I could 
not call Lua functions that had been connected because they would run in 
the wrong thread. So I came up with a native callback mechanism. This 
basically used the same Connect() model that wxLua uses, but it uses a 
form that registers a C++ callback rather than a Lua function. wxLua 
would call this callback and my native function would send a message to 
the thread running the Lua interpreter to execute the Lua function.

All this inter-thread comm is done in my app, so all wxLua needs is the 
ability to register native callbacks. I discussed adding this to this 
latest incarnation of wxLua with John. It does not look like that was 
ever added.

John, any resolution on adding this? If there is still interest, I will 
switch over to your version of wxLua, make my changes there and make 
them available to you. My goal, of course, is to use a stock version of 
wxLua!

Let me know, thanks...

-- 
chris marrin                ,""$,
ch...@ma...          b`    $                             ,,.
(650) 941-9040          mP     b'                            , 1$'
M1      ,.`           ,b`    ,`                              :$$'
      ,|`             mP    ,`                                       ,mm
    ,b"              b"   ,`            ,mm      m$$    ,m         ,`P$$
   m$`             ,b`  .` ,mm        ,'|$P   ,|"1$`  ,b$P       ,`  :$1
  b$`             ,$: :,`` |$$      ,`   $$` ,|` ,$$,,`"$$     .`    :$|
b$|            _m$`,:`    :$1   ,`     ,$Pm|`    `    :$$,..;"'     |$:
P$b,      _;b$$b$1"       |$$ ,`      ,$$"             ``'          $$
  ```"```'"    `"`         `""`        ""`                          ,P`
"As a general rule,don't solve puzzles that open portals to Hell"'