wxlua-users Mailing List for wxLua

On Dec 24, 2007 9:44 AM, Andre <ar...@ki...> wrote:
> Andre <arpin@...> writes:
>
> >
> > Current version
> install a fresh copy
> got these errors
>
> canlua.cpp
>
> 'PushUserDataType' : is not a member of 'wxLuaState'
> 's_wxluatag_wxlCanObj' : undeclared identifier
>
> even doing a clean sometime does not work
>
I have "updated" the nomenclature for what wxLua calls the C++ class
objects that wxLua pushes into Lua. Originally they were called "tags"
(hence the functions PushUserTag(...), newtag(), gettag(),
settag()...) and that made sense in Lua 4 since that's what Lua also
called the functions to work on Lua objects, in our case userdata. Lua
5 got rid of the idea of "tags" and now uses metatables. The Lua 4
functions gettag() and settag() are gone.
wxLua now calls the C++ objects that are pushed into Lua using
userdata, "wxLua types". I think this is more generic and there are
wxLua types that map to the lua_type()s LUA_TXXX as WXLUA_TXXX and are
negative, the wxLua types that are positive are C/C++ structs and
classes with their number generated at runtime. Numbers are used for
speed since using the string class/struct name is slower since Lua has
to hash every string to compare it.
How this affects you...
1) wxLuaState::PushUserTag() is removed and PushUserDataType() is now
wxluaT_PushUserDataType() which takes the parameters that
PushUserTag() did. These two functions were very similar and have been
combined.
2) The global integer "tags" or now wxLua types were named int
s_wxluatag_XXX and are now named g_wxluatype_XXX since they're not
static anymore and are the types.
3)... ? Hopefully not much else unless your C++ code is fairly advanced.
The bottom line, the wxLua functions have been renamed or reworked to
match the Lua functions so that people familiar with Lua can more
easily understand wxLua and people who become familar with wxLua will
also be learning Lua.
I hope this doesn't ruin anyone's holiday fun!
 John

Andre <arpin@...> writes:
> 
> Current version
> 
> VC7
> 
> nmake -f makefile.vc USE_OPENGL=1
> 
install a fresh copy
got these errors
canlua.cpp
'PushUserDataType' : is not a member of 'wxLuaState'
's_wxluatag_wxlCanObj' : undeclared identifier
even doing a clean sometime does not work

Current version
VC7
nmake -f makefile.vc USE_OPENGL=1
 
link /NOLOGO /OUT:..\..\..\bin\vc_lib\wxluacan.exe /LIBPATH:c:\Programs\wxWidg
ets\lib\vc_lib /DEBUG /LIBPATH:.
.\..\..\lib\vc_lib /LIBPATH:..\..\..\modules\lua\lib /SUBSYSTEM:WINDOWS 
@C:\DOCUME~1\Andre\LOCALS~1\Temp\nm21.tmp
app_wxluacan_canlua.obj : error LNK2019: unresolved external symbol "public: 
void __thiscall wxLuaState::PushUserDataTyp
e(int,void const *)" (?PushUserDataType@wxLuaState@@QAEXHPBX@Z) referenced in 
function "public: virtual void __thiscall
wxlCanObjScript::DoDraw(class wxDC &,double,double)" (?
DoDraw@wxlCanObjScript@@UAEXAAVwxDC@@NN@Z)
app_wxluacan_canlua.obj : error LNK2001: unresolved external symbol "int 
s_wxluatag_wxDC" (?s_wxluatag_wxDC@@3HA)
app_wxluacan_canlua.obj : error LNK2001: unresolved external symbol "int 
s_wxluatag_wxlCanObj" (?s_wxluatag_wxlCanObj@@3
HA)
..\..\..\bin\vc_lib\wxluacan.exe : fatal error LNK1120: 3 unresolved externals
NMAKE : fatal error U1077: 'link' : return code '0x460'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio .NET 2003
\VC7\BIN\nmake.exe"' : return code '0x2'
Stop.
Andre

