wxlua-users — wxLua list for users and developers

Re: [Wxlua-users] Thinger. A DX7 editor for SysEx data transfer to DX7, FS1R etc.

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

I've just been looking at the wxWidgets manual, at propagation, which appears to be the root of this business. It says only wsCommandEvent based events are propagated. As the word command appears in all the spin control, button, menu, events, I guess this is no co-incidence.

How do I make sure that wxEVT_LEFT_DCLICK propagates all the way back to the frame?

Re: [Wxlua-users] Thinger. A DX7 editor for SysEx data transfer to DX7, FS1R etc.

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

Here's an example. It will exit if the panel is double-clicked because wxEVT_LEFT_UP is explicitly linked to the panel, but the notebook isn't clickable, nor would any control on it be clickable unless it has its own explicit handling code. All I want is for wxEVT_LEFT_UP to be handled wherever it appears, and for my function to filter the event according to the ID of the control that produced the event. I've tested stuff to confirm that the ID is indeed passed, so this ought to work, and to be ideal. If it wasn't impossible...

If any toolbar button or menu entry works with wxEVT_COMMAND_MENU_SELECTED, and any button works with wxEVT_COMMAND_BUTTON_CLICKED, surely it makes sense to have any double-click of the left mouse button work with wxEVT_LEFT_DCLICK regardless of where in the area of a frame or dialog it happens. Separating the events by ID filtering is easy, so this would be the right way, given that it's fine for most other controls events. It might be arguable that there could be too many things to filter from, but I can't imagine why, there are only so many clicks per second the average human finger can do. :)

--=======================================================

FRAME=wx.wxFrame(wx.wxNull,-1,TITLE,wx.wxDefaultPosition,wx.wxSize(436,314))   

PANEL=wx.wxPanel(FRAME,-1)                                                     

PAGES=wx.wxNotebook(                                                           
    PANEL,
    -1,
    wx.wxPoint(11,30),
    wx.wxSize(405,230),
    wx.wxNB_TOP
)

PANEL:ConnectEvent(-1,wx.wxEVT_LEFT_UP,                                   
    function(event)  FRAME:Destroy()  end
)

FRAME:Centre()
FRAME:Show(wx.TRUE)

--=======================================================

Re: [Wxlua-users] Thinger. A DX7 editor for SysEx data transfer to DX7, FS1R etc.

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

The problem isn't the spincontrols.

I only quoted those as an example of what works.

The mouse event stuff is much less easy. Most of the mouse stuff seems to be absent, lots of things in the wxWidgets manual don't have any meaning in wxLua as far as I know. My specific problem is that I can't do FRAME:ConnectEvent(-1,wx.wxEVT_LEFT_DCLICK,DoStuff) and then make it work for anything I left click on the frame.

If I have FRAME:ConnectEvent(-1,wx.wxEVT_COMMAND_SPINCTRL_UPDATED,DoStuff) I can put a spin control on a page on a notebook on a panel on a frame, and it will work. All spin controls will work, wherever they are.

If I have FRAME:ConnectEvent(-1,wx.wxEVT_LEFT_DCLICK,DoStuff) ONLY the frame can be clicked! I must specify an exact one-to-one relationship for every control I want to click! I have 6 on each of three pages. Right now the required code will bulk to about 25% of all my active code because there is no way to sensible group the controls.
I keep looking at it in stupefaction. Though I've found ways to make it work, it's a horrible kludge, and there seems to be no elegant way to do it.

Re: [Wxlua-users] Thinger. A DX7 editor for SysEx data transfer to DX7, FS1R etc.

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

On 6/26/05, The Doctor <the...@bl...> wrote:
> Hello, I've decided to try to use wx.wxEVT_LEFT_DCLICK and such to make s=
pecific mouse events for fast access to several things via a small number o=
f controls, so that this access depends on motor memory as well as visual m=
emory, this being very fast and easy to use.
>=20
> I've managed to make a single button (or even a static text label) be a c=
ontrol for this, so it's very versatile, but there is a major drawback: the=
 window (control) must be assigned to a variable, and that means the event =
handlers proliferate in horrible tiers of duplication. With spin controls, =
it doesn't matter how many there are, or how many parent controls they're p=
laced on, they're all captured by wx.wxEVT_COMMAND_SPINCTRL_UPDATED, but ob=
viously I can't assign all my custom clickable controls to 'CC' to capture =
with CC:ConnectEvent(-1,wx.wxEVT_LEFT_DCLICK,DoStuff).

I'm not sure I understand, all events are captured by your event
handler for wx.wxEVT_COMMAND_SPINCTRL_UPDATED?

In terms of easing the amount of duplicate code perhaps something like
this could work. (untested)

function CreateMySpinCtrl(parent, id, ...)
    local win =3D wx.wxSpinCtrl(parent, id, ...)
    win:ConnectEvent(id, wx.wxEVT_COMMAND_SPINCTRL_UPDATED, func)
    return win -- return it for further processing if desired, ok if not us=
ed
end

> Is there a way to group these assigned controls so a single event handler=
 passes the flow to a single function which filters the controls by ID as u=
sual? I've thought of making tables indexed by ID so that for loops can red=
uce the sixe of the source code, but this doesn't really solve the problem.

Are you saying that you cannot use the same function for two separate
win: ConnectEvent calls? I don't know of any reason why this shouldn't
work. Maybe you could post the simplest snippet of code that shows
your problem, just add a panel and two controls to the
VeryMinimal.wx.lua sample.

Regards,
    John Labenski

Re: [Wxlua-users] Thinger. A DX7 editor for SysEx data transfer to DX7, FS1R etc.

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

Hello, I've decided to try to use wx.wxEVT_LEFT_DCLICK and such to make specific mouse events for fast access to several things via a small number of controls, so that this access depends on motor memory as well as visual memory, this being very fast and easy to use.

I've managed to make a single button (or even a static text label) be a control for this, so it's very versatile, but there is a major drawback: the window (control) must be assigned to a variable, and that means the event handlers proliferate in horrible tiers of duplication. With spin controls, it doesn't matter how many there are, or how many parent controls they're placed on, they're all captured by wx.wxEVT_COMMAND_SPINCTRL_UPDATED, but obviously I can't assign all my custom clickable controls to 'CC' to capture with CC:ConnectEvent(-1,wx.wxEVT_LEFT_DCLICK,DoStuff).

Is there a way to group these assigned controls so a single event handler passes the flow to a single function which filters the controls by ID as usual? I've thought of making tables indexed by ID so that for loops can reduce the sixe of the source code, but this doesn't really solve the problem.

Re: [Wxlua-users] Thinger. A DX7 editor for SysEx data transfer to DX7, FS1R etc.

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

Belay that :)

You had a . instead of a : in that code. The reporting didn't suggest that directly, but I wondered about it, and played with breaking a : to a . in some working code and got a similar error, so I tried the reverse here, and it fixed it.

Re: [Wxlua-users] Thinger. A DX7 editor for SysEx data transfer to DX7, FS1R etc.

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

John Labenski <jla...@gm...> wrote:
(25/06/2005 21:22)

>
>> Another thing I haven't found a way to do is make a popup menu that appears if a button is clicked. I tried till I got confused, and all I can say is that nothing worked, and the variety of error reports was dazzling. :)
>
>local popMenu = wx.wxMenu()
>-- add normal menu items
>-- to position the menu for a button use local rect =
>mybutton.GetRect() to find the bottom left.
>mywindow.PopupMenuXY(popMenu, mouseEvt.GetX(), mouseEvt.GetY())
>
>Regards,
>    John Labenski
>

