wxlua-users Mailing List for wxLua

John Labenski <jla...@gm...> wrote:
(19/08/2005 19:05)
>
>Looks very impressive, I'll check it out this weekend, does it even
>run if you don't have a Yamaha DX7 keyboard?
>
Yes. :) That's one of the cool things about it, you can work with SysEx files in the ansence of any hardware other than host machine for DX7-EDIT, but there's no substitute for using a synthesiser to get the full sense of why this might be truly useful. If you were ever thinking about getting an FM synthesizer, I'd suggest the FS1R, there is never likely to be a better one, unless someone starts where that left off. It's a small 1 unit rack, but it's not cheap or commonly found.
>One thing I noticed about the code though, you used absolute sizes for
>things. You may want to use wxSizers in case someone uses a different
>(larger) default font size. You can use wxGlade,
>http://wxglade.sourceforge.net/ , to get a good idea how sizers work
>by creating different things and looking at the output. It should be
>easy to translate it from either c++ or python to wxLua. I think you
>can even keep the code the same, just add the controls to the sizers
>you create at the end of each page. This will keep the code pretty
>clean.
>
I know.. I decided early on to do this though, for now. I wanted a very compact GUI. I thought that maybe sizers might cause some problems I can't even predict as easily as I can the effects of a large font in this thing, so I decided to let this go and see what kind of feedback I get, and once I see what sorts of problems happen, I'll test sizers and changes to fixed sizes too, to see what will work. So much of this thing started out with fixed sizes, the only thing to do, for now, was to be consistent. :)

On 8/19/05, Crow <xo...@bl...> wrote:
> DX7-Edit is a MIDI SysEx File for Yamaha 6 operator FM synthesisers, and =
for anything that can use the standard SysEx message format for either bank=
s or single voices.
>=20
> It's working, though no doubt capable of improvements, especially as it's=
 stretching the use of wxLua just a tad.. :) Also, I tend to make my own er=
ror tests and such, and I think Lua itself offers things in built-in functi=
ons, so I'll be optimising stuff there, once I'm ready to look deeply at th=
is thing again.
Looks very impressive, I'll check it out this weekend, does it even
run if you don't have a Yamaha DX7 keyboard?
One thing I noticed about the code though, you used absolute sizes for
things. You may want to use wxSizers in case someone uses a different
(larger) default font size. You can use wxGlade,
http://wxglade.sourceforge.net/ , to get a good idea how sizers work
by creating different things and looking at the output. It should be
easy to translate it from either c++ or python to wxLua. I think you
can even keep the code the same, just add the controls to the sizers
you create at the end of each page. This will keep the code pretty
clean.
Regards,
 John Labenski

DX7-Edit is a MIDI SysEx File for Yamaha 6 operator FM synthesisers, and for anything that can use the standard SysEx message format for either banks or single voices.
It's working, though no doubt capable of improvements, especially as it's stretching the use of wxLua just a tad.. :) Also, I tend to make my own error tests and such, and I think Lua itself offers things in built-in functions, so I'll be optimising stuff there, once I'm ready to look deeply at this thing again.
Go here for a guide and some links: http://www.lostgallifreyan.pwp.blueyonder.co.uk
Thanks John (Labenski), you've helped a lot with ideas and questions answered. I hope this thing stimulates a bit of action from other people using wxLua, and maybe stimulates someone able to make a MIDI library for wxLua, perhaps. I've posted access to DX7-EDIT on my oubliette of a LiveJournal too, so there might be some attention coming via that if it's read by anyone at all. :)
Other than that I'll leave it to Google to index the pages somehow, it is good at that, better than I am.

Hi John,
Oke i will wait some more. I just had some time to work on it now :-(
And to bad, wxArt2D its bakefiles can not really be finished, since 
wxLua does not have them yet. And Francesco liked to have wxLua done 
first, because that made think a bit simpler, which i agree. I am 
affraid there is nothing i can do.
But if Ray is still busy with it, i just wait. I hope he takes into 
account the ideas that came up here. And it would be nice to get some 
idea of what it is going to be.
I will keep the Cmake files that i have now in a save place, so i will 
have little effort to add them later on.
Just for the record.
I have to conclude that wxLua as it is in CVS is not working properly 
right now, at least i can't get it compiled (without correction), and if 
compiled wxLua standalone does not work for me.
Regards,
Klaas
John Labenski wrote:
>Klaas, I hope the waiting doesn't put you out too much, any lua code
>you write will still work so you can work on that using the older
>wxLua...
> 
>

On 8/2/05, The Doctor <the...@bl...> wrote:
> >I guess I don't have the same problem, I took your sample code and
> >added buttons to them as a further test. (note that the wxID_OK/CANCEL
> >
> >BANK=3Dwx.wxDialog(PANEL,-1,"",wx.wxPoint(-1,-1),wx.wxSize(426,266))
> >CNFG=3Dwx.wxDialog(PANEL,-1,"",wx.wxPoint(-1,-1),wx.wxSize(426,266))
> >do
> > wx.wxButton(BANK, wx.wxID_OK, "Ok")
> > wx.wxButton(CNFG, wx.wxID_OK, "Ok")
> >end
>=20
> That was interesting. The second dialog still showed the failure to respo=
nd to the first click, but the use of Enter, as that button has focus, work=
s as it should, as you said. :)
> I don't know the reason for this, but it definitely seems related to the =
OS. I'm using 98-Lite, by Shane Brooks. Meaning it's a W95 shell on a W98 S=
E core. Some things hate=20
That sounds like a strange combo.
> Btw, why did you use do and end? I realised when I saw it, that it could =
be a neat way to declare local variables in the do ... end without leaving =
them around as they would be if declared outside that, but in this case I c=
an't see what the do ... end would add here.
I think I was going to do something with them or make them locals, but
then realized that I didn't even need to assign them to anything since
the parent would deal with them... So, no there's no reason to have
that.
> >I think the perfect solution is to create a Wiki on the web page. I
>=20
> Agreed. :) I like that far better. I do make mistakes, like the order of =
that=20
Good, I'll look into it.
>Is there a way to make uploaded binaries available to people who
didn't get the original
>email? Meaning: does the mailing list archive attachments? That
Thinger has a few
>bitmaps, one of which is too big to make into XML text conveniently.
I don't have any idea.
Regards,
 John Labenski