John Labenski wrote:
> On Dec 23, 2007 9:21 AM, klaas.holwerda <ng...@kl...> wrote:
> 
> I had actually changed code to make this possible, before you could
> only have a pointer to C++ be one type, say a wxWindow, but if a
> function returns it as a wxEvtHandler it'd swap all the references to
> the object to a wxEvtHandler from being a wxWindow.
>
> 
>> What do you think?
>> 
>
> I tried adding an extra pointer for wxRED, which I know is not exactly
> the same since it sounds like you're casting the same object to two
> types, but at least this works.
> 
No I am not casting, the base class and the derived class have and are 
only one instance in the program.
So they are initialized to the "this" pointer of the class instance, 
that is why they have the same value.
They are used inside the lau script to get to the commandhandler/wrapper.
But of course the base class pointer is of the base class type, so only 
use-able for all the commands in that baseclass.
While the derived class commands can be called via the derived class 
pointer.
So two different pointers to exactly the same address are pushed into lua.
>
> Could you update to the newest CVS, regenerate your bindings and try again.
>
> 
I already used the latest, but will try again soon.
> I assume it will still fail and I'm guessing in this function. Try
> putting some statements like this into it for debugging.
>
> bool LUACALL wxluaT_pushuserdatatype(lua_State* L, const void
> *obj_ptr, int wxl_type, bool track, bool allow_NULL)
> {
> ...
> wxPrintf(wxT("pushuserdatatype1 %p %p pushing %p type %d\n"),
> a2dLuaWP, a2dMaskProc, obj_ptr, wxl_type);
> if (wxluaO_istrackedweakobject(L, (void*)obj_ptr, wxl_type, true))
> return true;
> wxPrintf(wxT("pushuserdatatype2 %p %p pushing %p type %d\n"),
> a2dLuaWP, a2dMaskProc, obj_ptr, wxl_type);
>
>
> Then if it fails the second time it was pushed I'd guess it was inside
> of wxluaO_istrackedweakobject and see where it fails there.
>
> Thanks for looking into this, I'd really like this sort of stuff working,
> 
Will try soon, bit to busy eating these days :-(
Glad to do something back, still working on the problem with the static 
const in the other thread, i am affraid another issue to come ;-)
Thanks,
Klaas

On Dec 23, 2007 9:21 AM, klaas.holwerda <ng...@kl...> wrote:
> Hi John,
>
> I think i found the problem, it seems one can have not two pointers to
> the same location.
> The base class of MaskprocLuaWrapper has the pointer down here called
> a2dLuaWP.
> It has of course the same value as the pointer in the derived class. But
> in the derived class it is called a2dMaskProc.
> No if i outcoment the first %define_pointer a2dLuaWP, all is fine. But
> if not i get the assertion.
>
> And i think the assertion at this spot is not a coincidence, if i
> look at the name.
>
> luaO_rawequalObj(const lua_TValue * 0x4d678191, const lua_TValue * 0x02005698)
> line 73 + 6 bytes
>
> Still this should not be a problem (at least if %delete means what i thought it meant).
> Maybe to make this work properly we need some smart pointer??
Nothing should be deleted at initialization nor should the garbage
collector run.
> So in short i have a global pointer to a command interpreter in a library, and in my application the derived class has a global pointer to the same (but derived class).
> And both those pointer i like to wrap.
I had actually changed code to make this possible, before you could
only have a pointer to C++ be one type, say a wxWindow, but if a
function returns it as a wxEvtHandler it'd swap all the references to
the object to a wxEvtHandler from being a wxWindow.
> What do you think?
I tried adding an extra pointer for wxRED, which I know is not exactly
the same since it sounds like you're casting the same object to two
types, but at least this works.
%class wxColour ...
 %rename wxRED %define_pointer wxLua_wxRED
 %rename wxREDA %define_pointer wxLua_wxRED
Could you update to the newest CVS, regenerate your bindings and try again.
I assume it will still fail and I'm guessing in this function. Try
putting some statements like this into it for debugging.
bool LUACALL wxluaT_pushuserdatatype(lua_State* L, const void
*obj_ptr, int wxl_type, bool track, bool allow_NULL)
{
...
 wxPrintf(wxT("pushuserdatatype1 %p %p pushing %p type %d\n"),
a2dLuaWP, a2dMaskProc, obj_ptr, wxl_type);
 if (wxluaO_istrackedweakobject(L, (void*)obj_ptr, wxl_type, true))
 return true;
 wxPrintf(wxT("pushuserdatatype2 %p %p pushing %p type %d\n"),
a2dLuaWP, a2dMaskProc, obj_ptr, wxl_type);
Then if it fails the second time it was pushed I'd guess it was inside
of wxluaO_istrackedweakobject and see where it fails there.
Thanks for looking into this, I'd really like this sort of stuff working,
 John
> //-------------------- first binding module
> luabind.i file
>
> %class %delete %noclassinfo a2dLuaWrapper, a2dCommandLanguageWrapper
> //%define_pointer a2dLuaWP
> a2dLuaWrapper( a2dCentralCanvasCommandProcessor* commandProcessor )
> ...........................
> %endclass
>
> //-------------------- second binding module
> maskproc.i
>
> %class %delete %noclassinfo MaskprocLuaWrapper, a2dLuaWrapper
> MaskprocLuaWrapper( a2dCentralEditorCommandProcessor*
> commandProcessor )
> bool Exit()
>
> %define_pointer a2dMaskProc
>
> %endclass
>
>
> John Labenski wrote:
> > On Dec 21, 2007 10:31 AM, Klaas Holwerda <db...@nl...> wrote:
> >
> >> If i remove "%define_pointer a2dMaskProc", the RegisterBindings() fase is fine.
> >> The function a2dGetMaskProc() return the same pointer, and i tested a few script
> >>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>

Hi John,
I think i found the problem, it seems one can have not two pointers to 
the same location.
The base class of MaskprocLuaWrapper has the pointer down here called 
a2dLuaWP.
It has of course the same value as the pointer in the derived class. But 
in the derived class it is called a2dMaskProc.
No if i outcoment the first %define_pointer a2dLuaWP, all is fine. But 
if not i get the assertion.
And i think the assertion at this spot is not a coincidence, if i 
look at the name.
luaO_rawequalObj(const lua_TValue * 0x4d678191, const lua_TValue * 0x02005698) 
line 73 + 6 bytes
Still this should not be a problem (at least if %delete means what i thought it meant).
Maybe to make this work properly we need some smart pointer??
So in short i have a global pointer to a command interpreter in a library, and in my application the derived class has a global pointer to the same (but derived class).
And both those pointer i like to wrap.
What do you think?
Klaas
//-------------------- first binding module
luabind.i file
%class %delete %noclassinfo a2dLuaWrapper, a2dCommandLanguageWrapper
 //%define_pointer a2dLuaWP
 a2dLuaWrapper( a2dCentralCanvasCommandProcessor* commandProcessor )
...........................
%endclass
//-------------------- second binding module
maskproc.i
%class %delete %noclassinfo MaskprocLuaWrapper, a2dLuaWrapper
 MaskprocLuaWrapper( a2dCentralEditorCommandProcessor* 
commandProcessor ) 
 bool Exit() 
 
 %define_pointer a2dMaskProc
 
%endclass
John Labenski wrote:
> On Dec 21, 2007 10:31 AM, Klaas Holwerda <db...@nl...> wrote:
> 
>> If i remove "%define_pointer a2dMaskProc", the RegisterBindings() fase is fine.
>> The function a2dGetMaskProc() return the same pointer, and i tested a few script
>> 

John Labenski wrote:
> Find "a2dMaskProc" in the generated C++ code, it should be in a
> wxLuaBindObject as { "a2dMaskProc", g_wxluatag_XXX, NULL, (const
> void**)&a2dMaskProc }. Of course, you should be using %define_pointer
> if and only if a2dMaskProc is declared in C++ as "MaskprocLuaWrapper*
> a2dMaskProc;" and %define_object if this "MaskprocLuaWrapper
> a2dMaskProc;".
> 
Its is a real pointer, i checked its value, as it was assigned in C++ at 
the start, and this value it has in wxlObject->pObjPtr when 
wxluaT_pushusertag()is called for it. I think wxlObject contains the 
right info at that point, but why lua_rawset is failing deep down, i 
don't know.
The wrapping/binding seems fine, it is as you said it should be.
> wxluaT_pushusertag(L, *wxlObject->pObjPtr,
> *wxlObject->wxluatype, true);
>
> lua_rawset(L, -3);
> }
>
> Hope this helps,
> 
I am afraid not, and since it worked all the time since my last upgrade 
to CVS, i think there may be a bug hanging around.
To bad i don't know how to find it. It might be something else is 
responsible for destroying memory, and only this only pointer in the 
last binding makes this clear. Also this part of the code is passed 
several times without problem, so ...
I keep trying, who knows i find something. For me its like a black box 
inside lua. I understand you can't say much about it.
Thanks!
Klaas

T24gRGVjIDIwLCAyMDA3IDM6NDkgQU0sIEhha2v9IERv8HVzYW4gPGhkQGRvZ3VzYW4ubmV0PiB3
cm90ZToKPiBIaSwKPgo+IEFjY29yZGluZyB0byBkb2MsICJQYXNzaW5nIGEgTlVMTCB2YWx1ZSAo
bm90IGVtcHR5IHN0cmluZykgdG8gdGhpcwo+IGZ1bmN0aW9uIGRpc2FibGVzIG1lc3NhZ2UgdGlt
ZXN0YW1waW5nIi4KCk9rLCB0aGVuIGl0IGhhcyB0byBiZSBvdmVycmlkZGVuIHRvIGFsbG93IG5p
bCB0byBiZSBwYXNzZWQgaW4uIEl0J3MKZml4ZWQgdGhlIG5leHQgdGltZSBJIGNvbW1pdCB0aGUg
Q1ZTLgoKVGhhbmtzLAogICAgSm9obgo=

On Dec 21, 2007 4:38 AM, Eero Pajarre <epa...@ko...> wrote:
> John Labenski wrote:
> > MSW Binary only release for now since the build files do not account
> > for the options to build the wxWidgets binding libs and which ones to
> > link to. Hopefully this will be fixed soon and the source code and (if
> > we're lucky) an OSX binary release will be made too.
>
> I apologise for asking a possibly stupid question...
>
>
> It looks like that the source code package for 2.8.4.2 was never made?
Probably not.
> If this is the case, how stable is the current CVS version?
Usually pretty good, right now I'm making huge changes to remove the
terminology of "tags" since that's from the Lua 4.0 days and Lua 5.x
replaced them with metatables. The new terminology will be wxLua
types. It is taking much longer than expected however.
I always test a couple samples and make sure the C++ code compiles in
whatever system I'm using before I commit any changes, but there are
differences between gcc and Visual Studio, but they're usually
trivial.
> I have been using wxLua for a rather long time, and now
> I am thinking of updating the version I am currently using,
> because the old version seems to have some bugs hidden inside.
There are *many* fixes and improvements in the CVS version.
Regards,
 John

On Dec 21, 2007 10:31 AM, Klaas Holwerda <db...@nl...> wrote:
> Hi John,
>
> One of my last bindings is this, which always worked fine.
> I do not get any errors when building the bindings, but when the program start i
> get an error. See the stack dump down here.
> If i remove "%define_pointer a2dMaskProc", the RegisterBindings() fase is fine.
> The function a2dGetMaskProc() return the same pointer, and i tested a few script
> using that instead of a2dMaskProc itself, and they work.
> So i wonder what is going on. When i look at wxlObject->pObjPtr just before the
> call to lua_rawset, it contains the right info as far as i can see.
> It is not the only place i use %define_pointer e.g also in its base class.
> Is that maybe what luaO_rawequalObj sees as a problem??
> I think my bindings are oke, and something else is wrong :-)
> Can you give me some hints, or maybe even better, is this already enough for you
> to find an error in the binding generation?
>
> Regards
> and Happy Christmas to all of you.
>
> Klaas
>
> %class %delete %noclassinfo a2dCentralEditorCommandProcessor
> %endclass
>
> %define_string a2dMASKPROC_VERSION
>
> %class %delete %noclassinfo MaskprocLuaWrapper, a2dLuaWrapper
> MaskprocLuaWrapper( a2dCentralEditorCommandProcessor* commandProcessor )
> bool Exit()
>
> %define_pointer a2dMaskProc
>
> %endclass
>
> %function MaskprocLuaWrapper* a2dGetMaskProc()
>
>
> Here the stack dump.
>
> luaO_rawequalObj(const lua_TValue * 0x4d678191, const lua_TValue * 0x02005698)
> line 73 + 6 bytes
> luaH_get(Table * 0x02174a30, const lua_TValue * 0x02005698) line 484 + 16 bytes
> luaH_set(lua_State * 0x020053a8, Table * 0x02174a30, const lua_TValue *
> 0x02005698) line 495 + 13 bytes
> lua_rawset(lua_State * 0x020053a8, int -3) line 673 + 37 bytes
> wxLuaBinding::DoRegisterBinding(const wxLuaState & {...}, int 1) line 1193 + 11
Find "a2dMaskProc" in the generated C++ code, it should be in a
wxLuaBindObject as { "a2dMaskProc", g_wxluatag_XXX, NULL, (const
void**)&a2dMaskProc }. Of course, you should be using %define_pointer
if and only if a2dMaskProc is declared in C++ as "MaskprocLuaWrapper*
a2dMaskProc;" and %define_object if this "MaskprocLuaWrapper
a2dMaskProc;".
If the above is not the problem, can you debug this code in
wxLuaBinding::DoRegisterBinding? I'm guessing the problem is in
wxluaT_pushusertag().
 const wxLuaBindObject *wxlObject = m_objectArray;
 for (n = 0; n < m_objectCount; ++n, ++wxlObject)
 {
 lua_pushstring(L, wxlObject->name);
 if (wxlObject->objPtr != 0)
 wxluaT_pushusertag(L, wxlObject->objPtr,
*wxlObject->wxluatype, true);
 else
 wxluaT_pushusertag(L, *wxlObject->pObjPtr,
*wxlObject->wxluatype, true);
 lua_rawset(L, -3);
 }
Hope this helps,
 John

On Dec 19, 2007 9:22 AM, Klaas Holwerda <db...@nl...> wrote:
> Hi John or other wrappers,
>
> Do you have an idea how i can wrap the next (static const member )
>
> class A2DEDITORDLLEXP a2dDrawRectangleTool: public a2dStDrawTool
> {
> public:
> static const a2dCommandId COMID_PushTool_DrawRectangle;
>
>
> I tried:
>
> %class %noclassinfo a2dCommandId
> %endclass
>
> %class %noclassinfo a2dDrawRectangleTool
> %member const a2dCommandId COMID_PushTool_DrawRectangle;
> %endclass
>
> And although this compiles in C++, the next line is a not working in wxLua.
>
> wx.a2dMaskProc:PushTool( wx.a2dDrawRectangleTool.COMID_PushTool_DrawRectangle )
>
> Error: lua: Syntax error during pre-compilation
> [string "*tools.lua"]:2: function arguments expected near ')'
>
> Or am i doing something wrong to call it?
You don't have the static keyword after the %member tag. I think that
should work.
Compare the C++ output with that of wxPoint's x %member.
> I must admit i am not using the latest CVS version.
I don't remember if the last release supports this, there's been many
changes and fixes for things like this.
Regards,
 John

Hi John,
One of my last bindings is this, which always worked fine.
I do not get any errors when building the bindings, but when the program start i 
get an error. See the stack dump down here.
If i remove "%define_pointer a2dMaskProc", the RegisterBindings() fase is fine.
The function a2dGetMaskProc() return the same pointer, and i tested a few script 
using that instead of a2dMaskProc itself, and they work.
So i wonder what is going on. When i look at wxlObject->pObjPtr just before the 
call to lua_rawset, it contains the right info as far as i can see.
It is not the only place i use %define_pointer e.g also in its base class.
Is that maybe what luaO_rawequalObj sees as a problem??
I think my bindings are oke, and something else is wrong :-)
Can you give me some hints, or maybe even better, is this already enough for you 
to find an error in the binding generation?
Regards
and Happy Christmas to all of you.
Klaas
%class %delete %noclassinfo a2dCentralEditorCommandProcessor
%endclass
%define_string a2dMASKPROC_VERSION
%class %delete %noclassinfo MaskprocLuaWrapper, a2dLuaWrapper
 MaskprocLuaWrapper( a2dCentralEditorCommandProcessor* commandProcessor )
 bool Exit()
 %define_pointer a2dMaskProc
%endclass
%function MaskprocLuaWrapper* a2dGetMaskProc()
Here the stack dump.
luaO_rawequalObj(const lua_TValue * 0x4d678191, const lua_TValue * 0x02005698) 
line 73 + 6 bytes
luaH_get(Table * 0x02174a30, const lua_TValue * 0x02005698) line 484 + 16 bytes
luaH_set(lua_State * 0x020053a8, Table * 0x02174a30, const lua_TValue * 
0x02005698) line 495 + 13 bytes
lua_rawset(lua_State * 0x020053a8, int -3) line 673 + 37 bytes
wxLuaBinding::DoRegisterBinding(const wxLuaState & {...}, int 1) line 1193 + 11 
bytes
wxLuaBinding::RegisterBinding(const wxLuaState & {...}) line 988
wxLuaState::RegisterBindings() line 2687
wxLuaState::Create(lua_State * 0x020053a8, int 2) line 2220
wxLuaState::Create(wxEvtHandler * 0x01f71740, int -1) line 2113 + 14 bytes
wxLuaState::wxLuaState(wxEvtHandler * 0x01f71740, int -1) line 615 + 75 bytes
MaskprocLuaWrapper::MaskprocLuaWrapper(a2dCentralCanvasCommandProcessor * 
0x01ff8170) line 569 + 16 bytes
MyApp::OnInit() line 354 + 72 bytes
wxAppConsole::CallOnInit() line 76 + 28 bytes
wxEntryReal(int & 1, char * * 0x01f70f50) line 436 + 25 bytes
wxEntry(int & 1, char * * 0x01f70f50) line 209 + 13 bytes
wxEntry(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, HINSTANCE__ * 
0x00000000, int 1) line 386 + 13 bytes
WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00051f1e, 
int 1) line 208 + 24 bytes
WinMainCRTStartup() line 330 + 54 bytes
KERNEL32! 77e735dd()
-- 
Unclassified