Thankyou. I can't make that work though, even when it's spelled out like that.

The mouseEvt's are nil values, so I substitute actual numbers, and that won't work either. If I take the PopupMenu instead of PopupMenuXY, and use a wxPoint instead of the two integers (as specified in the wxWidgets manual), that doesn't work either. I need something tested and verified. The problem I have is that if something works I can thrash around on my own trying to vary things to see what works, what breaks, and maybe even what will work better. If I can't get anything to work, all I can do is plead from a state of utter helplessness. Any actual working script, complete, no matter how small, is great, I can then take it apart til I know how it ticks.

Re: [Wxlua-users] Thinger. A DX7 editor for SysEx data transfer to DX7, FS1R etc.

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

On 6/25/05, The Doctor <the...@bl...> wrote:
> A couple of things came up in the last two days:
> One is wx.wxSYS_COLOR_HIGHLIGHT or any other system colour. I found I cou=
ld specify wxColour(nnn,nnn,nnn), but I can't substitute any system colour,=
 wxLua complains of an unexpected user defined data type if I try this. I a=
lso wonder if there are ever issues with color and colour. I've tested a co=
uple in other contexts and found it will take either, which is cool.

wx.wxSYS_COLOR_HIGHLIGHT (a number IIRC) is meant for wxSystemSettings.
local c =3D wx.wxSystemSettings.GetColour(wx.wxSYS_COLOR_HIGHLIGHT)
-- the above errors out since there's no constuctor for wxSystemSettings...
print("%d %d %d", c.Red(), c.Green(), c.Blue())

I think it's impossible to get at them since static methods aren't
handled properly. They need to be added to the wrappers as "LuaGlobal"
with a name of something like "wxSystemSettings_GetColour".

I'm sorry that we're deadlocked currently, I can't work on or test
this until we get a working wrapper system. Maybe another week or so.

> Another thing I haven't found a way to do is make a popup menu that appea=
rs if a button is clicked. I tried till I got confused, and all I can say i=
s that nothing worked, and the variety of error reports was dazzling. :)

local popMenu =3D wx.wxMenu()
-- add normal menu items
-- to position the menu for a button use local rect =3D
mybutton.GetRect() to find the bottom left.
mywindow.PopupMenuXY(popMenu, mouseEvt.GetX(), mouseEvt.GetY())

Regards,
    John Labenski

Re: [Wxlua-users] Thinger. A DX7 editor for SysEx data transfer to DX7, FS1R etc.

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

John Labenski <jla...@gm...> wrote:
(23/06/2005 16:59)

>
>Let me be the first to say, welcome to wxLua. The app you're writing
>sounds impressive, it'd be great to hear how things work or don't work
>for you so we can patch up wxLua. There are so many components in
>wxWidgets that it's impossible to test them all ourselves.
>

Thankyou :) I stopped for a few days to do other things, heat and 99.9% humidity make foul conditions for thinking clearly...

A couple of things came up in the last two days:
One is wx.wxSYS_COLOR_HIGHLIGHT or any other system colour. I found I could specify wxColour(nnn,nnn,nnn), but I can't substitute any system colour, wxLua complains of an unexpected user defined data type if I try this. I also wonder if there are ever issues with color and colour. I've tested a couple in other contexts and found it will take either, which is cool.

Another thing I haven't found a way to do is make a popup menu that appears if a button is clicked. I tried till I got confused, and all I can say is that nothing worked, and the variety of error reports was dazzling. :)

>
>I don't think anyone has any plans to implement this, but since this
>is so specialized you're on your own in terms of what library to use.
>We'd be happy to show how to write and implement wrapper for the lib
>however.
> 

That would help a lot. I haven't looked into MIDI libraries yet, but I certainly will, if I can't find a small SysEx file handler that doesn't work hidden. If this wrapper is something that can be written in Lua or wxLua I can learn this, though if it's C I prefer to stay away, because I found that learning C was too much, and is an all or nothing effort demanding too much detailed learning of the systems that support it. This why I turned to Lua in the first place. I can get things done without having to be a full-time programmer.

>> Last question: Is there anything (or will there be something) that can compile a wkLua script with all resources into a standalone binary? This would make wxLua more attractive than Visual Studio, to me. And probably to a few thousand other people, I suspect.
>
>This would be great, but this is probably going to be on the back
>burner for awhile. Python can do it, so it must be possible.
>

Good to hear. :) Python is quite large and complex, I've read, so wxLua having this ability would be a strong tool, and for many uses might be preferred by people who use both.

Re: [Wxlua-users] Thinger. A DX7 editor for SysEx data transfer to DX7, FS1R etc.

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

On 6/21/05, The Doctor <the...@bl...> wrote:
> Just testing the mail for now, and saying I'm new to wxLua and I like it =
immensely. I'll turn over my project to help the cause, when it's done. To =
those who don't know the Yamaha DX7 synthesiser and the many compatible ins=
truments made in the 22 years since, the Thinger will just be an extensive =
example of slightly eccentric wxLua coding, but to those who make electroni=
c music, I hope it will be as useful to you as it already is to me. It's fu=
nctional, emulates the original DX7's use of Init, Edit/Compare and Recall =
buffers, but I'm next to work on operator copy and algorithm display, and o=
perations on 32-voice bank files.
>=20
> I'll release this as a full v1, when it's at least as fuctional as an FM =
synthesizer should be, I expect this to be in anything up to about 6 weeks =
time, but it might be a lot less.
>

Let me be the first to say, welcome to wxLua. The app you're writing
sounds impressive, it'd be great to hear how things work or don't work
for you so we can patch up wxLua. There are so many components in
wxWidgets that it's impossible to test them all ourselves.

> One bit of help I could use is some helpful comments regarding MIDI. This=
 is a serial asycnchronous 31.25 Kbaud interface with 8 bits and a start/st=
op bit added to each byte, and a simple protocol with values over 127 as St=
atus bytes, the rest as Data bytes, making it a useful machine control tran=
smission with uses well beyone electronic music. This might excite someone =
into coding a library for wxLua. I hope. :) Right now I'm using a small Ger=
man app called SysEx, which takes a command line, but I want something that=
 doesn't pop up every time it's invoked.

I don't think anyone has any plans to implement this, but since this
is so specialized you're on your own in terms of what library to use.
We'd be happy to show how to write and implement wrapper for the lib
however.
=20
> Last question: Is there anything (or will there be something) that can co=
mpile a wkLua script with all resources into a standalone binary? This woul=
d make wxLua more attractive than Visual Studio, to me. And probably to a f=
ew thousand other people, I suspect.

This would be great, but this is probably going to be on the back
burner for awhile. Python can do it, so it must be possible.

> To end: I'll add posts if I run out of ideas while working, begging for h=
elp, but I won't ask before I solve most things as I prefer it that way. Al=
so, thans to John Labenski who has already helped a lot, and has helped lau=
nch this SourceForge effort, partly in response to my own wish that it migh=
t happen.
>=20

For very general wxWidgets questions you can even post to the wx-users
list. People will probably show you how to do things in c++ however,
but it can probably be translated.
=20
> PS. Small buglet? wxTextCtrl has rthe wrong system colour for text. There=
 are at least two in MSwindows, and someone seems to have picked the wrong =