On 8/2/05, k. holwerda <kla...@nl...> wrote:
>=20
> I forgot to add the wx_Binding() which i outcommented.
> Now that is have wx_Binding() registered proberly the error popup has
> changed to the following:
>=20
> wxLua: Expected enum for parameter 6.
>=20
> Which i traced down to happening here, any idea what can be wrong?, Does
> it work for you?:
>=20
> getenumerationtype(lua_State * 0x018e9af0, int 6) line 1575
There are no wrapped %enums and %builtin functions currently, this is
a bug in the wrapper code that I haven't bothered to track down since
it'll be replaced. I've talked to Ray, see my other message. Can you
use the old wxLua for a while longer?
Regards,
 John Labenski

On 8/2/05, k. holwerda <kla...@nl...> wrote:
> Hi John,
>=20
> Maybe the best would be to do the next:
>=20
> m_luaInterpreter =3D new wxLuaInterpreter(this, -1);
> m_luaInterpreter->AddBinding( "wx_Binding" );
> m_luaInterpreter->RegisterBindings( true);
I agree that the wxLuaStateVariables shouldn't automatically add the
binding. It can be done as you say in the wxLuaInterpreter.
I spoke to Ray and he's still working, so instead of changing anything
lets wait for him to finish. The other problems you been having
compiling are due to %enums and %builtin functions not being put into
the wrappers. Until that is fixed we can't fully test things anyway.
Klaas, I hope the waiting doesn't put you out too much, any lua code
you write will still work so you can work on that using the older
wxLua...
Regards,
 John Labenski

On 8/2/05, k. holwerda <kla...@nl...> wrote:
> Does WXLUA_CODE always needs to be set 1?
>=20
> In lstate.c i found:
>=20
> #ifndef WXLUA_CODE
> ..................
> #else
> /* labenski - track child threads see wxLuaInterpreter.cpp */
> #include <luathread.h>
Yes, you need it set. This is to add the lua_State to the hash table
of known lua_States if you create a coroutine in lua.
-John Labenski

I forgot to add the wx_Binding() which i outcommented.
Now that is have wx_Binding() registered proberly the error popup has 
changed to the following:
wxLua: Expected enum for parameter 6.
Which i traced down to happening here, any idea what can be wrong?, Does 
it work for you?:
getenumerationtype(lua_State * 0x018e9af0, int 6) line 1575
wxToolBarBase_AddTool(lua_State * 0x018e9af0) line 1657 + 17 bytes
wxLuaFunction::CallMethod(lua_State * 0x018e9af0) line 524 + 14 bytes
callFunction(lua_State * 0x018e9af0) line 2029 + 12 bytes
luaD_precall(lua_State * 0x018e9af0, lua_TObject * 0x019cc310) line 260 
+ 18 bytes
luaV_execute(lua_State * 0x018e9af0) line 627 + 13 bytes
luaD_call(lua_State * 0x018e9af0, lua_TObject * 0x018e9d30, int -1) line 
313 + 9 bytes
f_call(lua_State * 0x018e9af0, void * 0x014afaa4) line 672 + 22 bytes
luaD_rawrunprotected(lua_State * 0x018e9af0, void (lua_State *, void *)* 
0x00531451 f_call(lua_State *, void *), void * 0x014afaa4) line 88 + 13 
bytes
luaD_pcall(lua_State * 0x018e9af0, void (lua_State *, void *)* 
0x00531451 f_call(lua_State *, void *), void * 0x014afaa4, int 144, int 
0) line 416 + 17 bytes
lua_pcall(lua_State * 0x018e9af0, int 0, int -1, int 0) line 685 + 32 bytes
aux_do(lua_State * 0x018e9af0, int 0) line 569 + 15 bytes
lua_dobuffer(lua_State * 0x018e9af0, const char * 0x00906028, unsigned 
int 51558, const char * 0x019701c0) line 583 + 34 bytes
wxLuaInterpreter::RunBuffer(const unsigned char * 0x00906028, unsigned 
int 51558, const wxString & {...}) line 705 + 61 bytes
wxLuaStandaloneApp::RunEditor() line 400
wxLuaStandaloneApp::OnInit() line 162 + 11 bytes
wxAppConsole::CallOnInit() line 87 + 28 bytes
wxEntryReal(int & 1, char * * 0x0034e3b0) line 401 + 25 bytes
wxEntry(int & 1, char * * 0x0034e3b0) line 216 + 13 bytes
wxEntry(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, HINSTANCE__ 
* 0x00000000, int 1) line 299 + 13 bytes
WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 
0x00041f17, int 1) line 97 + 24 bytes
WinMainCRTStartup() line 330 + 54 bytes
k. holwerda wrote:
> I get an error in a popup:
>
> (none):0: attempt to index global `wx`( a nil value)
>
> and next:
>
>
> Unclassified
>

