wxlua-users

[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] 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] 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, 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

[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