one. wxTE_RICH as style corrects this, but it would be nice to have it as d=
efault. :)

Humm, hopefully this will get sorted out in the next few weeks. We
can't test anything until the wrappers get fixed up though.

Regards,
    John Labenski

ps. Please turn wordwrap on in your mailer, all your paragraphs come
out as extremely long lines.

[Wxlua-users] Thinger. A DX7 editor for SysEx data transfer to DX7, FS1R etc.

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

Just testing the mail for now, and saying I'm new to wxLua and I like it immensely. I'll turn over my project to help the cause, when it's done. To those who don't know the Yamaha DX7 synthesiser and the many compatible instruments made in the 22 years since, the Thinger will just be an extensive example of slightly eccentric wxLua coding, but to those who make electronic music, I hope it will be as useful to you as it already is to me. It's functional, emulates the original DX7's use of Init, Edit/Compare and Recall buffers, but I'm next to work on operator copy and algorithm display, and operations on 32-voice bank files.

I'll release this as a full v1, when it's at least as fuctional as an FM synthesizer should be, I expect this to be in anything up to about 6 weeks time, but it might be a lot less.

One bit of help I could use is some helpful comments regarding MIDI. This is a serial asycnchronous 31.25 Kbaud interface with 8 bits and a start/stop bit added to each byte, and a simple protocol with values over 127 as Status bytes, the rest as Data bytes, making it a useful machine control transmission with uses well beyone electronic music. This might excite someone into coding a library for wxLua. I hope. :) Right now I'm using a small German app called SysEx, which takes a command line, but I want something that doesn't pop up every time it's invoked.

Last question: Is there anything (or will there be something) that can compile a wkLua script with all resources into a standalone binary? This would make wxLua more attractive than Visual Studio, to me. And probably to a few thousand other people, I suspect.

To end: I'll add posts if I run out of ideas while working, begging for help, but I won't ask before I solve most things as I prefer it that way. Also, thans to John Labenski who has already helped a lot, and has helped launch this SourceForge effort, partly in response to my own wish that it might happen.

Crow.


PS. Small buglet? wxTextCtrl has rthe wrong system colour for text. There are at least two in MSwindows, and someone seems to have picked the wrong one. wxTE_RICH as style corrects this, but it would be nice to have it as default. :)

Re: [Wxlua-users] Changing binding files

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

On 6/20/05, Ray Gilbert <ray...@sc...> wrote:
> I am currently working on generating a set of *.i files directly from
> wxWidgets headers, instead of hand coding them each time. This will allow=
 us
> to maintain a complete up to date binding with less effort.=20

Cool! What about wx24 and groan wx22. Personally, I don't think we
should bother with anything <wx26 at this point. (note: wx22 was the
last win16 version IIRC, if anyone cares)

Unless of course all you need to do is download wx22 and run your
program and poof you get wrappers... :)
  =20
> I wonder if it is better to follow the wxWidgets structure of=20
> Base, Gui, Adv, Net, Html, etc=20
> as _wx_base.i  _wx_net.i_wx_gui.i  _wx_adv.i etc

Might as well, I broke the original (whatever it was called) wrapper
file up into the current state since it was so overwhelming. But now,
I find that having so many of them is annoying in it's own way.

It'd be great if you could keep each .i file ordered by each .h file
so that you can compare them in case something's funny.

> and for specific toolkits=20
> _wx_gui_gtk.i   _wx_gui_mac.i  _wx_gui_mac_carbon.i   _wx_gui_mac_cocoa.i=
=20
>  _wx_gui_msw.i  _wx_gui_os2.i=20

I suppose you have an idea of how this could work? Mmmm, I think I see
how... the generator doesn't care if you duplicate %classes, it'll
just contine to add members to them. (I'm just talking out loud,
ignore this)

Personally I don't think we have to bother with too much really
platform dependent stuff. wxLua is an interpreted language and as such
can provide a fairly complete system, just using the stuff that works
everywhere.
Things like this are probably useless since you can't do anything with
them anyway.
gdi.i:    %win WXHANDLE GetHandle()
gdi.i:    %win void SetHandle(WXHANDLE handle)

> (I have been able to get a nice set of *.h files for ctags to use from
> wxWidgets files.bkl)=20

Good, I thought it doesn't handle the #ifdefs though? Anyway I guess
you found a way.
  =20
> Internally have still have equivalants of each wxUSE_ with wxLUA_USE_=20
> The will enable end users to only bind the wx modules they are using, and
> the power to customise what is exposed by lua interpreter=20

Good, I think that's important. As you probably know, but just to
reiterate, my idea was to be able to reduce the size and that you can
sandbox wxLua (a little bit, at least) by not wrapping some of the
more dangerous classes like wxApp.

---------------
Some thoughts about rewriting things. :)

I think the wrapper should ignore trailing ";" for class members or
"," for enums.

Additionally do we want to just use=20
%class  or %enum
{
stuff
}; (again trailing ";" is ignored)

instead of %class %endclass. Basicly if we could make the wrapper
files as close to c++ as possible it'd be trivial for people to write
their own. Maybe you could even use a visual diff program to compare
them to the original, which would be really nice!

You could even make=20
#ifdef __WXMSW__=20
#elif ...
#endif=20
mean for the wrapper to literally stick the c++ #ifdef around all the
wrappers in the middle without any interpretation of it at all. This
may be a lot more compilicated though... forget it if it's too hard.

Finally might as well change %include to #include right? Since it
implies that we want to do a c++ #include.

Thanks for your work,
    John Labenski

[Wxlua-users] Changing binding files

[Ray G. <ray...@sc...>]

I am currently working on generating a set of *.i files directly from
wxWidgets headers, instead of hand coding them each time. This will
allow us to maintain a complete up to date binding with less effort.
=20
I wonder if it is better to follow the wxWidgets structure of
=20
Base, Gui, Adv, Net, Html, etc=20
=20
as
_wx_base.i=20
_wx_net.i
_wx_gui.i
_wx_adv.i=20
etc
=20
and for specific toolkits
_wx_gui_gtk.i=20
_wx_gui_mac.i=20
_wx_gui_mac_carbon.i=20
_wx_gui_mac_cocoa.i=20
_wx_gui_msw.i=20
_wx_gui_os2.i
=20
(I have been able to get a nice set of *.h files for ctags to use from
wxWidgets files.bkl)
=20
Internally have still have equivalants of each wxUSE_ with wxLUA_USE_
=20
The will enable end users to only bind the wx modules they are using,
and the power to customise what is exposed by lua interpreter
=20
Ray

Re: [Wxlua-users] Bakefile

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

On 6/20/05, f18m_217828 <f18...@ya...> wrote:
> Hi,
>     I have updated wxLua bakefiles & makefiles so that it compiles also
> wxbind module.
>=20
> However, I have two issues to ask:
>=20
> 1) the auto-generated files by "genwxbin.bat" are not in the CVS; this
> is okay to me but I'd need to know if bakefile build system needs to
> call it (this is not a problem) to generate the wxbind source files or
> those files, missing in the CVS, will be included in the releases of
> wxLua (and thus bakefile should not call that batch file)...

