wxlua-users — wxLua list for users and developers

Re: [Wxlua-users] Extended Toolbar, a new example of wxLua code.

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

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

Re: [Wxlua-users] Running wxlua

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

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

Re: [Wxlua-users] RegisterBindings later

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

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

Re: [Wxlua-users] WXLUA_CODE

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

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

Re: [Wxlua-users] Running wxlua

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

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
>

Re: [Wxlua-users] RegisterBindings later

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

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
>
>
>

Re: [Wxlua-users] Extended Toolbar, a new example of wxLua code.

[The D. <the...@bl...>]

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.

Re: [Wxlua-users] wxbind/include/wxbind.h

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

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

[Wxlua-users] RegisterBindings later

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

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

[Wxlua-users] Running wxlua

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

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

[Wxlua-users] WXLUA_CODE

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

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

[Wxlua-users] wxLUA_USE_FL 0 errors

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

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

Re: [Wxlua-users] wxbind/include/wxbind.h

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

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

Re: [Wxlua-users] wxbind/include/wxbind.h

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

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

Re: [Wxlua-users] wxchkver25

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

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

Re: [Wxlua-users] wxchkver25

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

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

Re: [Wxlua-users] wxchkver25

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

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

Re: [Wxlua-users] wxchkver25

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

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

Re: [Wxlua-users] wxbind/include/wxbind.h

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

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

[Wxlua-users] wxchkver25

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

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

Re: [Wxlua-users] internal.cpp

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

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

[Wxlua-users] internal.cpp

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

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

Re: [Wxlua-users] wxbind/include/wxbind.h

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

John Labenski wrote:

>On 7/31/05, klaas.holwerda <kho...@xs...> wrote:
>  
>
>>included from  in internal.cpp
>>
>>Where is  it?
>>    
>>
>
>see my other message, it's generated on the fly by running wxluawrap.lua.
>  
>
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??

I think we should have to a default binding library.
And if the user wants has own specific set, he can do so.

>I don't know about the bakefiles, but just to clarify the reasoning I
>think the only workable solution for having multiple versions of the
>wrapper libraries is to make people compile them in their own project.
>  
>
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.

So have a table of the next and not just one:

WXLUACLASS *GetClassList(size_t &count)
{
    static WXLUACLASS ClassList[] =
    {

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.

>For example, the standalone wxlua ide should wrap everything, all the
>wxLUA_USE_XXX are 1.
>
Right, this i see a s a default binding library.

> However for using wxLua in your own project you
>might want to turn some of them off.
>
I can understand, it would be ideal if this can be done at runtime?
If not there is only one solution, one has to switch them off, and 
recompile the library.
If this is inclusive the user wrappers/bindings, is for me just a matter 
of organizing things.

> I will want to be able to compile
>both of them without too much problem for debugging so I don't want to
>have to compile the wrapper lib for the standalone program, have to
>edit something and recompile it for an embedded program.
>
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.

So when i see in internal.cpp a line like this, i am lost ;-)

#include "../../../bindings/wxwidgets/luasetup.h.in" // get the base 
library

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?

> You shouldn't
>have to edit anything.
>  
>
Do you mean that for the moment having several luasetup.in  files, one 
leading to one libary another to another library would be oke?
This is the situation i had sofar in wxArt2D, several luasetup.h.in 
files, which are configured to the build tree as several luasetup.h
files. But now i realize that the luasetup.h is never used, it is 
generated by wxluawrap.lua from luasetup.h.in too.
Where is the generated luasetup.h meant for?

>I hope this makes sense,
>
>  
>
Not all ;-)
But with your help i might be able to understand what is the current 
situation, and next think about what we really want and how.
To me it is clear that when one wants to disable functionality of a 
default distributed wxLua library, this can only de done at run time. 
Which to me would not be a problem, since i never bother about size.
Next to this we can of course make a system that generates based on  an 
application luasetup.h, a new set of cpp files ( seperated by wxlua, 
thridparty, userapp  based on some sort of namespace in that setup.h file.)
This would than lead to a new wxLua_userapp library, meant only for that 
application, and does contain only code that was meant to be used by the 
application.

One thing for sure, we need to aim for a speration in  *.cpp files 
containing wrapping code. Currently adding one extra lua command to my 
app, takes long compilation time, and therefore is bad in a debug cylce.

What do you think, or do you have something else in mind.

Thanks,

Klaas

Unclassified

Re: [Wxlua-users] Extended Toolbar, a new example of wxLua code.

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

On 7/29/05, The Doctor <the...@bl...> wrote:
> That SetFocus() was the wrong one though. You added it to the dialog that=
 works, and I already said that SetFocus() wasn;t solving things, although =
it appears as if it ought to... That dialog works anyway, somehow, because =
of the preceding FilePane dialog I think, but I don't know why it makes a d=
ifference unless it's something to do with returning focus to the rest of t=
he program. If you add that SetFocus() after the other ShowModal instead, i=
t won't stop that other dialog from failing to respond to any first click. =
On the other hand, if this doesn't happen for you, it might be something OS=
 specific. It's certainly repeatable here with brutally simple regularity. =
I can't do anything to shift it.. :)

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=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

I'm using XP, what are you using?

> I was hoping you might say something more about that caveat emptor direct=
ory idea. I think it's a good way to make a script available. This is all s=
o new, that in the absence of any documentation other than the source files=
, surely any kind of working script is worth preserving and distributing in=
tact, so that others can learn from it. If it works, coding style is surely=
 secondary, and no-one's going to confuse it with the formally released sam=
ples. Also, if this doesn't happen, it might be rather difficult to persuad=
e anyone else to contribute...

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.

Regards,
    John Labenski

Re: [Wxlua-users] wxbind/include/wxbind.h

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

On 7/31/05, klaas.holwerda <kho...@xs...> wrote:
> included from  in internal.cpp
>=20
> Where is  it?

see my other message, it's generated on the fly by running wxluawrap.lua.
=20
> BTW i read the thread on binding with you and Francesco, i think i get it=
.
> There is no bindings library yet.
> It is all application specific.  ( like in apps/wxlua ).

Right.

> Still a bit confused what is in the bakefiles on this wxbind sources.

I don't know about the bakefiles, but just to clarify the reasoning I
think the only workable solution for having multiple versions of the
wrapper libraries is to make people compile them in their own project.
For example, the standalone wxlua ide should wrap everything, all the
wxLUA_USE_XXX are 1. However for using wxLua in your own project you
might want to turn some of them off. I will want to be able to compile
both of them without too much problem for debugging so I don't want to
have to compile the wrapper lib for the standalone program, have to
edit something and recompile it for an embedded program. You shouldn't
have to edit anything.

I hope this makes sense,
    John Labenski