On Dec 21, 2007 8:55 AM, Klaas Holwerda <db...@nl...> wrote:
> Hi,
>
> I think many people must be frustrated by this problem.
> I have the wxWidgets wxmsw28_gl.lib ( yes by #define wxUSE_GLCANVAS
> 1 in
> setup.h of wxWidgets)
> But still:
>
> nmake -f makefile.vc
>
> gives me de link error inside wxLua itself.
>
> app_wxluafreeze_wxluafreeze.obj : error LNK2001: unresolved external
> symbol "boo
> l __cdecl wxLuaBinding_wxgl_init(void)" (?wxLuaBinding_wxgl_init@@YA_NXZ)
> ..\..\..\bin\vc_lib\wxluafreeze.exe : fatal error LNK1120: 1 unresolved
> external
> s
> NMAKE : fatal error U1077: 'link' : return code '0x460'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual
> Studio\VC98\bin\N
> MAKE.EXE"' : return code '0x2'
> Stop.
>
> MY solution is to go to wxluafreeze.cpp and outcomment:
>
> WXLUA_DECLARE_BIND_WXGL
> WXLUA_IMPLEMENT_BIND_WXGL
>
>
> In fact the stc i also have in wxWidgets compiled:
> And putting back in wxluafreeze.cpp those two, gives the similar error.
>
> WXLUA_DECLARE_BIND_WXSTC
> WXLUA_IMPLEMENT_BIND_WXSTC
>
> So it looks like this wxluafreeze target is not getting the right
> libraries
> linked into it.
>
> Anyway i hope this helps some to compile wxLua
>
> Klaas
>
Oh boy this is a good idea. I can't build wxLua at all with the supplied
makefiles. This issue needs to be improved. I will try this and see how it
goes.
-- 
Regards,
Ryan
RJP Computing