Lets, not put them up just yet, people will have to run genwxbind.bat
or do the equivalent to generate them. I wouldn't bother generating
them using bakefiles either. We have some cleaning up to do first.
Eventually we'll just have all the cpp files in wxbind/src all the
time since they'll have #ifdefs to work under any condition (but not
yet).
=20
> 2) I now get some error while trying to compile the wxbind module:
>          cl /c /nologo /TP /Fomsvcud\wxbind_lib_wx_define.obj /MDd
...
> ..\..\wxbind\src\wx_define.cpp
>=20
> wx_define.cpp
> wx/wave.h header is deprecated, use wx/sound.h and wxSound

Yes, %if wxLUA_USE_WAVE is being ignored and we haven't added wxSound
instead, ignore this warning for now.

> ..\..\wxbind\src\wx_define.cpp(1511) : error C2065:
> 'CB_LEFT_BAR_HANDLE_HITTED'
> : undeclared identifier

Just set these values to 0, they're from the contrib/include/fl/
library. Again the %if wxLUA_USE_FL is being ignored. You'll have to
do this everytime you run genwxbind.lua until genwxbind.lua gets
fixed.

> ..\..\wxbind\src\wx_define.cpp(1899) : error C2065: 'wxEOL_UNIX' :
> undeclared identifier

put #include "wx/txtstrm.h" at the top of wx_define.cpp, somehow it's
getting skipped even though it's at the bottom of defutils.i. It
probably has something to do with the %enums before it. Again, this is
an issue with genwxbind.lua.

> 3) I see that "luad.exe" has been added in the CVS bin folder:
> - is this wanted ?

No, you should be able to build this on the fly. We should remove it
since every time you build wxlua's lua it'll get overwritten and get
uploaded again (as I did by accident).

> - bakefile builds lua exe always with the name 'lua.exe'; should I
> change it to build 'luad.exe' when debug is enabled ?
> I'd say no because genwxbind.bat does not know which version (build or
> release) of lua has been built and so it needs to refer to the same
> executable name, 'lua.exe', in every build config...

There probably isn't any reason to build lua.exe in debug ever, (that
should always work) but I just wanted to give them different names.
You're probably right though, it'll make things easier to just output
the release and debug versions right on top of each other and leave it
up to the user to remember what they did last. I'll change my dsp
files accordingly.
=20
> 4) I'll start linux build testing asap... I'll let you know

We're a little stuck until we get the %builtin wrappers working since
it's hard to test. Also use samples/editor.wx.lua by running wxLua
../../../samples/editor.wx.lua since the default uses the binary
editor.h which hasn't been updated yet. You get some errors, but the
GUI works.
=20
> 5) I've added DSW/DSP files to CVS so that wxLua can be built also using
> bakefile-generated project files...
> however, until bakefile build system does not perfectly work I'd keep
> the current dsw files scattered in modules dirs...

Yes, I use the XXX_wx26 ones, you're right, I'll remove them once
things get working.

>6) where should I write bakefile build system docs (both for users'
>usage info and for some internal notes for modifying the build system
>itself...) ?
>I'd propose to create an install.html file in root folder where we put
>all this infos...

I think it should go into the docs folder, don't you think? People
should be able to find it easily enough.

-----=20

Sorry, things are a little messed up right now, as Ray said this may
take a little time to get sorted out. Don't bother remming things out
in the .i files (or at least don't commit the changes) since once
genwxbind is working again we'll have to restore them.

-John Labenski

Re: [Wxlua-users] Bakefile

[f18m_217828 <f18...@ya...>]

6) where should I write bakefile build system docs (both for users' 
usage info and for some internal notes for modifying the build system 
itself...) ?
I'd propose to create an install.html file in root folder where we put 
all this infos...

Francesco

Re: [Wxlua-users] Bakefile

[f18m_217828 <f18...@ya...>]

Hi,
    I have updated wxLua bakefiles & makefiles so that it compiles also 
wxbind module.

However, I have two issues to ask:

1) the auto-generated files by "genwxbin.bat" are not in the CVS; this 
is okay to me but I'd need to know if bakefile build system needs to 
call it (this is not a problem) to generate the wxbind source files or 
those files, missing in the CVS, will be included in the releases of 
wxLua (and thus bakefile should not call that batch file)...

2) I now get some error while trying to compile the wxbind module:

         cl /c /nologo /TP /Fomsvcud\wxbind_lib_wx_define.obj /MDd 
/DWIN32 /D_UNI
CODE  /D__WXDEBUG__ /D__WXMSW__  /IT:\wxWidgets\lib\vc_lib\mswud 
/IT:\wxWidgets
\include /I..\..\..\modules /W4 /Od  /Zi 
/Fd..\..\..\lib\vc_lib\wxbind.pdb /D_DE
BUG   /IT:\wxWidgets\contrib\include /GR /EHsc 
..\..\wxbind\src\wx_define.cpp

wx_define.cpp
wx/wave.h header is deprecated, use wx/sound.h and wxSound
..\..\wxbind\src\wx_define.cpp(1511) : error C2065: 
'CB_LEFT_BAR_HANDLE_HITTED'
: undeclared identifier
..\..\wxbind\src\wx_define.cpp(1567) : error C2065: 
'CB_RIGHT_BAR_HANDLE_HITTED'
  : undeclared identifier
..\..\wxbind\src\wx_define.cpp(1596) : error C2065: 
'CB_BAR_CONTENT_HITTED' : un
declared identifier
..\..\wxbind\src\wx_define.cpp(1643) : error C2065: 'wxEOL_MAC' : 
undeclared ide
ntifier
..\..\wxbind\src\wx_define.cpp(1681) : error C2065: 'wxEOL_NATIVE' : 
undeclared
identifier
..\..\wxbind\src\wx_define.cpp(1716) : error C2065: 'CB_NO_ITEMS_HITTED' 
: undec
lared identifier
..\..\wxbind\src\wx_define.cpp(1782) : error C2065: 
'CB_LOWER_ROW_HANDLE_HITTED'
  : undeclared identifier
..\..\wxbind\src\wx_define.cpp(1807) : error C2065: 
'CB_UPPER_ROW_HANDLE_HITTED'
  : undeclared identifier
..\..\wxbind\src\wx_define.cpp(1899) : error C2065: 'wxEOL_UNIX' : 
undeclared id
entifier
..\..\wxbind\src\wx_define.cpp(2101) : error C2065: 'wxEOL_DOS' : 
undeclared ide
ntifier
NMAKE : fatal error U1077: 'cl' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Programmi\Microsoft Visual 
Studio\VC98\bin\NMAKE
.EXE"' : return code '0x2'
Stop.


Also, the first message:
"wx/wave.h header is deprecated, use wx/sound.h and wxSound" is repeated 
in each file of wxbind module since it's included in wxbind.h...

3) I see that "luad.exe" has been added in the CVS bin folder:
- is this wanted ?
- bakefile builds lua exe always with the name 'lua.exe'; should I 
change it to build 'luad.exe' when debug is enabled ?
I'd say no because genwxbind.bat does not know which version (build or 
release) of lua has been built and so it needs to refer to the same 
executable name, 'lua.exe', in every build config...

4) I'll start linux build testing asap... I'll let you know

5) I've added DSW/DSP files to CVS so that wxLua can be built also using 
bakefile-generated project files...
however, until bakefile build system does not perfectly work I'd keep 
the current dsw files scattered in modules dirs...

Francesco Montorsi

Re: [Wxlua-users] Can we have standard LUA_PATH for wxLua apps

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