Hi John,
Maybe the best would be to do the next:
 m_luaInterpreter = new wxLuaInterpreter(this, -1);
 m_luaInterpreter->AddBinding( "wx_Binding" );
 m_luaInterpreter->RegisterBindings( true);
bool wxLuaInterpreter::AddBinding( const wxString& bindingClassName )
{
 GET_LUASTATEVARS_MSG(L, false)
 wxASSERT(!stateVars->m_typesRegistered);
 wxASSERT(!stateVars->GetLuaBinding( bindingClassName );
 // ignore binding request when we already have wx registered
 if (stateVars->GetLuaBinding( bindingClassName ))
 return false;
 m_luaStateVariables->m_bindings.Append( wxCreateDynamicObject( 
bindingClassName ) );
 return true;
}
bool wxLuaInterpreter::RegisterBindings()
{
 m_luaStateVariables->RegisterBindings(m_lua_State, true);
}
This way one can add bindings as needed by classname, and Register them 
all at once when done.
Or is this what you had in mind all the time :-)
Klaas
k. holwerda wrote:
> Hi John,
>
> I struggle on, and i think it would be good to make a change.
> In short i think RegisterBindings() is called to early.
>
> I try to explain.
>
> The next piece of code should work ( it does here ;-) ).
> It is in bool wxLuaStandaloneApp::OnInit().
> The idea is to add all the binding when the wxLuaInterpreter was created.
>
> // Initialize lua
> m_luaInterpreter = new wxLuaInterpreter(this, -1);
> m_luaState = m_luaInterpreter->GetLuaState();
> if ( !bind_wx( m_luaState ) )
> return false;
>
> Klaas
>
> Unclassified
>
>
>

John Labenski <jla...@gm...> wrote:
(01/08/2005 04:55)
>I guess I don't have the same problem, I took your sample code and
>added buttons to them as a further test. (note that the wxID_OK/CANCEL
>will automatically close the dialog and returns that window id from
>ShowModal) I find that when I press the toolbar tool the dialog pops
>up, the dialog has the focus (the titlebar is colored) and if I press
>enter (don't even click on the dialog) the dialog closes since it has
>focus and the enter key goes to the button which has the focus.
>
>BANK=wx.wxDialog(PANEL,-1,"",wx.wxPoint(-1,-1),wx.wxSize(426,266))
>CNFG=wx.wxDialog(PANEL,-1,"",wx.wxPoint(-1,-1),wx.wxSize(426,266))
>do
> wx.wxButton(BANK, wx.wxID_OK, "Ok")
> wx.wxButton(CNFG, wx.wxID_OK, "Ok")
>end
>
>I'm using XP, what are you using?
>
That was interesting. The second dialog still showed the failure to respond to the first click, but the use of Enter, as that button has focus, works as it should, as you said. :)
I don't know the reason for this, but it definitely seems related to the OS. I'm using 98-Lite, by Shane Brooks. Meaning it's a W95 shell on a W98 SE core. Some things hate that and won't run at all, especially if they have special dependencies on the W98 shell files. If I can find an old Ghost image of either W95 or W98 SE in pure state, I'll test again. For now, I'm happy with doing
BANK:Show(1) FRAME:Enable(nil)
on calling the dialog, and
FRAME:Enable(1) BANK:Show(nil) FRAME:SetFocus(1)
on closing it. (I just hide it, in fact.) So long as I get the frame re-enabled before hiding the dialog, there is a clean transfer of focus back to the frame.
Btw, why did you use do and end? I realised when I saw it, that it could be a neat way to declare local variables in the do ... end without leaving them around as they would be if declared outside that, but in this case I can't see what the do ... end would add here.
>I think the perfect solution is to create a Wiki on the web page. I
>think SF provides the means and that way it'll be very easy for you
>and others to contibute and update/polish/add code or whatever since
>it'll be user editable and you'll have full control. For example see
>here,
>http://wiki.wxwidgets.org/wiki.pl?Table_Of_Contents
>
>I don't know how to set it up, but I know someone who does so I'll
>have ask about it.
>
Agreed. :) I like that far better. I do make mistakes, like the order of that FRAME:Enable(1) BANK:Show(nil) FRAME:SetFocus(1) sequence, and going back to fis stuff like that will be useful. /me hopes that someone might also know how to make a MIDI I/O library for wxLua. :) I'll finish the Thinger and release it during the next few days, as I'll be listening to a test match for much of that time and will have time to do it. Is there a way to make uploaded binaries available to people who didn't get the original email? Meaning: does the mailing list archive attachments? That Thinger has a few bitmaps, one of which is too big to make into XML text conveniently.