Hi,
I think many people must be frustrated by this problem.
I have the wxWidgets wxmsw28_gl.lib ( yes by #define wxUSE_GLCANVAS 1 in 
setup.h of wxWidgets)
But still:
nmake -f makefile.vc
gives me de link error inside wxLua itself.
app_wxluafreeze_wxluafreeze.obj : error LNK2001: unresolved external symbol "boo
l __cdecl wxLuaBinding_wxgl_init(void)" (?wxLuaBinding_wxgl_init@@YA_NXZ)
..\..\..\bin\vc_lib\wxluafreeze.exe : fatal error LNK1120: 1 unresolved external
s
NMAKE : fatal error U1077: 'link' : return code '0x460'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio\VC98\bin\N
MAKE.EXE"' : return code '0x2'
Stop.
MY solution is to go to wxluafreeze.cpp and outcomment:
 WXLUA_DECLARE_BIND_WXGL
 WXLUA_IMPLEMENT_BIND_WXGL
In fact the stc i also have in wxWidgets compiled:
And putting back in wxluafreeze.cpp those two, gives the similar error.
	WXLUA_DECLARE_BIND_WXSTC
	WXLUA_IMPLEMENT_BIND_WXSTC
So it looks like this wxluafreeze target is not getting the right libraries 
linked into it.
Anyway i hope this helps some to compile wxLua
Klaas
-- 
Unclassified