On 6/20/05, John Labenski <jla...@gm...> wrote:
> On 6/19/05, Ray Gilbert <ray...@sc...> wrote:
> > I will upload my stuff as soon as I get the wx interface generator
> > working and I can tie it altogther.
> >
> > I say there is a week or two of me fiddling.
>=20
> Is there a quick hack that could be made to this in the meantime?
> http://cvs.sourceforge.net/viewcvs.py/wxlua/wxLua/bindings/genwxbind.lua?=
view=3Dmarkup
> Search for the two "FIXME" lines

I've committed a simple hack to get the enums to work. However the %if
wxLUA_USE still doesn't work so you have to edit the wx_define.cpp and
add
include "wx/txtstrm.h" and put arbitrary values for CB_XXX (for fl) to
get it compile.

You can run the sample/editor.wx.lua again! The editor.h has to be
regenerated though so you have do do "wxLua.exe editor.wx.lua".
=20
%builtin is still busted so you can't run wxExecute. :(

-John Labenski

> I've tried quite a few things, but can't figure out why putting this
> after the first FIXME doesn't set the DataType
> lineState.DataType =3D tag
>=20
> later on line 1572 we need the DataType for AllocMember
>   -- enum parseObject
>   if parseState.ObjectStack[1].DefType =3D=3D "enum" then
>   ...
>   for k, v in lineState do print("lineState", k, v) end
>   local member=3D AllocMember(lineState)
>=20
> The print dump of the lineState shows that lineState.DataType is back to =
nil.
>=20
> >Maybe longer when baby is born - second one due this week.
>=20
> Congrats!
>=20
> Thanks,
>     John
>=20
> > Ray
> >
> > -----Original Message-----
> > From: wxl...@li...
> > [mailto:wxl...@li...] On Behalf Of John
> > Labenski
> > Sent: Monday, 20 June 2005 13:43
> > To: wxl...@li...
> > Subject: Re: [Wxlua-users] Can we have standard LUA_PATH for wxLua apps
> >
> > On 6/19/05, Ray Gilbert <ray...@sc...> wrote:
> > >
> > > Currently we do not set the LUA_PATH when we run scripts.
> > >
> > > So the require() fn does not correctly find modules.
> > >
> > > I have added GetLuaPath(), AddLuaPath() to my wxLuaInterpreter object=
,
> >
> > > can I add it to wxLua?
> >
> > Sure! I tried very hard to make it so that wxLua should be as close as =
I
> > could make it to your version while keeping any fixes Paul and I made.
> > Hopefully you can use it out of the box, but probably not, fit it up as
> > necessary. In the beginning they'll be some growing pains as people
> > change things to make it work better for them, but so long as it's done
> > in a way to keep everything else working, nobody should complain.
> >
> > For example, it looks to me like wxLuaStateVariables should be renamed
> > to wxLuaState, and it'll encapsulate just the lua_State and manage the
> > memory. We can put all the tgetxxx and toxxx functions in the wxLuaStat=
e
> > as static functions to make the code a little more readable. The
> > wxLuaInterpreter will then just be a thin wrapper around the wxLuaState
> > that provides even simpler methods and the wxLuaEvents.
> > That way you can use either the simplier wxLuaInterpreter or the lighte=
r
> > wxLuaState as you see fit.
> >
> > Anyway all I'm trying to say is that for a little bit now things may ge=
t
> > ugly, but they'll settle down. The bottom line - I never want to go
> > though the hassle of merging the different wxLuas again so if you need =
a
> > feature, add it here so we can all benefit.
> >
> > Ray - do you want to put your extra modules up at sourceforge? That way
> > when people change something they can also compile those and fix them u=
p
> > if necessary so there won't be too much breakage.
> >
> > > BTW
> > >
> > > I currently only add script path -
> > > But should we have standard wxLua search path?
> > > Should it search OS PATH?
> > > Are there other paths it should search by default, e.g.
> > > <app>/lua/?.lua; <script>/lua/?.lua;
> >
> > I thought that require searches typical system places already? I haven'=
t
> > any thoughts on this.
> >
> > -John Labenski
> >
> >
> > -------------------------------------------------------
> > 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_idt77&alloc_id=16492&op=3Dick
> > _______________________________________________
> > Wxlua-users mailing list
> > Wxl...@li...
> > https://lists.sourceforge.net/lists/listinfo/wxlua-users
> >
> >
> > -------------------------------------------------------
> > 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_idt77&alloc_id=16492&opclick
> > _______________________________________________
> > Wxlua-users mailing list
> > Wxl...@li...
> > https://lists.sourceforge.net/lists/listinfo/wxlua-users
> >
>

Re: [Wxlua-users] Can we have standard LUA_PATH for wxLua apps

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

On 6/19/05, Ray Gilbert <ray...@sc...> wrote:
> I will upload my stuff as soon as I get the wx interface generator
> working and I can tie it altogther.
>=20
> I say there is a week or two of me fiddling.=20

Is there a quick hack that could be made to this in the meantime?
http://cvs.sourceforge.net/viewcvs.py/wxlua/wxLua/bindings/genwxbind.lua?vi=
ew=3Dmarkup
Search for the two "FIXME" lines

I've tried quite a few things, but can't figure out why putting this
after the first FIXME doesn't set the DataType
lineState.DataType =3D tag

later on line 1572 we need the DataType for AllocMember
  -- enum parseObject
  if parseState.ObjectStack[1].DefType =3D=3D "enum" then
  ...
  for k, v in lineState do print("lineState", k, v) end
  local member=3D AllocMember(lineState)

The print dump of the lineState shows that lineState.DataType is back to ni=
l.

>Maybe longer when baby is born - second one due this week.

Congrats!

Thanks,
    John

> Ray
>=20
> -----Original Message-----
> From: wxl...@li...
> [mailto:wxl...@li...] On Behalf Of John
> Labenski
> Sent: Monday, 20 June 2005 13:43
> To: wxl...@li...
> Subject: Re: [Wxlua-users] Can we have standard LUA_PATH for wxLua apps
>=20
> On 6/19/05, Ray Gilbert <ray...@sc...> wrote:
> >
> > Currently we do not set the LUA_PATH when we run scripts.
> >
> > So the require() fn does not correctly find modules.
> >
> > I have added GetLuaPath(), AddLuaPath() to my wxLuaInterpreter object,
>=20
> > can I add it to wxLua?
>=20
> Sure! I tried very hard to make it so that wxLua should be as close as I
> could make it to your version while keeping any fixes Paul and I made.
> Hopefully you can use it out of the box, but probably not, fit it up as
> necessary. In the beginning they'll be some growing pains as people
> change things to make it work better for them, but so long as it's done
> in a way to keep everything else working, nobody should complain.
>=20
> For example, it looks to me like wxLuaStateVariables should be renamed
> to wxLuaState, and it'll encapsulate just the lua_State and manage the
> memory. We can put all the tgetxxx and toxxx functions in the wxLuaState
> as static functions to make the code a little more readable. The
> wxLuaInterpreter will then just be a thin wrapper around the wxLuaState
> that provides even simpler methods and the wxLuaEvents.
> That way you can use either the simplier wxLuaInterpreter or the lighter
> wxLuaState as you see fit.
>=20
> Anyway all I'm trying to say is that for a little bit now things may get
> ugly, but they'll settle down. The bottom line - I never want to go
> though the hassle of merging the different wxLuas again so if you need a
> feature, add it here so we can all benefit.
>=20
> Ray - do you want to put your extra modules up at sourceforge? That way
> when people change something they can also compile those and fix them up
> if necessary so there won't be too much breakage.
>=20
> > BTW
> >
> > I currently only add script path -
> > But should we have standard wxLua search path?
> > Should it search OS PATH?
> > Are there other paths it should search by default, e.g.
> > <app>/lua/?.lua; <script>/lua/?.lua;
>=20
> I thought that require searches typical system places already? I haven't
> any thoughts on this.
>=20
> -John Labenski
>=20
>=20
> -------------------------------------------------------
> 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_idt77&alloc_id=16492&op=3Dick
> _______________________________________________
> Wxlua-users mailing list
> Wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>=20
>=20
> -------------------------------------------------------
> 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_idt77&alloc_id=16492&opclick
> _______________________________________________
> Wxlua-users mailing list
> Wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>