Hi,
John Labenski wrote:
>The only problem is that in internal.cpp you have to know the name of
>the binding class in order to call it. This means that you can't
>compile without it.
>
See my lattest thread. I think that this binding is added to early, 
maybe someone does not even want that wx binding.
wxLuaStateVariables::wxLuaStateVariables()
{
.....................
 m_bindings.Append(new wx_Binding());
}
> It also makes the #include "wxbind.h" necessary. 
>
Not if removed there, and added at e.g. wxLuaInterpreter level or even 
wx(LuaStandalone)App level.
Using the function bind_wx( m_luaState ).
This is all fine if the statevars->RegisterBindings(m_luaState, true) 
is done a bit later.
>I
>was just thinking out loud about how to dynamicly create a list of
>bindings and use the string namespace to differentiate between them.
> 
>
Right, which i think is already possible??
>Now that I check it out a little more, it'd be much easier to to just have a 
>static wxArrayString wxLuaBinding::ms_arrayBindingClassNames;
>every subclassed binding just adds it's own classname once to the
>binding list. Now that you know the class names of the bindings, each
>wxLuaStateVariables can create and add them to the m_bindings list by
>running
>
>wxObject * wxCreateDynamicObject(const wxString& className)
> 
>
Sure this is indeed better then a string, since at least all bindings 
classes will be unique.
I use this trick all over wxArt2D, works nice. e.g. i load xml from a 
file and create the objects in it like this.
> I'm just thinking about how people can most simply
>add their own wrappers without having to modify anything in wxlua.
> 
>
This is already the case now i think, what do you think they need to 
add/change?
>As you can see, I really haven't played with the current system that
>much since I don't know how they'll change. I won't commit anything
>without consulting others, I just wanted to throw the idea out there.
> 
>
I think at least that it is better to use the classname of the binding 
class to test if it is there or not.
So as you suggest above.
Regards,
Klaas
Unclassified

Hi John,
I struggle on, and i think it would be good to make a change.
In short i think RegisterBindings() is called to early.
I try to explain.
The next piece of code should work ( it does here ;-) ).
It is in bool wxLuaStandaloneApp::OnInit().
The idea is to add all the binding when the wxLuaInterpreter was created.
 // Initialize lua
 m_luaInterpreter = new wxLuaInterpreter(this, -1);
 m_luaState = m_luaInterpreter->GetLuaState();
 if ( !bind_wx( m_luaState ) )
 return false;
 wxLuaStateVariables* statevars = m_luaInterpreter->GetStateVariables();
 statevars->RegisterBindings(m_luaState, true);
BUT the problem is that in:
bool wxLuaInterpreter::Create(lua_State *inL, wxEvtHandler *handler, int id)
{
 .........................
 // now register bindings
 //m_luaStateVariables->RegisterBindings(m_lua_State, true);
 return TRUE;
}
If not outcommented m_luaStateVariables->RegisterBindings already sets 
a flag see:
void LUACALL wxLuaStateVariables::RegisterBindings(lua_State *L, bool 
registerTypes)
{
.......................
 m_typesRegistered = true;
......................
}
And that means one can not register more bindings which where added by 
e.g. bind_wx( m_luaState ) above.
So therefore i think in wxLuaInterpreter::Create() we better not call 
RegisterBindings() and instead have the user call it after he did add 
all bindings to the wxLuaStateVariables.
If that is done, we can remove in internal.cpp ALL the outcommented 
lines down here.
//#include "../../../bindings/wxwidgets/luasetup.h.in" // get the base 
library setup parameters
//#include "wxbind/include/wxbind.h"
wxLuaStateVariables::wxLuaStateVariables()
{
...................
 //m_bindings.Append(new wx_Binding());
 m_bindings.DeleteContents(true);
}
This change would make the module wxlua independent of the wxbind stuff.
Which is i think exactly what we need. Dynamically adding bindings!
What do you think.
Klaas
Unclassified