John Labenski wrote:
> MSW Binary only release for now since the build files do not account
> for the options to build the wxWidgets binding libs and which ones to
> link to. Hopefully this will be fixed soon and the source code and (if
> we're lucky) an OSX binary release will be made too.
I apologise for asking a possibly stupid question...
It looks like that the source code package for 2.8.4.2 was never made?
If this is the case, how stable is the current CVS version?
I have been using wxLua for a rather long time, and now
I am thinking of updating the version I am currently using,
because the old version seems to have some bugs hidden inside.
I am using Windows (XP), but I cannot use the -dll release,
because I want to compile my application which uses wxLua to
a single (statically linked) file.
 Eero

Hi,
According to doc, "Passing a NULL value (not empty string) to this 
function disables message timestamping".
--
Regards,
Hakki Dogusan

Hi John or other wrappers,
Do you have an idea how i can wrap the next (static const member )
class A2DEDITORDLLEXP a2dDrawRectangleTool: public a2dStDrawTool
{
public:
 static const a2dCommandId COMID_PushTool_DrawRectangle;
I tried:
%class %noclassinfo a2dCommandId
%endclass
%class %noclassinfo a2dDrawRectangleTool
 %member const a2dCommandId COMID_PushTool_DrawRectangle;
%endclass
And although this compiles in C++, the next line is a not working in wxLua.
wx.a2dMaskProc:PushTool( wx.a2dDrawRectangleTool.COMID_PushTool_DrawRectangle )
Error: lua: Syntax error during pre-compilation
[string "*tools.lua"]:2: function arguments expected near ')'
Or am i doing something wrong to call it?
I must admit i am not using the latest CVS version.
Thanks,
Klaas
-- 
Unclassified

On Dec 18, 2007 12:51 AM, John Labenski <jla...@gm...> wrote:
>
> I will update it. The problem is that SF got rid of running nightly cron
> jobs.
That is too bad. Thanks for the update. Is SF going to bring them back?
I don't know subversion very well, but it does seem to be the future.
>
I am very familiar with Subversion, so I can offer help if you would like.
Just ask questions.
-- 
Regards,
Ryan

Hi,
John Labenski yazmış:
> On Dec 16, 2007 6:59 AM, Hakkı Doğusan <hd...@do...> wrote:
>> Hi,
>>
>> I translated mentioned sample to wxLua.
>>
>> http://www.dynaset.org/dogusanh/download/wxluaimage.zip (448Kb)
> 
> Great!
> 
>> - Designed to work in wxLua/samples/wximage folder
> 
> I wish the images that it uses weren't so large. I wonder if we need
> them all since they're really for the C++ library to test if the
> loaders work as expected. I think it's safe for wxLua to assume that
> they do. Any thoughts before I add it?
> 
I translated this sample because of a message sent to Lua list:
Habib wrote:
 > [snip]
 > Thefore first I tried: wxWidgets. Dropped it when I couldn't find any 
easy way to display a JPEG on the screen. Hacking it will be more 
troublesome than it's worth.
Hence, I believe it would be good to show all loaders in action. Can we 
replace images with something else in tiny size?
>> - Some parts are commented out with --[[FIXME
> 
> All fixed, except for the wxPixelData iterators. That may have to wait
> until the new year since they look a little tricky at first glance.
> 
Thanks.
>> - There is a flag to prevent one slow operation
> 
> I added wxImage::GetData() and it's much faster.
> 
Ok.
>> - There is a bug I left, about wx.wxFileSelector usage
> 
> wxLua uses the newer (well, still pretty old) version where you only
> pass in a wxArrayString/table with strings.
> 
Thanks. In a quick hacking mode, I tried something, then left it :)
> =============
> 
> I've also made wxApp::MainLoop() callable multiple times and
> require("wx") do nothing if already loaded so that we can add
> require("wx") as well as the wxGetApp().MainLoop() call to all the
> samples and they'll work using DLLs or the executables.
> 
Excellent! It'll help writing samples.
> =============
> 
> I really like this
> 
> function win.OnPaint(win, event) ... end
> win:Connect(wx.wxEVT_PAINT, function(event) win:OnPaint(event) end)
> 
> 
> But I'm not sure about the usefulness of modules inside of a single
> file. Since you lose the globals and there's so many local vars it
> makes it harder to debug. I'm guessing that you're doing it this way
> to simulate a C++ class. Are there any advantages in doing it this way
> that I'm missing?
> 
For "all in one file" samples? No.. I'm trying to make it a habit of 
myself :) It helps more controlled writing..
> Regards,
> John
ps. Could you please add Code::Blocks project files to cvs? They're only 
13Kb.
--
Regards,
Hakki Dogusan

On Dec 18, 2007 12:45 AM, Ryan Pusztai <rpu...@gm...> wrote:
> Hi,
> The nightly snapshots seem to be a bit old. The latest one is dated
> 12-02-1007. Is this intentional? I can't use CVS from work because of the
> firewall, so this is the way I get my source. Is there any better way to get
I will update it. The problem is that SF got rid of running nightly cron jobs.
> it? Is Subversion going to be an option?
I don't know subversion very well, but it does seem to be the future.
Regards,
 John

Hi,
The nightly snapshots seem to be a bit old. The latest one is dated
12-02-1007. Is this intentional? I can't use CVS from work because of the
firewall, so this is the way I get my source. Is there any better way to get
it? Is Subversion going to be an option?
-- 
Regards,
Ryan
RJP Computing

T24gRGVjIDE2LCAyMDA3IDY6NTkgQU0sIEhha2v9IERv8HVzYW4gPGhkQGRvZ3VzYW4ubmV0PiB3
cm90ZToKPiBIaSwKPgo+IEkgdHJhbnNsYXRlZCBtZW50aW9uZWQgc2FtcGxlIHRvIHd4THVhLgo+
Cj4gaHR0cDovL3d3dy5keW5hc2V0Lm9yZy9kb2d1c2FuaC9kb3dubG9hZC93eGx1YWltYWdlLnpp
cCAoNDQ4S2IpCgpHcmVhdCEKCj4gLSBEZXNpZ25lZCB0byB3b3JrIGluIHd4THVhL3NhbXBsZXMv
d3hpbWFnZSBmb2xkZXIKCkkgd2lzaCB0aGUgaW1hZ2VzIHRoYXQgaXQgdXNlcyB3ZXJlbid0IHNv
IGxhcmdlLiBJIHdvbmRlciBpZiB3ZSBuZWVkCnRoZW0gYWxsIHNpbmNlIHRoZXkncmUgcmVhbGx5
IGZvciB0aGUgQysrIGxpYnJhcnkgdG8gdGVzdCBpZiB0aGUKbG9hZGVycyB3b3JrIGFzIGV4cGVj
dGVkLiBJIHRoaW5rIGl0J3Mgc2FmZSBmb3Igd3hMdWEgdG8gYXNzdW1lIHRoYXQKdGhleSBkby4g
QW55IHRob3VnaHRzIGJlZm9yZSBJIGFkZCBpdD8KCj4gLSBTb21lIHBhcnRzIGFyZSBjb21tZW50
ZWQgb3V0IHdpdGggLS1bW0ZJWE1FCgpBbGwgZml4ZWQsIGV4Y2VwdCBmb3IgdGhlIHd4UGl4ZWxE
YXRhIGl0ZXJhdG9ycy4gVGhhdCBtYXkgaGF2ZSB0byB3YWl0CnVudGlsIHRoZSBuZXcgeWVhciBz
aW5jZSB0aGV5IGxvb2sgYSBsaXR0bGUgdHJpY2t5IGF0IGZpcnN0IGdsYW5jZS4KCj4gLSBUaGVy
ZSBpcyBhIGZsYWcgdG8gcHJldmVudCBvbmUgc2xvdyBvcGVyYXRpb24KCkkgYWRkZWQgd3hJbWFn
ZTo6R2V0RGF0YSgpIGFuZCBpdCdzIG11Y2ggZmFzdGVyLgoKPiAtIFRoZXJlIGlzIGEgYnVnIEkg
bGVmdCwgYWJvdXQgd3gud3hGaWxlU2VsZWN0b3IgdXNhZ2UKCnd4THVhIHVzZXMgdGhlIG5ld2Vy
ICh3ZWxsLCBzdGlsbCBwcmV0dHkgb2xkKSB2ZXJzaW9uIHdoZXJlIHlvdSBvbmx5CnBhc3MgaW4g
YSB3eEFycmF5U3RyaW5nL3RhYmxlIHdpdGggc3RyaW5ncy4KCj09PT09PT09PT09PT0KCkkndmUg
YWxzbyBtYWRlIHd4QXBwOjpNYWluTG9vcCgpIGNhbGxhYmxlIG11bHRpcGxlIHRpbWVzIGFuZApy
ZXF1aXJlKCJ3eCIpIGRvIG5vdGhpbmcgaWYgYWxyZWFkeSBsb2FkZWQgc28gdGhhdCB3ZSBjYW4g
YWRkCnJlcXVpcmUoInd4IikgIGFzIHdlbGwgYXMgdGhlIHd4R2V0QXBwKCkuTWFpbkxvb3AoKSBj
YWxsIHRvIGFsbCB0aGUKc2FtcGxlcyBhbmQgdGhleSdsbCB3b3JrIHVzaW5nIERMTHMgb3IgdGhl
IGV4ZWN1dGFibGVzLgoKPT09PT09PT09PT09PQoKSSByZWFsbHkgbGlrZSB0aGlzCgpmdW5jdGlv
biB3aW4uT25QYWludCh3aW4sIGV2ZW50KSAuLi4gZW5kCndpbjpDb25uZWN0KHd4Lnd4RVZUX1BB
SU5ULCBmdW5jdGlvbihldmVudCkgd2luOk9uUGFpbnQoZXZlbnQpIGVuZCkKCgpCdXQgSSdtIG5v
dCBzdXJlIGFib3V0IHRoZSB1c2VmdWxuZXNzIG9mIG1vZHVsZXMgaW5zaWRlIG9mIGEgc2luZ2xl
CmZpbGUuIFNpbmNlIHlvdSBsb3NlIHRoZSBnbG9iYWxzIGFuZCB0aGVyZSdzIHNvIG1hbnkgbG9j
YWwgdmFycyBpdAptYWtlcyBpdCBoYXJkZXIgdG8gZGVidWcuIEknbSBndWVzc2luZyB0aGF0IHlv
dSdyZSBkb2luZyBpdCB0aGlzIHdheQp0byBzaW11bGF0ZSBhIEMrKyBjbGFzcy4gQXJlIHRoZXJl
IGFueSBhZHZhbnRhZ2VzIGluIGRvaW5nIGl0IHRoaXMgd2F5CnRoYXQgSSdtIG1pc3Npbmc/CgpS
ZWdhcmRzLAogICAgSm9obgo=

T24gRGVjIDE3LCAyMDA3IDg6NTggUE0sIEhha2v9IERv8HVzYW4gPGhkQGRvZ3VzYW4ubmV0PiB3
cm90ZToKCj4gSSd2ZSBwdXQgYSBmaWxlIGNvbnRhaW5pbmcgbHVhLmNicCwgd3hsdWEuY2JwIGhl
cmU6Cj4KPiBodHRwOi8vd3d3LmR5bmFzZXQub3JnL2RvZ3VzYW5oL2Rvd25sb2FkL3d4THVhLUNv
ZGVCbG9ja3MuemlwCj4KPiAtIEkgdGVzdGVkIHRoZW0gYWdhaW5zdCBjdXJyZW50IGN2cwo+IC0g
d3gtMi44LjcgYnVpbGQgd2l0aAo+ICAgbWluZ3czMi1tYWtlIC1mbWFrZWZpbGUuZ2NjIE1PTk9M
SVRISUM9MSBCVUlMRD1yZWxlYXNlIFVOSUNPREU9MQo+IC0gcHJvamVjdCdzIHBhdGhzIGFkanVz
dGVkIHRvIHdvcmsgaW4gd3hMdWEvYnVpbGQvQ29kZUJsb2NrcyBmb2xkZXIKPgo+IC0tCj4gUmVn
YXJkcywKPiBIYWtraSBEb2d1c2FuIDxodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0
cy9saXN0aW5mby93eGx1YS11c2Vycz4KPgoKCk5pY2UhIFRoaXMgaXMgZ3JlYXRseSBhcHByZWNp
YXRlZC4gSSBoYXZlIGJlZW4gbG9va2luZyBmb3IgdGhpcyBzb2x1dGlvbiBmb3IKYSB3aGlsZS4g
VGhhbmtzLgotLSAKUmVnYXJkcywKUnlhbgpSSlAgQ29tcHV0aW5nCg==

T24gRGVjIDE3LCAyMDA3IDk6MDMgUE0sIEhha2v9IERv8HVzYW4gPGhkQGRvZ3VzYW4ubmV0PiB3
cm90ZToKPiBIaSwKPgo+IChjdXJyZW50IGN2cywgbWluZ3csIHdpbnhwKQo+Cj4gUmVtb3ZlZCBp
bmxpbmUgaW4gd3hsc3RhdGUuaCBwcmV2ZW50cyBtaW5ndyB0byBsaW5rIChtdWx0aXBsZSBkZWZp
bml0aW9uCj4gZXJyb3IpLgoKVGhhbmtzLCBmaXhlZCBub3cuIE1TVkMgZG9lc24ndCBoYXZlIHRo
YXQgcHJvYmxlbS4KClJlZ2FyZHMsCiAgICBKb2huCg==

Hi,
(current cvs, mingw, winxp)
Removed inline in wxlstate.h prevents mingw to link (multiple definition 
error).
--
Regards,
Hakki Dogusan