Re: [Wxlua-users] Updated with wxIDE's wrappers

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

On 6/19/05, Ray Gilbert <ray...@sc...> wrote:
> I am working on binding generators again - I will look into it

Great, genwxbind.lua looks incredibly powerful (and cleanly written),
but I think I'm missing the big picture of what function calls what to
do what. Could you put a few comments in it when you get a chance.

Also, the enums don't respect the %if wxLUA_USE conditions, only the
%wxchkver ones that appear on the same line as the enum.

Thanks,
    John

>=20
> Ray
>=20
> -----Original Message-----
> From: wxl...@li...
> [mailto:wxl...@li...] On Behalf Of John
> Labenski
> Sent: Sunday, 19 June 2005 07:14
> To: wxl...@li...
> Subject: [Wxlua-users] Updated with wxIDE's wrappers
>=20
> Unfortunately they're busted, but hopefully only slightly. Everything
> builds properly except for a hundred or so errors about undeclared
> identifiers, but see #1 below.
>=20
> 1) genwxbind doesn't handle %enums properly, it needs to write
> enumType::enumName so it can handle enums in a class. Unfortunately I
> cannot make any sense of genwxbind so I've left it with two "FIXME"
> lines, one where the enumType is known and one where I want to use it.
>=20
> 2) It doesn't seem to write out the %builtin functions, I can't figure
> this out at all.
>=20
> Ray could you take a look at this, I've only modified genwxbind ever so
> slightly.
>=20
> See wxLua/bindings/genwxbind.bat to see how to generate new bindings.
>=20
> You can easily test them by using wxLua/apps/wxlua/src/wxLua_wx26.dsw
> which will build everything. (I've not updated the makefiles)
>=20
> I've decided to put the output of the wrappers into
> wxLua/modules/wxbind/include and src this way the code necessary for
> virtual functions can be built right with it, I've called those wxlprint
> and wxlhtmlwin (used to be wxLuaPrinting, wxLuaHtmlWin).
>=20
> I think the only viable option for personalized bindings to link to is
> to have people's projects compile the wrapper cpp files into their own
> lib using their own luasetup.h file. We should have a generic build file
> to build all of them as is, this is what wxlua will use. I've added my
> wxluabind_wx26.dsp file in modules/wxbind/src/ to do this already, but
> eventually we can make bakefile do this.
>=20
> I've not uploaded the wrapper *.cpp files yet since they don't work, are
> huge, and can be easily generated, but if you run the code in
> genwxbind.bat you'll get them.
>=20
> I hope this makes sense, this is our last step and once apps/wxlua
> compiles properly anyone is free to do as they please since I think
> we've got the best of all the various wxLuas now. Just remember, test
> the wxlua app against any change you make and fix it up if necessary.
>=20
> Regards,
>     John Labenski
>=20
>

RE: [Wxlua-users] Can we have standard LUA_PATH for wxLua apps

[Ray G. <ray...@sc...>]

I will upload my stuff as soon as I get the wx interface generator
working and I can tie it altogther.

I say there is a week or two of me fiddling. Maybe longer when baby is
born - second one due this week.

Ray

-----Original Message-----
From: wxl...@li...
[mailto:wxl...@li...] On Behalf Of John
Labenski
Sent: Monday, 20 June 2005 13:43
To: wxl...@li...
Subject: Re: [Wxlua-users] Can we have standard LUA_PATH for wxLua apps

On 6/19/05, Ray Gilbert <ray...@sc...> wrote:
> =20
> Currently we do not set the LUA_PATH when we run scripts.=20
>  =20
> So the require() fn does not correctly find modules.=20
>
> I have added GetLuaPath(), AddLuaPath() to my wxLuaInterpreter object,

> can I add it to wxLua?

Sure! I tried very hard to make it so that wxLua should be as close as I
could make it to your version while keeping any fixes Paul and I made.
Hopefully you can use it out of the box, but probably not, fit it up as
necessary. In the beginning they'll be some growing pains as people
change things to make it work better for them, but so long as it's done
in a way to keep everything else working, nobody should complain.

For example, it looks to me like wxLuaStateVariables should be renamed
to wxLuaState, and it'll encapsulate just the lua_State and manage the
memory. We can put all the tgetxxx and toxxx functions in the wxLuaState
as static functions to make the code a little more readable. The
wxLuaInterpreter will then just be a thin wrapper around the wxLuaState
that provides even simpler methods and the wxLuaEvents.
That way you can use either the simplier wxLuaInterpreter or the lighter
wxLuaState as you see fit.
  =20
Anyway all I'm trying to say is that for a little bit now things may get
ugly, but they'll settle down. The bottom line - I never want to go
though the hassle of merging the different wxLuas again so if you need a
feature, add it here so we can all benefit.

Ray - do you want to put your extra modules up at sourceforge? That way
when people change something they can also compile those and fix them up
if necessary so there won't be too much breakage.

> BTW
>  =20
> I currently only add script path -
> But should we have standard wxLua search path?=20
> Should it search OS PATH?=20
> Are there other paths it should search by default, e.g. =20
> <app>/lua/?.lua; <script>/lua/?.lua;

I thought that require searches typical system places already? I haven't
any thoughts on this.

-John Labenski


-------------------------------------------------------
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_idt77&alloc_id=16492&op=3Dick
_______________________________________________
Wxlua-users mailing list
Wxl...@li...
https://lists.sourceforge.net/lists/listinfo/wxlua-users

Re: [Wxlua-users] Can we have standard LUA_PATH for wxLua apps

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

On 6/19/05, Ray Gilbert <ray...@sc...> wrote:
> =20
> Currently we do not set the LUA_PATH when we run scripts.=20
>  =20
> So the require() fn does not correctly find modules.=20
>
> I have added GetLuaPath(), AddLuaPath() to my wxLuaInterpreter object, ca=
n I
> add it to wxLua?=20

Sure! I tried very hard to make it so that wxLua should be as close as
I could make it to your version while keeping any fixes Paul and I
made. Hopefully you can use it out of the box, but probably not, fit
it up as necessary. In the beginning they'll be some growing pains as
people change things to make it work better for them, but so long as
it's done in a way to keep everything else working, nobody should
complain.

For example, it looks to me like wxLuaStateVariables should be renamed
to wxLuaState, and it'll encapsulate just the lua_State and manage the
memory. We can put all the tgetxxx and toxxx functions in the
wxLuaState as static functions to make the code a little more
readable. The wxLuaInterpreter will then just be a thin wrapper around
the wxLuaState that provides even simpler methods and the wxLuaEvents.
That way you can use either the simplier wxLuaInterpreter or the
lighter wxLuaState as you see fit.
  =20
Anyway all I'm trying to say is that for a little bit now things may
get ugly, but they'll settle down. The bottom line - I never want to
go though the hassle of merging the different wxLuas again so if you
need a feature, add it here so we can all benefit.

Ray - do you want to put your extra modules up at sourceforge? That
way when people change something they can also compile those and fix
them up if necessary so there won't be too much breakage.

> BTW=20
>  =20
> I currently only add script path -=20
> But should we have standard wxLua search path?=20
> Should it search OS PATH?=20
> Are there other paths it should search by default, e.g.  <app>/lua/?.lua;
> <script>/lua/?.lua;=20

I thought that require searches typical system places already? I
haven't any thoughts on this.

-John Labenski

[Wxlua-users] Can we have standard LUA_PATH for wxLua apps

[Ray G. <ray...@sc...>]

Currently we do not set the LUA_PATH when we run scripts.
=20
So the require() fn does not correctly find modules.
=20
I have added GetLuaPath(), AddLuaPath() to my wxLuaInterpreter object,
can I add it to wxLua?
=20
BTW=20
=20
I currently only add script path -
But should we have standard wxLua search path?
Should it search OS PATH?
Are there other paths it should search by default, e.g.
<app>/lua/?.lua; <script>/lua/?.lua;
=20
Ray
=20
=20

RE: [Wxlua-users] Updated with wxIDE's wrappers

[Ray G. <ray...@sc...>]

I am working on binding generators again - I will look into it

Ray=20

-----Original Message-----
From: wxl...@li...
[mailto:wxl...@li...] On Behalf Of John
Labenski
Sent: Sunday, 19 June 2005 07:14
To: wxl...@li...
Subject: [Wxlua-users] Updated with wxIDE's wrappers

Unfortunately they're busted, but hopefully only slightly. Everything
builds properly except for a hundred or so errors about undeclared
identifiers, but see #1 below.

1) genwxbind doesn't handle %enums properly, it needs to write
enumType::enumName so it can handle enums in a class. Unfortunately I
cannot make any sense of genwxbind so I've left it with two "FIXME"
lines, one where the enumType is known and one where I want to use it.