So John,
Having the Cmake files ready,
I finally got things to work ( outcommenting the errors i got on FL etc. ).
And know i am trying to run apps/wxlua.
I get an error in a popup:
(none):0: attempt to index global `wx`( a nil value)
and next:
wxLua: Error while running chunk.
This is the stack.
wxLuaInterpreter::RunBuffer(const unsigned char * 0x00906028, unsigned 
int 51558, const wxString & {...}) line 706
wxLuaStandaloneApp::RunEditor() line 393
wxLuaStandaloneApp::OnInit() line 155 + 11 bytes
wxAppConsole::CallOnInit() line 87 + 28 bytes
wxEntryReal(int & 1, char * * 0x0034e3b0) line 401 + 25 bytes
wxEntry(int & 1, char * * 0x0034e3b0) line 216 + 13 bytes
wxEntry(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, HINSTANCE__ 
* 0x00000000, int 1) line 299 + 13 bytes
WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 
0x00041f17, int 1) line 96 + 24 bytes
WinMainCRTStartup() line 330 + 54 bytes
KERNEL32! 77e8141a()
Do you have the same problem?
How do you use what is in CVS currenly, using bakefile generated 
makefiles or something else, or nothing at all ;-) ?
Thanks,
Klaas
Unclassified

Hi John,
Does WXLUA_CODE always needs to be set 1?
In lstate.c i found:
#ifndef WXLUA_CODE
..................
#else
/* labenski - track child threads see wxLuaInterpreter.cpp */
#include <luathread.h>
.......................
And
${wxLUA}/apps/wxlua at least needs it.
Klaas
unclassified

Hi,
In the setup for wxbind i have:
#define wxLUA_USE_FL 0
This gives me the next errors:
c:\data\art2d\wxLua\modules\wxbind\src\wx_define.cpp(1511) : error 
C2065: 'CB_LEFT_BAR_HANDLE_HITTED' : undeclared identifier
c:\data\art2d\wxLua\modules\wxbind\src\wx_define.cpp(1567) : error 
C2065: 'CB_RIGHT_BAR_HANDLE_HITTED' : undeclared identifier
c:\data\art2d\wxLua\modules\wxbind\src\wx_define.cpp(1596) : error 
C2065: 'CB_BAR_CONTENT_HITTED' : undeclared identifier
c:\data\art2d\wxLua\modules\wxbind\src\wx_define.cpp(1643) : error 
C2065: 'wxEOL_MAC' : undeclared identifier
c:\data\art2d\wxLua\modules\wxbind\src\wx_define.cpp(1681) : error 
C2065: 'wxEOL_NATIVE' : undeclared identifier
c:\data\art2d\wxLua\modules\wxbind\src\wx_define.cpp(1716) : error 
C2065: 'CB_NO_ITEMS_HITTED' : undeclared identifier
c:\data\art2d\wxLua\modules\wxbind\src\wx_define.cpp(1782) : error 
C2065: 'CB_LOWER_ROW_HANDLE_HITTED' : undeclared identifier
c:\data\art2d\wxLua\modules\wxbind\src\wx_define.cpp(1807) : error 
C2065: 'CB_UPPER_ROW_HANDLE_HITTED' : undeclared identifier
c:\data\art2d\wxLua\modules\wxbind\src\wx_define.cpp(1899) : error 
C2065: 'wxEOL_UNIX' : undeclared identifier
c:\data\art2d\wxLua\modules\wxbind\src\wx_define.cpp(2101) : error 
C2065: 'wxEOL_DOS' : undeclared identifier
When i go to the first, it is clearly not #if wxLUA_USE_FL, but in fl.i 
i see
%if wxLUA_USE_FL around the whole thing. So it looks oke, but it is not :-(
 { "wxCAL_BORDER_ROUND", false, wxCAL_BORDER_ROUND, 0 },
 { "CB_LEFT_BAR_HANDLE_HITTED", false, CB_LEFT_BAR_HANDLE_HITTED, 
0 },
 { "wxVARIABLE", false, wxVARIABLE, 0 },
Is there a solution?
Klaas
Unclassified

On 8/1/05, klaas.holwerda <kho...@xs...> wrote:
> I do understand more or less what you write. But i do not understand why
> the wxLuaBinding i see now, is not good enough, which i think is the
> case from what you have in mind. Don't get me wrong, i do not critisize
> :-), just don't understand.
> e.g. i see in wxbind.h
> class wx_binding
>=20
> Where did this wxLuaBinding class come from, it is not in my wxArt2D
> version, so i assume Ray or you made it?
Ray did, it's in modules/wxlua/include/internal.h and src/internal.cpp.
The only problem is that in internal.cpp you have to know the name of
the binding class in order to call it. This means that you can't
compile without it. It also makes the #include "wxbind.h" necessary. I
was just thinking out loud about how to dynamicly create a list of
bindings and use the string namespace to differentiate between them.
Now that I check it out a little more, it'd be much easier to to just have =
a=20
static wxArrayString wxLuaBinding::ms_arrayBindingClassNames;
every subclassed binding just adds it's own classname once to the
binding list. Now that you know the class names of the bindings, each
wxLuaStateVariables can create and add them to the m_bindings list by
running
wxObject * wxCreateDynamicObject(const wxString& className)
All you need to have is that each subclassed wxLuaBinding class have
DECLARE/IMPLEMENT_DYNAMIC_CLASS. Again, maybe this isn't perfect or
even a good idea, I'm just thinking about how people can most simply
add their own wrappers without having to modify anything in wxlua.
As you can see, I really haven't played with the current system that
much since I don't know how they'll change. I won't commit anything
without consulting others, I just wanted to throw the idea out there.
Regards,
 John Labenski

