Menu
▾
▴
wxlua-users
|
From: Francesco M. <f18...@ya...> - 2006-02-01 21:00:58
|
Hi, John Labenski ha scritto: >>Francesco Montorsi ha scritto: >> >>>>1) STC (more generically CONTRIB) problem > > > I tried to disconnect wxSTC from the wxWidgets wrappers last night. I > think it will take some doing however. Since they'll share the same > lua namespace, they don't have to, but I would like the generic > flexibility of putting multiple wrappers into the same namespace, any > additional wrappers overwrite earlier ones. I have to do some reading > up on how to add more to lua in C. I hope it won't be too hard. ok, let me know if I can help in some way... >>>>2) wxLUA_USE_wxCriticalSectionLocker is not defined - maybe it should >>>>be added to wxluasetup.h >>> >>>looking to wxluasetup.h I've found that there is a heading which says >>>that it's generated by "utils/get_luasetup"; however I couldn't find >>>that util. >>>Is that true or that's an old comment? > > > That is a simple little utility, basicly just grep wxLUA_USE* for the > .i files. I will try to find it if I can. it would be nice to have it in CVS... >>>>3) wxLua application needs wxStyledTextCtrl wrapper and an error >>>>should be given when it's not available instead of just failing it at >>>>runtime (IMO) > > > See above about separating it. > > >>>7) can I start to connect the options WXLUASETUP_DIR and >>>WXLUABINDLIB_DIR to the build system ? >> >>Before starting this work, I need to know exactly how they must work ;) >> >>If I'm right, they should be used not to *modify* the build of the >>wxbind module of wxLua (which should always use the >>modules/wxbind/src/wxluasetup.h header and should always go in the lib/ >>folder) but rather to *create* a new library, built from same sources of >>wxbind module, which would be created in the WXLUABINDLIB_DIR folder and >>which would use the wxluasetup.h found in the WXLUASETUP_DIR path. >>Is it right ? > > > I would be nice to be able to build the wxbind lib for different > wxluasetup.h files, one lib for the wxLua app and others for your > programs that use wxLua as a library. Sorry, I didn't follow this too > closely. Klaas, IIRC you would use these options... my description above describe the wanted behaviour correctly, or there is something else which needs to be done ? Francesco |
|
From: John L. <jla...@gm...> - 2006-02-02 04:22:26
|
On 2/1/06, Francesco Montorsi <f18...@ya...> wrote:
> >>>>1) STC (more generically CONTRIB) problem
> >
> > I tried to disconnect wxSTC from the wxWidgets wrappers last night. I
> > think it will take some doing however. Since they'll share the same
> > lua namespace, they don't have to, but I would like the generic
> > flexibility of putting multiple wrappers into the same namespace, any
> > additional wrappers overwrite earlier ones. I have to do some reading
> > up on how to add more to lua in C. I hope it won't be too hard.
> ok, let me know if I can help in some way...
I believe I got it to work. It currently generates a library that you
link to in addition to the wxbind library. You can now add any
arbitrary number of libraries to any lua namespace.
So, I guess we need to add some more dirs, let me know what you think
about these.
wxLua/bindings/wxstc/stc.i
or wxLua/bindings/wxwidgets/contrib/stc/stc.i (maybe better)
wxLua/modules/wxbindstc/ - same as wxbind
* I think this has to be in it's own dir at the same level as wxbind
> >>>>2) wxLUA_USE_wxCriticalSectionLocker is not defined - maybe it should
> >>>>be added to wxluasetup.h
> >>>
> >>>looking to wxluasetup.h I've found that there is a heading which says
> >>>that it's generated by "utils/get_luasetup"; however I couldn't find
> >>>that util.
> >>>Is that true or that's an old comment?
> > That is a simple little utility, basicly just grep wxLUA_USE* for the
> > .i files. I will try to find it if I can.
> it would be nice to have it in CVS...
I found it, it's an awk script that was written before we used the
wxWidgets %if wxUSE_XXX in the bindings so it's pretty dumb and not
very useful anymore.
#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
# read in all the .i files, look for "%if" print them out
grep "%if" *.i | awk 'BEGIN {print("// Automatically generated by
utils/get_luasetup edit as necessary."); \
print(""); \
print("#ifndef __WXLUA_SETUP__");
print("#define __WXLUA_SETUP__");
print("") } \
{ len =3D length($2); printf("#define %s",$2); for
(i=3D0;i<40-len;i++) { printf(" ") }; print("1") } \
END { print(""); print("#endif // __WXLUA_SETUP__") }'
#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >>>7) can I start to connect the options WXLUASETUP_DIR and
> >>>WXLUABINDLIB_DIR to the build system ?
> >>
> >>Before starting this work, I need to know exactly how they must work ;)
> >>
> >>If I'm right, they should be used not to *modify* the build of the
> >>wxbind module of wxLua (which should always use the
> >>modules/wxbind/src/wxluasetup.h header and should always go in the lib/
> >>folder) but rather to *create* a new library, built from same sources o=
f
> >>wxbind module, which would be created in the WXLUABINDLIB_DIR folder an=
d
> >>which would use the wxluasetup.h found in the WXLUASETUP_DIR path.
> >>Is it right ?
> >
> >
> > I would be nice to be able to build the wxbind lib for different
> > wxluasetup.h files, one lib for the wxLua app and others for your
> > programs that use wxLua as a library. Sorry, I didn't follow this too
> > closely.
> Klaas, IIRC you would use these options... my description above describe
> the wanted behaviour correctly, or there is something else which needs
> to be done ?
These are things that you can use with configure? How would you make
it so that you can build wxbind for the apps/wxlua and a different one
for external programs. Do you have to run configure between building
each of them?
Regards,
John Labenski
|
|
From: Francesco M. <f18...@ya...> - 2006-02-02 08:36:16
|
Hi,
John Labenski ha scritto:
> On 2/1/06, Francesco Montorsi <f18...@ya...> wrote:
>>>>>> 1) STC (more generically CONTRIB) problem
>>> I tried to disconnect wxSTC from the wxWidgets wrappers last night. I
>>> think it will take some doing however. Since they'll share the same
>>> lua namespace, they don't have to, but I would like the generic
>>> flexibility of putting multiple wrappers into the same namespace, any
>>> additional wrappers overwrite earlier ones. I have to do some reading
>>> up on how to add more to lua in C. I hope it won't be too hard.
>> ok, let me know if I can help in some way...
>
> I believe I got it to work. It currently generates a library that you
> link to in addition to the wxbind library. You can now add any
> arbitrary number of libraries to any lua namespace.
very nice !
> So, I guess we need to add some more dirs, let me know what you think
> about these.
>
> wxLua/bindings/wxstc/stc.i
> or wxLua/bindings/wxwidgets/contrib/stc/stc.i (maybe better)
there is the possibility that some day wx contrib stuff will be moved in
wxCode or somewhere else... so I would use wxLua/bindings/wxstc/stc.i
rather than wxLua/bindings/wxwidgets/contrib/stc/stc.i ...
> wxLua/modules/wxbindstc/ - same as wxbind
> * I think this has to be in it's own dir at the same level as wxbind
ok
>>>>>> 2) wxLUA_USE_wxCriticalSectionLocker is not defined - maybe it should
>>>>>> be added to wxluasetup.h
>>>>> looking to wxluasetup.h I've found that there is a heading which says
>>>>> that it's generated by "utils/get_luasetup"; however I couldn't find
>>>>> that util.
>>>>> Is that true or that's an old comment?
>>> That is a simple little utility, basicly just grep wxLUA_USE* for the
>>> .i files. I will try to find it if I can.
>> it would be nice to have it in CVS...
>
> I found it, it's an awk script that was written before we used the
> wxWidgets %if wxUSE_XXX in the bindings so it's pretty dumb and not
> very useful anymore.
>
> #=======================
> # read in all the .i files, look for "%if" print them out
>
> grep "%if" *.i | awk 'BEGIN {print("// Automatically generated by
> utils/get_luasetup edit as necessary."); \
> print(""); \
> print("#ifndef __WXLUA_SETUP__");
> print("#define __WXLUA_SETUP__");
> print("") } \
> { len = length($2); printf("#define %s",$2); for
> (i=0;i<40-len;i++) { printf(" ") }; print("1") } \
> END { print(""); print("#endif // __WXLUA_SETUP__") }'
> #=======================
No problem for me if we decide to maintain wxluasetup.h by hand.
In that case I will add wxLUA_USE_wxCriticalSectionLocker to it, ok ?
>
>>>>> 7) can I start to connect the options WXLUASETUP_DIR and
>>>>> WXLUABINDLIB_DIR to the build system ?
>>>> Before starting this work, I need to know exactly how they must work ;)
>>>>
>>>> If I'm right, they should be used not to *modify* the build of the
>>>> wxbind module of wxLua (which should always use the
>>>> modules/wxbind/src/wxluasetup.h header and should always go in the lib/
>>>> folder) but rather to *create* a new library, built from same sources of
>>>> wxbind module, which would be created in the WXLUABINDLIB_DIR folder and
>>>> which would use the wxluasetup.h found in the WXLUASETUP_DIR path.
>>>> Is it right ?
>>>
>>> I would be nice to be able to build the wxbind lib for different
>>> wxluasetup.h files, one lib for the wxLua app and others for your
>>> programs that use wxLua as a library. Sorry, I didn't follow this too
>>> closely.
>> Klaas, IIRC you would use these options... my description above describe
>> the wanted behaviour correctly, or there is something else which needs
>> to be done ?
>
> These are things that you can use with configure?
yes, there will be some options like --enable-custom-bindlib=path and
--with-custom-wxluasetup=path to enable the build of this additional lib.
> How would you make
> it so that you can build wxbind for the apps/wxlua and a different one
> for external programs. Do you have to run configure between building
> each of them?
No, that's not required. I'll just add another wxLua module which is
enabled only when WXLUABINDLIB_DIR!='' and which includes the
WXLUASETUP_DIR instead of the dir which contains the std wxluasetup.h.
Francesco
|
|
From: k. h. <kla...@nl...> - 2006-02-02 10:13:04
|
Francesco Montorsi wrote: >> >>>> 7) can I start to connect the options WXLUASETUP_DIR and >>>> WXLUABINDLIB_DIR to the build system ? >>> >>> >>> Before starting this work, I need to know exactly how they must work ;) >>> >>> If I'm right, they should be used not to *modify* the build of the >>> wxbind module of wxLua (which should always use the >>> modules/wxbind/src/wxluasetup.h header and should always go in the lib/ >>> folder) but rather to *create* a new library, built from same >>> sources of >>> wxbind module, which would be created in the WXLUABINDLIB_DIR folder >>> and >>> which would use the wxluasetup.h found in the WXLUASETUP_DIR path. >>> Is it right ? >> >> >> >> I would be nice to be able to build the wxbind lib for different >> wxluasetup.h files, one lib for the wxLua app and others for your >> programs that use wxLua as a library. Sorry, I didn't follow this too >> closely. > > Klaas, IIRC you would use these options... my description above > describe the wanted behaviour correctly, or there is something else > which needs to be done ? > I wonder first why wxluasetup.h is located in a source directory while it is a header file?? Why not place it in wbind/include? For application/libraries which want to extend/subset the wxLua bindings ( e.g. have one extra myextra.i file or disable some classes), one needs to have a wxluasetup.h of his own. So in such a case there must be two wxluasetup.h files in different locations. Same for the path where the library will be created. To extend wxLua in the same lua namespace, the new wxBindings modules could handle that once they work correctly. But that would always lead to an extra library in the end. For creating a subset of the wxLua bindings one will always need a second wxluasetup.h file. I think this should not be part of configure. It is a feature to be able to use the *.i files from wxLua and a different external wxluasetup.h file, to create an extra bindinglib which only is oke for the application who needs that. Maybe there or two application like that and one wants extend/subset X and the other Y. Also Installation of wxLua on Unix systems should not influence this mechanism. Although i did not ask for this feature ( John wanted this i think ), i would be glad with it now, since that would make it possible to use wxLua as is currently. I would just extend the base binding, and forget of creating extra bindings using the new mechanism. Without this feature, that is impossible, i would need to ask users to modify wxLua internal first. That would be bad. If all the new moduler binding features would work correctly, there is still a need for the above. It would be to create a subset of wxLua bindings to make the base binding library smaller for a specific application. If one can Unregister things runtime, the need would be less. All in all i think those variables would be good to have. regards, Klaas -- Unclassified |
|
From: Francesco M. <f18...@ya...> - 2006-02-02 17:53:45
|
Hi, k. holwerda ha scritto: > Francesco Montorsi wrote: >>>>> 7) can I start to connect the options WXLUASETUP_DIR and >>>>> WXLUABINDLIB_DIR to the build system ? >>>> >>>> >>>> Before starting this work, I need to know exactly how they must work ;) >>>> >>>> If I'm right, they should be used not to *modify* the build of the >>>> wxbind module of wxLua (which should always use the >>>> modules/wxbind/src/wxluasetup.h header and should always go in the lib/ >>>> folder) but rather to *create* a new library, built from same >>>> sources of >>>> wxbind module, which would be created in the WXLUABINDLIB_DIR folder >>>> and >>>> which would use the wxluasetup.h found in the WXLUASETUP_DIR path. >>>> Is it right ? >>> >>> >>> >>> I would be nice to be able to build the wxbind lib for different >>> wxluasetup.h files, one lib for the wxLua app and others for your >>> programs that use wxLua as a library. Sorry, I didn't follow this too >>> closely. >> >> Klaas, IIRC you would use these options... my description above >> describe the wanted behaviour correctly, or there is something else >> which needs to be done ? >> > I wonder first why wxluasetup.h is located in a source directory while > it is a header file?? Probably it was put in src/ thinking to the fact that it should be 'overrideable' by an option like WXLUASETUP_DIR. However I suggest to move wxluasetup.h in a directory ad-hoc like "wxLua/modules/setup" so that it would still be possible to include it using lines like: #include "wxluasetup.h" (since the wxLua/modules path is automatically added to include search paths). I'm proposing this because AFAIK every compiler is free to decide its own rules about include directories priority. That is, if we keep 'wxluasetup.h' in modules/wxbind/src, even if we give to the compiler the -I/userpath/to/custom/wxluasetup switch, we cannot be 100% sure that the compiler will use the /userpath/to/custom/wxluasetup/wxluasetup.h file instead of the modules/wxbind/src/wxluasetup.h.... If you agree, I'll move wxluasetup.h in wxLua/modules/setup and commit bakefile changes required to get this option to work. > Why not place it in wbind/include? because it would always be found by the compiler since the wxbind/include directory needs to be searched for headers in any case. This would give no problems when building the wxLua's wxbind lib but it could give problems when building user's wxbind lib since we need to be sure to be using the user's custom wxluasetup.h for that. > For application/libraries which want to extend/subset the wxLua bindings > ( e.g. have one extra myextra.i file or disable some classes), one needs > to have a wxluasetup.h of his own. So in such a case there must be two > wxluasetup.h files in different locations. sure > Same for the path where the library will be created. > To extend wxLua in the same lua namespace, the new wxBindings modules > could handle that once they work correctly. > But that would always lead to an extra library in the end. For creating > a subset of the wxLua bindings one will always need a second > wxluasetup.h file. sure > I think this should not be part of configure. > It is a feature to be able to use the *.i files from wxLua and a > different external wxluasetup.h file, to create an extra bindinglib > which only is oke for the application who needs that. Maybe there or two > application like that and one wants extend/subset X and the other Y. > Also Installation of wxLua on Unix systems should not influence this > mechanism. I'm not sure to understand what you mean. Users who do not need to extend wxLua with new bindings would just not use the -enable-custom-bindlib=path and --with-custom-wxluasetup=path options. Developers who need to build wxLua extensions would have to use them instead. This leads to another problem I'm going to describe later in another mail... > Although i did not ask for this feature ( John wanted this i think ), i > would be glad with it now, since that would make it possible to use > wxLua as is currently. I would just extend the base binding, and forget > of creating extra bindings using the new mechanism. > Without this feature, that is impossible, i would need to ask users > to modify wxLua internal first. That would be bad. that would be very bad, indeed. > If all the new moduler binding features would work correctly, there is > still a need for the above. It would be to create a subset of wxLua > bindings to make the base binding library smaller for a specific > application. If one can Unregister things runtime, the need would be less. > > All in all i think those variables would be good to have. Ok, so, in conclusion, my description of the wanted behaviour for those options is right, isn't it ? Francesco |
|
From: John L. <jla...@gm...> - 2006-02-02 20:03:17
|
On 2/2/06, Francesco Montorsi <f18...@ya...> wrote:
> > I wonder first why wxluasetup.h is located in a source directory while
> > it is a header file??
> Probably it was put in src/ thinking to the fact that it should be
> 'overrideable' by an option like WXLUASETUP_DIR.
>
> However I suggest to move wxluasetup.h in a directory ad-hoc like
> "wxLua/modules/setup" so that it would still be possible to include it
> using lines like:
>
> #include "wxluasetup.h"
>
> (since the wxLua/modules path is automatically added to include search
> paths).
>
> I'm proposing this because AFAIK every compiler is free to decide its
> own rules about include directories priority. That is, if we keep
> 'wxluasetup.h' in modules/wxbind/src, even if we give to the compiler
> the -I/userpath/to/custom/wxluasetup switch, we cannot be 100% sure that
> the compiler will use the /userpath/to/custom/wxluasetup/wxluasetup.h
> file instead of the modules/wxbind/src/wxluasetup.h....
>
> If you agree, I'll move wxluasetup.h in wxLua/modules/setup and commit
> bakefile changes required to get this option to work.
That sounds fine, I put wxluasetup.h in the src dir for the reason you stat=
ed.
> > If all the new moduler binding features would work correctly, there is
> > still a need for the above. It would be to create a subset of wxLua
> > bindings to make the base binding library smaller for a specific
> > application. If one can Unregister things runtime, the need would be le=
ss.
> >
> > All in all i think those variables would be good to have.
> Ok, so, in conclusion, my description of the wanted behaviour for those
> options is right, isn't it ?
I think it's good. I think it's better to compile your app and link
against a stripped down wxluabinding lib rather than try to remove
stuff at runtime. This way the linker can remove wxWidgets classes
that aren't used as well. If you take wxLua with everything then you
have to drag all of wxWidgets in too since it'll be referenced in the
binding code.
Regards,
John Labenski
|
|
From: klaas.holwerda <kho...@xs...> - 2006-02-02 21:25:52
|
Just to say i am all fine with what is proposed. It sounds good to me. Klaas John Labenski wrote: >On 2/2/06, Francesco Montorsi <f18...@ya...> wrote: > > >>>I wonder first why wxluasetup.h is located in a source directory while >>>it is a header file?? >>> >>> |
|
From: Francesco M. <f18...@ya...> - 2006-02-03 20:55:14
|
Hi,
I think I can update this thread with last two unsolved problems
(at least on Unix).
>1) STC (more generically CONTRIB) problem
Now that wxbindstc has been separed from remaining bindings, I think
that we can add a new option like USE_WXBINDSTCLIB which allows to
enable/disable it, right ?
Then, when USE_WXBINDSTCLIB=1, wxLuaApp can be built.
When the configure script (on Unix) detects wxStedit, then also
wxLuaEdit can be built. Is this right ?
2) wxLua application needs wxStyledTextCtrl wrapper and an error
should be given when it's not available instead of just failing it at
runtime (IMO)
This problem is still present, as far as I know.
Francesco Montorsi
|
|
From: Francesco M. <f18...@ya...> - 2006-02-05 11:08:40
|
hi, Francesco Montorsi ha scritto: > Hi, > I think I can update this thread with last two unsolved problems (at > least on Unix). > > >> 1) STC (more generically CONTRIB) problem > Now that wxbindstc has been separed from remaining bindings, I think > that we can add a new option like USE_WXBINDSTCLIB which allows to > enable/disable it, right ? > > Then, when USE_WXBINDSTCLIB=1, wxLuaApp can be built. > > When the configure script (on Unix) detects wxStedit, then also > wxLuaEdit can be built. Is this right ? I have worked on the configure script and added USE_WXBINDSTC option. Now when the user has not compiled wxSTC, he's kindly warned that he needs to that if he wants to compile wxLuaApp and wxLuaEdit, but that he can use the --disable-wxbindstc option to skip them. I've tried to compile & install wxSTC and to compile wxLuaApp but when I try to run it I get the error: frm@genius:~/work/wxLua/gtksud/bin$ ./wxlua [string "./wxlua"]:374: attempt to call field `wxStyledTextCtrl' (a nil value)wxLua: Error while running chunkwxLua: Error while running chunk previously I thought that this error was because of missing wxStEdit control but I've now realized that wxLuaApp doesn't need it and that wxStyledTextCtrl is defined in wxSTC. So, please ignore problem #2 of my previous mail; this is the problem I meant: when running wxluaapp, even if you compiled wxSTC and wxBindSTC you get the error above (at least on Unix). The configure script now just misses a check for wxStEdit component, which must enable/disable wxLuaEdit, right ? Francesco |
|
From: klaas.holwerda <kho...@xs...> - 2006-02-05 21:09:11
|
Francesco Montorsi wrote: > > The configure script now just misses a check for wxStEdit component, > which must enable/disable wxLuaEdit, right ? Right. Klaas > > |
|
From: Francesco M. <f18...@ya...> - 2006-02-06 10:14:13
|
Hi, klaas.holwerda ha scritto: > Francesco Montorsi wrote: > >> >> The configure script now just misses a check for wxStEdit component, >> which must enable/disable wxLuaEdit, right ? > > Right. I've done some work on bakefiles: 1) fixed some problems with DLL naming 2) added next to WX_SHARED the SHARED option so that one can build static builds of wxLua against shared builds of wxWidgets (with SHARED=0 WX_SHARED=1) 3) added check for wxStEdit in configure script 4) changed WX_DEBUG=0/1 to BUILD=release/debug like the one wxWidgets use 5) changed WX_UNICODE=0/1 to UNICODE=0/1 like the one wxWidgets use Hopefully, the build system should now be complete and working. I've tested it against various builds of wxWidgets and it worked nicely... I'm going to test it on win32... Francesco |
|
From: Francesco M. <f18...@ya...> - 2006-02-06 11:04:47
|
Hi, > klaas.holwerda ha scritto: >> Francesco Montorsi wrote: >> >>> >>> The configure script now just misses a check for wxStEdit component, >>> which must enable/disable wxLuaEdit, right ? >> >> Right. > I've done some work on bakefiles: > > 1) fixed some problems with DLL naming > 2) added next to WX_SHARED the SHARED option so that one can build > static builds of wxLua against shared builds of wxWidgets (with SHARED=0 > WX_SHARED=1) > 3) added check for wxStEdit in configure script > 4) changed WX_DEBUG=0/1 to BUILD=release/debug like the one wxWidgets use > 5) changed WX_UNICODE=0/1 to UNICODE=0/1 like the one wxWidgets use > > Hopefully, the build system should now be complete and working. > I've tested it against various builds of wxWidgets and it worked > nicely... I'm going to test it on win32... tested on win32; I fixed some little bugs and found that now everything should work nicely except for two things: 1) I'm using wxCVS also on win32 and I've found that I had to put wxLUA_USE_wxHelpController to 0 otherwise I got an error about wxWinHelpController. 2) wxluacan app works nicely but wxluaapp still crashes at startup with the same error I got from unix version... Francesco |
|
From: k. h. <kla...@nl...> - 2006-02-06 15:12:48
|
Francesco Montorsi wrote: > tested on win32; I fixed some little bugs and found that now > everything should work nicely except for two things: > > 1) I'm using wxCVS also on win32 and I've found that I had to put > wxLUA_USE_wxHelpController to 0 otherwise I got an error about > wxWinHelpController. From what i updated yesterday. When i run wxLua i get the (lua script) error: wxlua.exe:374: attempt to call field `wxStyledTextCtrl' ( a nil value) And then exit. Is that the same problem? app_wxluaedit does not have that problem. > > 2) wxluacan app works nicely but wxluaapp still crashes at startup > with the same error I got from unix version... > Only when running a script, there is still the same problem of object added in lua and destroyed in c++. But this is just a wxLua bug. Will test the very lattest this evening. Klaas Unclassified |
|
From: John L. <jla...@gm...> - 2006-02-06 20:35:55
|
On 2/6/06, Francesco Montorsi <f18...@ya...> wrote:
> > I've done some work on bakefiles:
Great.
> 1) I'm using wxCVS also on win32 and I've found that I had to put
> wxLUA_USE_wxHelpController to 0 otherwise I got an error about
> wxWinHelpController.
This was a bug in wxWidgets CVS HEAD a few weeks ago. They had
duplicate #include guards for two different files. IIRC it was
html/helpwnd.h and msw/helpwin.h, it's fixed now.
> 2) wxluacan app works nicely but wxluaapp still crashes at startup with
> the same error I got from unix version...
This error?
>frm@genius:~/work/wxLua/gtksud/bin$ ./wxlua
>[string "./wxlua"]:374: attempt to call field `wxStyledTextCtrl' (a nil
>value)wxLua: Error while running chunkwxLua: Error while running chunk
I don't get it in linux w/ gcc, but I do get it in MSW with VC Express
2005. It has to do with the linker throwing out all of the wxbindstc
lib since it's "not used" directly, but through a wxModule. I think
the cleanest way to do this is to make people run C functions to
initialize each of the binding modules they link to. Similiar to
wxWidgets' WXINIT_ALL_IMAGE_HANDLERS (or whatever it's called). I'll
change this ASAP, but probably tonight.
Regards,
John Labenski
|
|
From: k. h. <kla...@nl...> - 2006-02-02 15:22:10
|
Francesco Montorsi wrote: > Hi, > > John Labenski ha scritto: > >> On 2/1/06, Francesco Montorsi <f18...@ya...> wrote: >> >>>>>>> 1) STC (more generically CONTRIB) problem >>>>>> >>>> I tried to disconnect wxSTC from the wxWidgets wrappers last night. I >>>> think it will take some doing however. Since they'll share the same >>>> lua namespace, they don't have to, but I would like the generic >>>> flexibility of putting multiple wrappers into the same namespace, any >>>> additional wrappers overwrite earlier ones. I have to do some reading >>>> up on how to add more to lua in C. I hope it won't be too hard. >>> >>> ok, let me know if I can help in some way... >> >> >> I believe I got it to work. It currently generates a library that you >> link to in addition to the wxbind library. You can now add any >> arbitrary number of libraries to any lua namespace. > I will test against the sample wxluacan, is something special needed? I still have no answer on if i can add it or not? What is the problem? > there is the possibility that some day wx contrib stuff will be moved > in wxCode or somewhere else... so I would use > wxLua/bindings/wxstc/stc.i rather than > wxLua/bindings/wxwidgets/contrib/stc/stc.i ... me too. > > >> wxLua/modules/wxbindstc/ - same as wxbind >> * I think this has to be in it's own dir at the same level as wxbind > > ok Oke. Klaas -- Unclassified |
|
From: John L. <jla...@gm...> - 2006-02-02 17:14:53
|
On 2/2/06, k. holwerda <kla...@nl...> wrote: > >> On 2/1/06, Francesco Montorsi <f18...@ya...> wrote: > >> > >>>>>>> 1) STC (more generically CONTRIB) problem > >>>>>> > >>>> I tried to disconnect wxSTC from the wxWidgets wrappers last night. = I > >>>> think it will take some doing however. Since they'll share the same > >>>> lua namespace, they don't have to, but I would like the generic > >>>> flexibility of putting multiple wrappers into the same namespace, an= y > >>>> additional wrappers overwrite earlier ones. I have to do some readin= g > >>>> up on how to add more to lua in C. I hope it won't be too hard. > >>> > >>> ok, let me know if I can help in some way... > >> > >> I believe I got it to work. It currently generates a library that you > >> link to in addition to the wxbind library. You can now add any > >> arbitrary number of libraries to any lua namespace. > > > I will test against the sample wxluacan, is something special needed? > I still have no answer on if i can add it or not? What is the problem? Yes, please add it. I forgot to respond. > > there is the possibility that some day wx contrib stuff will be moved > > in wxCode or somewhere else... so I would use > > wxLua/bindings/wxstc/stc.i rather than > > wxLua/bindings/wxwidgets/contrib/stc/stc.i ... > > me too. Ok all done and committed. I haven't updated the bakefiles, but the Makefiles work in linux. -John Labenski |
|
From: Francesco M. <f18...@ya...> - 2006-02-06 17:19:13
|
Hi, k. holwerda ha scritto: >> tested on win32; I fixed some little bugs and found that now >> everything should work nicely except for two things: >> >> 1) I'm using wxCVS also on win32 and I've found that I had to put >> wxLUA_USE_wxHelpController to 0 otherwise I got an error about >> wxWinHelpController. > > From what i updated yesterday. > > When i run wxLua i get the (lua script) error: > > wxlua.exe:374: attempt to call field `wxStyledTextCtrl' ( a nil value) > > And then exit. Is that the same problem? this is my problem #2; the problem about wxWinHelpController is a compile problem in wxbind. If you did not find it with wx2.6 it's probably because wxdev must have done some change in some preprocessor symbol... >> 2) wxluacan app works nicely but wxluaapp still crashes at startup >> with the same error I got from unix version... >> > Only when running a script, there is still the same problem of object > added in lua and destroyed in c++. > But this is just a wxLua bug. I'd like to help you and John to solve this but I still have much to learn with wxLua. Francesco |
|
From: John L. <jla...@gm...> - 2006-02-06 20:39:16
|
On 2/6/06, Francesco Montorsi <f18...@ya...> wrote: > >> 2) wxluacan app works nicely but wxluaapp still crashes at startup > >> with the same error I got from unix version... > >> > > Only when running a script, there is still the same problem of object > > added in lua and destroyed in c++. > > But this is just a wxLua bug. > I'd like to help you and John to solve this but I still have much to > learn with wxLua. I can take a look at the bindings tonight. You have to be careful about using %delete since if you use it wxLua will delete the object for you, something you don't want for wxWindow derived classes or objects that are managed in some other code. -John Labenski |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X