2) It doesn't seem to write out the %builtin functions, I can't figure
this out at all.

Ray could you take a look at this, I've only modified genwxbind ever so
slightly.

See wxLua/bindings/genwxbind.bat to see how to generate new bindings.

You can easily test them by using wxLua/apps/wxlua/src/wxLua_wx26.dsw
which will build everything. (I've not updated the makefiles)

I've decided to put the output of the wrappers into
wxLua/modules/wxbind/include and src this way the code necessary for
virtual functions can be built right with it, I've called those wxlprint
and wxlhtmlwin (used to be wxLuaPrinting, wxLuaHtmlWin).

I think the only viable option for personalized bindings to link to is
to have people's projects compile the wrapper cpp files into their own
lib using their own luasetup.h file. We should have a generic build file
to build all of them as is, this is what wxlua will use. I've added my
wxluabind_wx26.dsp file in modules/wxbind/src/ to do this already, but
eventually we can make bakefile do this.

I've not uploaded the wrapper *.cpp files yet since they don't work, are
huge, and can be easily generated, but if you run the code in
genwxbind.bat you'll get them.

I hope this makes sense, this is our last step and once apps/wxlua
compiles properly anyone is free to do as they please since I think
we've got the best of all the various wxLuas now. Just remember, test
the wxlua app against any change you make and fix it up if necessary.

Regards,
    John Labenski


-------------------------------------------------------
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_idt77&alloc_id=16492&op=3Dick
_______________________________________________
Wxlua-users mailing list
Wxl...@li...
https://lists.sourceforge.net/lists/listinfo/wxlua-users

[Wxlua-users] Updated with wxIDE's wrappers

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

Unfortunately they're busted, but hopefully only slightly. Everything
builds properly except for a hundred or so errors about undeclared
identifiers, but see #1 below.

1) genwxbind doesn't handle %enums properly, it needs to write
enumType::enumName so it can handle enums in a class. Unfortunately I
cannot make any sense of genwxbind so I've left it with two "FIXME"
lines, one where the enumType is known and one where I want to use it.

2) It doesn't seem to write out the %builtin functions, I can't figure
this out at all.

Ray could you take a look at this, I've only modified genwxbind ever
so slightly.

See wxLua/bindings/genwxbind.bat to see how to generate new bindings.

You can easily test them by using wxLua/apps/wxlua/src/wxLua_wx26.dsw=20
which will build everything. (I've not updated the makefiles)

I've decided to put the output of the wrappers into
wxLua/modules/wxbind/include and src
this way the code necessary for virtual functions can be built right
with it, I've called those wxlprint and wxlhtmlwin (used to be
wxLuaPrinting, wxLuaHtmlWin).

I think the only viable option for personalized bindings to link to is
to have people's projects compile the wrapper cpp files into their own
lib using their own luasetup.h file. We should have a generic build
file to build all of them as is, this is what wxlua will use. I've
added my wxluabind_wx26.dsp file in modules/wxbind/src/ to do this
already, but eventually we can make bakefile do this.

I've not uploaded the wrapper *.cpp files yet since they don't work,
are huge, and can be easily generated, but if you run the code in
genwxbind.bat you'll get them.

I hope this makes sense, this is our last step and once apps/wxlua
compiles properly anyone is free to do as they please since I think
we've got the best of all the various wxLuas now. Just remember, test
the wxlua app against any change you make and fix it up if necessary.

Regards,
    John Labenski

RE: [Wxlua-users] wxIDE compilation (was bakefile)

[Ray G. <ray...@sc...>]

Your right, I should have called it Debug DLL. I will change this to
correctly show correct lib to use.

You can add c:\wx\wxWindows\lib\vc_dll; to you system PATH. Windows will
search path directory when loading dlls
Or
Put dlls in same directory as exe (When I eventually get a release I
will do this)

Ray

-----Original Message-----
From: wxl...@li...
[mailto:wxl...@li...] On Behalf Of John
Labenski
Sent: Wednesday, 15 June 2005 13:38
To: wxl...@li...
Subject: [Wxlua-users] wxIDE compilation (was bakefile)

On 6/13/05, Ray Gilbert <ray...@sc...> wrote:
> Last night I cvs to wxIDE the latest wxXmlRpc, DebuggerNub, cdLua=20
> files so you may want to update them as well.
>=20
> I can now run cdLua.exe as an external process of wxStudio and debug=20
> the lua script. The debugger can show callstack, global and local
variables.

I'm still having a hard time compiling wxIDE using your "Debug" which I
think is really Debug DLL, right? I compiled wxWidgets as Debug and
Debug DLL (non unicode) and can compile a wxWidgets sample w/o problem
though when I run it I get an error saying that it can't find the DLL,
do I really have to copy them to my windows/system dir? I've never
compiled wxWidgets as a DLL before, always static lib in MSW.

I have the environment variable WXWIN set properly and use it for my own
programs. I'm using VC6 on WinXP using build/msw/CodeDragon.dsw in Batch
Build. Could you tell me exactly what settings you use to compile
wxWidgets and wxIDE so I can try those?

Here are some of the (hundreds of) errors I get