John Labenski wrote:
>Does this make more sense, even though we probably shouldn't do it yet
>(until we know if there are better wrappers or now)... this is how I
>envision it will work.
> 
>
I do understand more or less what you write. But i do not understand why 
the wxLuaBinding i see now, is not good enough, which i think is the 
case from what you have in mind. Don't get me wrong, i do not critisize 
:-), just don't understand.
e.g. i see in wxbind.h
class wx_binding
and next
bool bind_wx( .. )
Where did this wxLuaBinding class come from, it is not in my wxArt2D 
version, so i assume Ray or you made it?
What is the current system capable of? 
Or where is it not good enough, i don't have a clue :-(?
How does your idea differ from what is there now?
Sorry John this is all new to me, so i have to study a bit more, to be 
able to answer if i understand or not. But if you can tell me a bit more 
on what is there, i think i will get it quicker ;-)
Thanks,
Klaas

I'm sorry, but I completely forgot about how to build the wrappers. I
assume you must have figured it out (that when I spoke of wxluawrap I
really mean genwxbind), but to clarify for others.
Build lua.exe in release mode=20
wxLua\modules\lua\src\lua\lua.dsp (for VC or use makefile in linux)
Goto wxLua/bindings
run genwxbind.bat and it dumps the output into wxLua/modules/wxbind
(in linux just run the equivalent of genwxbind.bat on the command line)
I apologize if I caused any confusion, wxluawrap.lua is the original
binding program and it's output is probably not compatible anymore. It
should be removed and I would have done so if the current system
worked perfectly, but until then... lets keep it as a backup.
Regards,
 John Labenski

On 8/1/05, klaas.holwerda <kho...@xs...> wrote:
> Hi John,
>=20
> If you go to the generated wave.cpp, you will find several wxchkver25
> which or not commented and or not translated.
> So i think there is a bug somehow.
>=20
> e.g. I see:
> #if (defined(__WXMSW__) && !wxchkver25) && (wxLUA_USE_wxWave)
Oops, in bindings/wxwidgets/wave.i line 10 should be
%if %msw&!%wxchkver25
and not
%if %msw&!wxchkver25
I fixed it in CVS.
Regards,
 John Labenski