C:\wxCVS\wxIDE\wxIDE\parts\thread\src\threadmanager.cpp(43): Could not
find the file sys/time.h.
c:\wxCVS\wxWidgets\include\wx\defs.h(2297): Could not find the file
unistd.h.
c:\wxCVS\wxWidgets\include\wx\wxchar.h(107): Could not find the file
wcstr.h.
c:\wxCVS\wxWidgets\include\wx\string.h(47): Could not find the file
strings.h.
c:\wxCVS\wxWidgets\include\wx\string.h(51): Could not find the file
StringMgr.h.
c:\wxCVS\wxWidgets\include\wx\utils.h(41): Could not find the file
dirent.h.
c:\wxCVS\wxWidgets\include\wx\utils.h(42): Could not find the file
unistd.h.
c:\wxCVS\wxWidgets\include\wx\platform.h(37): Could not find the file
unistd.h.
c:\wxCVS\wxWidgets\include\wx\platform.h(515): Could not find the file
PalmOS.h.
=20
They're bizarre, how the heck is it getting here?! WXPALMOS is defined
nowhere as far as I can tell, not in
$(WXWIN)/lib/vc_dll/mswd/include/wx/setup.h at least. Like I said I get
no errors or warnings whatsoever compiling a wxWidget's sample.

#ifdef __WXPALMOS__
#   include <PalmOS.h>   -- platform.h line 515
#   undef Abs
#endif

> I am now working on a set of lua scripts to merge new wxWidget=20
> versions
> - so it can pick up new wx classes, merge new members automatically.
> This will save lots of time as new wx versions are released.

Sounds good, but first... I found that none of the enums are being
written to the wrapper.cpp files. I traced though genwxbind.lua the best
I could and didn't see any difference between the "enum" handling and
the "define" handling, but I haven't started to really debug it.

I'm slowly merging them, I'll try to get it working by the end of the
week, but I'd like to see what wxIDE looks like to get a better
understanding of it.

-John Labenski


> -----Original Message-----
> From: wxl...@li...
> [mailto:wxl...@li...] On Behalf Of John=20
> Labenski
> Sent: Tuesday, 14 June 2005 03:32
> To: wxl...@li...
> Subject: Re: [Wxlua-users] Bakefile
>=20
> Thanks for all your work.
>=20
> I'm slowly merging wxIDE's cdlua's code and wrappers, but it's slow=20
> going. I hope to have it done be the end of the week and then everyone

> can just use this version of wxLua.
>=20
> Regards,
>     John Labenski
>=20
> On 6/12/05, Francesco Montorsi <f18...@ya...> wrote:
> > Hi,
> >
> > >>1) I see wxLua\src & wxLua\include are not listed in dirs.txt;=20
> > >>should they be removed ?
> > > Yes, but let's leave them for now since they still have one file=20
> > > in them that Ray says he doesn't want, but it probably wouldn't=20
> > > hurt to
>=20
> > > let it be for a bit.
> > ok, no problem
> >
> >
> > >>2) The targets which need to be built are:
> > >>- modules\lua
> > >>- modules\wxlua
> > >>- modules\wxluadebug
> > >>- modules\wxluasocket
> > >
> > > for modules/lua you need to build two things, lua.exe the lua=20
> > > executable and lua.lib the library. lua should be built as a=20
> > > static lib on all platforms, see the Makefiles and dsp files to=20
> > > see how it's done.
> > > Maybe you can take a look at these bakefiles to see if they'll=20
> > > work for us http://lua-users.org/wiki/LuaAddons
> > > http://www.geocities.com/f18m_cpp217828/prog/lua_win32.zip
> > yes, they'll work for us since I created them and uploaded the links

> > above in lua wiki & on my website ;-)
> >
> > >>Do they support shared (i.e. DLL) builds ?
> > > Hopefully yes, I've never build wxWidgets as a DLL, but I copied=20
> > > the
>=20
> > > code in the wxWidget's contrib and added WXDLLIMPEXP_WXLUA which=20
> > > should export things properly. I have no idea about lua itself
> though.
> > ok, I'll try
> >
> >
> > >>All the output should go to wxArt2d\lib, right ?
> > > No? It goes to wxLua/lib for the libraries and lua.exe goes to=20
> > > wxLua/bin this is a standalone library that anyone can use.
> > oops; I just meant wxLua/lib & wxLua/bin... sorry
> >
> > >>Its output should go to wxArt2d\bin, right ?
> > >
> > > No, it should be built in either wxLua/bin or just=20
> > > wxLua/apps/wxlua/src/vc_xxx for VC for example, in much the same=20
> > > way
>=20
> > > wxWidgets builds it's samples.
> > again I mistyped the path...
> >
> >
> > >>4) in wxLua\bindings\wxwidgets there are some CPP & H files;=20
> > >>should they be built as a library ?
> > >>If yes, how should that lib be called ?
> > >
> > > No, for now they're included directly into the wrappers which is=20
> > > probably the simplest solution for now. Thew whole wrapper thing=20
> > > is going to change somehow...
> > ok
> >
> > > Maybe we could put apps/wxlua/build into just apps/build to=20
> > > simplify
> things.
> > right, that makes things more simmetric :-)
> >
> > >>to build the project, the user should just go to wxlua\build\msw=20
> > >>and
>=20
> > >>type
> > >>
> > >>nmake -fmakefile.vc WX_UNICODE=3D0/1 WX_SHARED=3D0/1 ....
> > >
> > >
> > > That would be great, maybe we could also have a dsw file as well,=20
> > > see apps/wxlua/src/wxLua.dsw that can build all the libraries=20
> > > using "batch build" just like wx.dsw.
> > sure; exactly like wxWidgets also have DSW/DSP files.
> >
> > >>PS: I see that exists a file called luasetup.h in=20
> > >>wxlua\bindings\wxwidgets; what is its use ? should it be generated

> > >>by some tool/makefile ?
> > > When you run bindings/wxluawrap.lua it takes either the=20
> > > luasetup.h.in the bindings dir or in your own program's dir and=20
> > > generates luasetup.h that may exclude other classes automatically
> using their dependencies.
> > > It can be updated by hand. Please see apps/wxlua/wrap.bat/lua and=20
> > > Makefile_import to see how the wrappers are generated. It's build=20
> > > is
>=20
> > > also automated in apps/wxlua/src/wxlua_wx26.dsp running wrap.bat=20
> > > to generate wxluawrap.cpp, can bakefile do this sort of thing?
> > yes, it can; I'll set up all this stuff when done with modules=20
> > bakefile; first I'll create modules\build stuff...
> >
> > I'll let you know,
> > Francesco
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: NEC IT Guy Games.  How far can=20
> > you shotput a projector? How fast can you ride your desk chair down=20
> > the
> office luge track?
> > If you want to score the big prize, get to know the little guy.
> > Play to win an NEC 61" plasma display: =
http://www.necitguy.com/?r=3D20

> > _______________________________________________
> > Wxlua-users mailing list
> > Wxl...@li...
> > https://lists.sourceforge.net/lists/listinfo/wxlua-users
> >
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you=20
> shotput a projector? How fast can you ride your desk chair down the=20
> office luge track?
> If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> Wxlua-users mailing list
> Wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you=20
> shotput a projector? How fast can you ride your desk chair down the
office luge track?
> If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> Wxlua-users mailing list
> Wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>


-------------------------------------------------------
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_idt77&alloc_id=16492&op=3Dick
_______________________________________________
Wxlua-users mailing list
Wxl...@li...
https://lists.sourceforge.net/lists/listinfo/wxlua-users