Hi John,
If you go to the generated wave.cpp, you will find several wxchkver25 
which or not commented and or not translated.
So i think there is a bug somehow.
e.g. I see:
#if (defined(__WXMSW__) && !wxchkver25) && (wxLUA_USE_wxWave)
OR
#if (!wxCHECK_VERSION(2,5,0)) && ((defined(__WXMSW__) && !wxchkver25) && 
(wxLUA_USE_wxWave))
// !%wxchkver25 bool Play(bool async = TRUE, bool looped = FALSE) const
John Labenski wrote:
>I don't know if it's worth it to fix them all if we're
>getting new wrappers anyway since it'll be hard to compare the two and
>you'll have to check everything all over again.
> 
>
I see, just did a few i saw now, not a big deal, i just leaf them in.
>I think it should be this, only include this if the wxWidgets version
>is < 2.5 or if WXWIN_COMPATIBILITY_2_4 is on.
>!%wxchkver25|%wxcompat24 void SetPrinterOptions(const wxString& options)
> 
>
It looks like %wxcompat24 does the job, but i will keep it in mind.
> 
>
>>What about that property?
>> 
>>
>
>Put the same checks for the property since it's basicly the same thing.
> 
>
Oke i did that.
>Some of the checks are really ugly, we should write a parser for 
>%wxchkver(2,5,0) so that it can be translated to
>wxCHECK_VERSION(2,5,0) directly without having to mess with all the
>%wxchverXX translations in wxluawrap.lua. Again, this is a trivial
>thing, but time consuming and a big change like this would make it
>very difficult to merge back in with Rays new wrappers so I was going
>to do it afterwards if people liked it.
> 
>
Oke better wait some more then :-(
Thanks,
Klaas

On 8/1/05, k. holwerda <kla...@nl...> wrote:
> I want to get rid of the errors, caused by WXWIN_COMPATIBILITY_2_4 =3D 0.
>=20
> So i first tried to find wxchkver25, it is not defined in any header.
> Should the user set/define it himself? It is used in wxbind.h and all
> the generated *.cpp files.
This is used only by the wrapper generator, they're comments in the
generated cpp files to tell you what the source was from.
> In genwxbind.lua i find:
> conditions["%wxchkver25"] =3D "wxCHECK_VERSION(2,5,0)"
>=20
> But it seems this does not become a setting in a header file?
The %wxchkver25 is replaced by wxCHECK_VERSION(2,5,0), see for example
in the generated wrappers in this file
"modules/wxbind/src/windows.cpp"
#if wxCHECK_VERSION(2,5,0)
// %wxchkver25 void ClearBackground()
static int LUACALL wxWindow_ClearBackground(lua_State *L)
....
#endif
> Same for the next conditions["%wxcompat24"] =3D "WXWIN_COMPATIBILITY_2_4"
> For the moment i just set it to 1 or 0 myself, but what am i missing?
This is done for you by the c++ compiler, again see the generated
wrappers, they're may be bugs however, I've never tested turning
COMPAT_2_4 off. I don't know if it's worth it to fix them all if we're
getting new wrappers anyway since it'll be hard to compare the two and
you'll have to check everything all over again.
=20
> Is the next the right way of disabling a member when
> WXWIN_COMPATIBILITY_2_4 is set 0?
>=20
> %wxcompat24 void SetPrinterOptions(const wxString& options)
> %property=3DPrinterOptions, read, write
I think it should be this, only include this if the wxWidgets version
is < 2.5 or if WXWIN_COMPATIBILITY_2_4 is on.
!%wxchkver25|%wxcompat24 void SetPrinterOptions(const wxString& options)
> What about that property?
Put the same checks for the property since it's basicly the same thing.
Some of the checks are really ugly, we should write a parser for=20
%wxchkver(2,5,0) so that it can be translated to
wxCHECK_VERSION(2,5,0) directly without having to mess with all the
%wxchverXX translations in wxluawrap.lua. Again, this is a trivial
thing, but time consuming and a big change like this would make it
very difficult to merge back in with Rays new wrappers so I was going
to do it afterwards if people liked it.
Regards,
 John Labenski

On 8/1/05, k. holwerda <kla...@nl...> wrote:
> But that is confusing, i mean i thought that ..../modules/wxlua would be
> a library by itself.
> But if it needs wxbind.h which is not yet generated??
Yes the code can be pregenerated, but lets not put it into CVS until
we're happy with it since it's easy to generate on the fly. We can
remove the dependence on wxbind.h eventually, see below.
> Right now that is true, but if we change wxLuaWrap.lua here and there,
> we can have several wrapper trees ( one for the wxLua and one for a
> thirdparty lib (e.g. wxArt2DLua) and one for the user app ).
> More imported several generated Cpp files, one for each tree. The idea
> was to generate a sort of namespace for the each tree.
That is the idea, we can make wxluawrap.lua generate bindings for any
given set of .i files.
=20
> So have a table of the next and not just one:
> WXLUACLASS *GetClassList(size_t &count)
> {
> static WXLUACLASS ClassList[] =3D
> {
I think that in order to make all the bindings independent we should
use a class with static members. Change wxLuaBinding to something like
this
class wxLuaBinding
{
 wxLuaBinding() {}
 static size_t GetBindingCount() { return ms_nameSpaceArray.GetCount();=
 }
 static wxString GetNameSpace(size_t n) { return ms_nameSpaceArray[n]; =
}
 static WXLUACLASS* GetClasses(size_t n) { return
(WXLUACLASS*)ms_classArray[n]; }
 static WXLUAEVENT* GetEvents(size_t n) { return
(WXLUAEVENT*)ms_eventArray[n];
 ...
 =20
 // all arrays are the SAME size even if they have NULL pointers
 static wxArrayString ms_nameSpaceArray;
 static wxArrayPtrVoid ms_classArray;
 static wxArrayInt ms_classCountArray;
 static wxArrayPtrVoid ms_eventArray;
 static wxArrayInt ms_eventCountArray;
 static wxArrayPtrVoid ms_defineArray;
 static wxArrayInt ms_defineCountArray;
 ...
}
in the cpp wrapper files for wxWidgets (or your binding) have this
class wxLuaBinding_wx : public wxLuaWrappers
{
 wxLuaBinding_wx(void* classes, int class_count, void* events,
int event_count, void* defines, int define_count)
 {
 ms_nameSpaceArray.Add(wxT("wx"));
 ms_classArray.Add(classes);
 ms_classCountArray.Add(class_count);
 ms_eventArray.Add(events);
 ms_eventCountArray.Add(event_count);
 ms_defineArray.Add(defines);
 ms_defineCountArray.Add(define_count);
 }
}
// now add them by creating a dummy instance of the class who's only
purpose is to add the structs to the arrays. this way no special
functions have to be called.
wxLuaBinding_wx dummy_instance(just use the structs themselves here
and the WXSIZEOF them);
Now from *anywhere* in your program (probably only used internally
though) you just call this (with appropriate checks first).
wxLuaBinding::GetClasses(index of wrapper)[index into classes].whatever;
=20
Now the wrappers are completely independent and are added at your
program's startup depending on what you linked to. If you don't link
to any, it's just as well since the arrays will be empty and you get
no wrappers. There's no special functions to know the names of ahead
of time and everything is created on the fly depending on what you
link to. You just have to make sure that you get the link order right,
link to wxlua before any bindings.
This is trivial to implement, but is a fairly big change to
wxluawrap.lua and internals.h/cpp, so I was waiting for Ray so we
wouldn't have two different wxluawrap.lua files that had to be merged
again...
> I once looked at that, but stopped when the ctags came about.
> I wonder if the *.i files will stay even if using ctags approach or
> whatever way of generating the *.i files?
> If the *.i files will go, and there will be a speration in bindings
> libraries anyway, i will not spend time on the above.
No the .i files will probably stay since the generator will be used
for your own wrappers and it should work to recreate it's own wrappers
as a test.
> To this is only possible, if that is done at runtime.
> Else you will have to compile a library of the standalone, and another
> for the user app containing less bindings.
> Do i miss something?
>
> Still it is of course a could thing to be able to use several luasetup.h
> files.
This is exactly what I was thinking, you copy the makefile (buildfile)
from the wxbind dir into your program's dir, change paths accordingly
and then run it. Now you've generated your own library of wxLua's
wxwidgets bindings specificly for your program's needs. I can think of
no other way.
=20
> So when i see in internal.cpp a line like this, i am lost ;-)
>=20
> #include "../../../bindings/wxwidgets/luasetup.h.in" // get the base
> library
>=20
> It says include a file, which normally is meant to be configured??
> It seems wxluawrap.lua is doing that step, but still internal.cpp
> includes all.
> Is that because it will be always a subset?
That was a hack I believe, using the above static functions in
wxLuaBinding we should be able to remove that include as well as the
include for wxbind.h since we will get all the info we need from the
static functions in wxLuaBinding. In fact there will be NO public
header for the wrapper libs as any information about them is set
internaly through wxLuaBinding.
Does this make more sense, even though we probably shouldn't do it yet
(until we know if there are better wrappers or now)... this is how I
envision it will work.
 John Labenski

Hi,
I want to get rid of the errors, caused by WXWIN_COMPATIBILITY_2_4 = 0.
So i first tried to find wxchkver25, it is not defined in any header.
Should the user set/define it himself? It is used in wxbind.h and all 
the generated *.cpp files.
In genwxbind.lua i find:
 conditions["%wxchkver25"] = "wxCHECK_VERSION(2,5,0)"
But it seems this does not become a setting in a header file?
Same for the next conditions["%wxcompat24"] = "WXWIN_COMPATIBILITY_2_4"
For the moment i just set it to 1 or 0 myself, but what am i missing?
Anyway, with this setting to wxchkver25 1, i get less errors, and those 
errors are due to the *.i files not taking care of it.
Is the next the right way of disabling a member when 
WXWIN_COMPATIBILITY_2_4 is set 0?
 %wxcompat24 void SetPrinterOptions(const wxString& options)
 %property=PrinterOptions, read, write
What about that property?
Klaas
Unclassified

Hi John,
Here at work somehow genwxbind.bat works directly.
And it generates wxbind.h and wx_class.cpp.
But seeing function like bool bind_wx(lua_State* L), i still think it 
would be bettter to split the wx bindings, and the code to
do the binding itself. It seems easy enough to do that.
Outcommenting those two lines makes it compile:
//#include "wxbind/include/wxbind.h"
//m_bindings.Append(new wx_Binding());
So adding those bindings in a seperate library and/or user code will do 
the job, i think?
Klaas
k. holwerda wrote:
> Hi John,
>
> I start to realize something is already done ;-)
> But i do not understand it yet :-(
>
> The following is needed:
> #include "wxbind/include/wxbind.h"
>
> to fill
>
> // always add wxWidgets binding
> m_bindings.Append(new wx_Binding());
>
> Do you know how this works, or where it comes from.
> Especially where is the class wx_Binding generated, i can't find it.
> I think it is generated from some script, but where.
>
> As i see it, the default bindings can not be here in order to make the 
> wrapper mechanism a library by itself.
> So i would suggest to have a:
>
> -wxlua_bind.lib <= contains all cpp code to read the wrapper cpp 
> files( wxwidgets + wxart2d + useapp) into lists/arrays.
> -wxlua_widgets_bindings.lib <= a library to be linked to an 
> application which only needs the default wxWidgets binding to lua.
>
> The first (wxlua_bind.lib) will be without any bindings by default,
> and the last (wxlua_widgets_bindings.lib) will have somehow:
> m_bindings.Append(new wx_Binding());
>
> e.g. wxLua standalone or any other application would use 
> wxlua_bind.lib to build itself without the need to depend on some 
> default binding. The application decides which those are, in its 
> app_bind.h/cpp
>
> ( i am not sure, but it could well be that wxLua standalone is in fact 
> doing no more then using wxlua_widgets_bindings.lib, or does it 
> disable some bindings which are in the default? ).
>
> Regards,
>
> Klaas
>
> Unclassified
>
>
>
>
>
>
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Wxlua-users mailing list
> Wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users