wxlua-users Mailing List for wxLua

Hi

I downloaded the latest windows binary files and wanted to create a window GUI
using GL Canvas to integrate it into our application - but wxGLCanvas in the wx
table is nil. The documentation states that it is integrated however. 
Any tips what I am doing wrong?

Thanks
Eike Decker

Sounds good, I'll try to get to it this next week, but I'll be
traveling so I may be out of contact for the duration.

Regards,
    John

On Fri, Apr 18, 2008 at 5:27 AM, LuaCalc Dev <tec...@ya...> wrote:
> As a great fan of lua ( and wx of course ), i joined a wxlua based project.
>
>  It's called luacalc and is hosted on sourceforge.
>
>  *atm the *BETA* version is located in svn/experiment.(will be solved)
>   the BETA is the version to download.
>
>  Basically luacalc is an interface between a (excel alike) sheet and wx.
>   it has:
>   - a GUI completely based on sizers.
>   - realtime data update (the sheet itself is a lua progam)
>   - basic graphics like a resizable line graph.(realtime too)
>   - atm no good csv support but it can load *some* csv.
>     *(loads/saves own lua tables)
>   - loads directly under wxlua editor (as dll, windows only,rest is untested)
>   - Example sheets like graphics,timezones,system,font properties.
>    *these reside in the main svn folder under grids, !! use the .lsv NOT .csv !!
>
>  *reminder: because lua uses : for objects and csv : for ranges
>   use the pipe | like A1|B6 to select range A1 to B6 (returns a table)
>   A1:create() is possible this way.
>
>  Try it,any suggestions are welcome.(even negative as long as they can be used in
>  a positive way).
>
>  I would be very honoured if the wxlua site would reference to us (a bit of
>  advertising never hurts), or any other kind of cooperation.
>
>  Luacalc itself is a good demonstration of several wx parts interfaced together,
>  so if you want to learn about wx workings it seems a good source (to me).
>   ( whether the code is optimal stays a point of discussion )
>
>  Thank you for your time.
>
>  The Luacalc dev team.
>
>  04/18/08
>
>
>
>
>  -------------------------------------------------------------------------
>  This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>  Don't miss this year's exciting event. There's still time to save $100.
>  Use priority code J8TL2D2.
>  http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>  _______________________________________________
>  wxlua-users mailing list
>  wxl...@li...
>  https://lists.sourceforge.net/lists/listinfo/wxlua-users
>

On Tue, Apr 15, 2008 at 9:23 AM, Adrian Carpenter <ad...@ts...> wrote:
>
>  I am using the latest windows binaries from the wxLua site, I have
>  generated a simple import library for wx.dll by providing the luaopen_wx
>  export.
>
>  I call the luaopen_wx function in the same manner that the other lua
>  libraries are opened (basically a copy of the luaL_openlibs function),
>  and wxLua is loading and I can quite happily use it, a call to
>  wx.wxMessageBox promptly opens a messagebox.

This is right.

>  My simple test case simply does a lua_open, lua_openlibs (including wx),
>  lua_close.  It doesn't actually execute any lua code.  When the host
>  program exits, wx.dll tries to access the lua_state variable (which was
>  closed long before) and ends up accessing an invalid pointer, and
>  crashes.  It appears to be when wx.dll is unloaded.

Can you debug this and let me know where wxLua tries to access the
lua_State? Perhaps you could post a backtrace? I assume somewhere in
the wxLuaState destructor.

Perhaps you have the linking order wrong and Lua is linked after wxLua
(but I doubt that the linker would allow that) and when the program
exits Lua closes then wxLua closes.

When you display a dialog or frame and then close it wxLua will exit
the app since that is the normal behavior of a GUI app, i.e. the
message loop is exited and there's nothing left to do.

Regards,
     John

ps. I will be away again next week so I may not have time to respond quickly.

John Labenski <jlabenski@...> writes:

> 
> On Feb 1, 2008 12:05 AM, A. Klingenstein <klingens@...> wrote:
> > I have a Windows app in C which can and mainly does load plugins to "do
> > the actual work".
> >
> > One of those plugins is a Lua interpreter allowing users to write their
> > scripts. I want to make Lua scripts which can do GUI stuff and not only
> > "backend", non-visual things. I wanted to use wxLua for that, but the
> > main application already has its own normal Windows event message pump.
> > How can I add one or possibly several (from several different Lua GUI
> > scripts) mainloops?
> >
> > Are threads my only solution for this problem or are there alternatives
> > I haven't seen yet?
> 
> I am not familiar with how to replace the wxWidgets event loop, but
> from the messages I've seen on the wx-users mailing list I think
> people have been told to use the wxWidgets message loop. However, I
> think it would be best to search their mailing list to be sure. If you
> can find a way that will work it would be possible to change the wxLua
> module to behave differently depending on the value of some unique Lua
> global variable.
> 
> Regards,
>     John
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> 


i would recommend either using threads (not so compatible) or a coroutine
dispatcher and then hook/insert plugin loops/functions to that.( examples in the
lua manual).

a partial event updating trick (no coroutines or threads) can be seen in luacalc
(sourceforge),
 a resize(sizer) event updates (triggers) a Scalable paint window.
 (*this resize could be replaced by network events or gui button presses etc)

I hope this information is helpful.

Kai.

As a great fan of lua ( and wx of course ), i joined a wxlua based project.

It's called luacalc and is hosted on sourceforge.

*atm the *BETA* version is located in svn/experiment.(will be solved)
  the BETA is the version to download.

Basically luacalc is an interface between a (excel alike) sheet and wx.
 it has:
  - a GUI completely based on sizers.
  - realtime data update (the sheet itself is a lua progam)
  - basic graphics like a resizable line graph.(realtime too)
  - atm no good csv support but it can load *some* csv.
    *(loads/saves own lua tables)
  - loads directly under wxlua editor (as dll, windows only,rest is untested)
  - Example sheets like graphics,timezones,system,font properties.
   *these reside in the main svn folder under grids, !! use the .lsv NOT .csv !!

*reminder: because lua uses : for objects and csv : for ranges
 use the pipe | like A1|B6 to select range A1 to B6 (returns a table)
  A1:create() is possible this way.

Try it,any suggestions are welcome.(even negative as long as they can be used in
a positive way).

I would be very honoured if the wxlua site would reference to us (a bit of
advertising never hurts), or any other kind of cooperation.

Luacalc itself is a good demonstration of several wx parts interfaced together,
so if you want to learn about wx workings it seems a good source (to me).
 ( whether the code is optimal stays a point of discussion )
 
Thank you for your time.

The Luacalc dev team.

04/18/08

Hi,

I'm looking into using wxLua in a project (have previously used vanilla
lua), but I'm experiencing a bit of a problem.

I am using the latest windows binaries from the wxLua site, I have
generated a simple import library for wx.dll by providing the luaopen_wx
export.

I call the luaopen_wx function in the same manner that the other lua
libraries are opened (basically a copy of the luaL_openlibs function),
and wxLua is loading and I can quite happily use it, a call to
wx.wxMessageBox promptly opens a messagebox.

My simple test case simply does a lua_open, lua_openlibs (including wx),
lua_close.  It doesn't actually execute any lua code.  When the host
program exits, wx.dll tries to access the lua_state variable (which was
closed long before) and ends up accessing an invalid pointer, and
crashes.  It appears to be when wx.dll is unloaded.

I'm using Visual Studio 2008 and I'm using wxLua to provide a scripting
language with cross platform UI capabilities, the host application is
not a wxWidgets application.

What exactly am I doing wrong?!  How do I prevent this crash in wx.dll
from occuring?

Apart from the crash when the host application exits, it's working
perfectly!  So it's a little bit frustrating.

Thanks.

Adrian

Hi,

I'm looking into using wxLua in a project (have previously used vanilla
lua), but I'm experiencing a bit of a problem.

I am using the latest windows binaries from the wxLua site, I have
generated a simple import library for wx.dll by providing the luaopen_wx
export.

I call the luaopen_wx function in the same manner that the other lua
libraries are opened (basically a copy of the luaL_openlibs function),
and wxLua is loading and I can quite happily use it, a call to
wx.wxMessageBox promptly opens a messagebox.

My simple test case simply does a lua_open, lua_openlibs (including wx),
lua_close.  It doesn't actually execute any lua code.  When the host
program exits, wx.dll tries to access the lua_state variable (which was
closed long before) and ends up accessing an invalid pointer, and
crashes.  It appears to be when wx.dll is unloaded.

I'm using Visual Studio 2008 and I'm using wxLua to provide a scripting
language with cross platform UI capabilities, the host application is
not a wxWidgets application.

What exactly am I doing wrong?!  How do I prevent this crash in wx.dll
from occuring?

Apart from the crash when the host application exits, it's working
perfectly!  So it's a little bit frustrating.

Thanks.

Adrian

On Tue, Apr 8, 2008 at 10:49 AM, Ryan Pusztai <rpu...@gm...> wrote:
>
> On Mon, Apr 7, 2008 at 11:38 PM, John Labenski <jla...@gm...> wrote:
> > Try to explain your problems. You are right that, currently we do not
> > have a build to create a single monolithic wx.dll as I am not sure how
> > to persuade Bakefile to generate something like that (at least not
> > yet, but I do see the advantage of having that build so I will work on
> > it).
>
> Another problem is using the default build files fail for me. It is the
> OpenGL libraries that fail. Now you and I have talked a few times about this
> and it just doesn't work for me. So I have actually created my own set of
> build files that work exactly as I need (plus they include OpenGL too so I
> don't know what is going wrong), except I am linking against the wxWidgets

I thought we fixed the OpenGL problem for the monolithic build? I see
that it is handled correctly in the apps/build/msvc6/*.dsp files. The
problem is the OpenGL lib is not put into the monolithic lib by
wxWidgets.

> dll as a monolithic target. I build with MinGW and not VC and I think this
> is part of the reason the current build files don't work. I would rather
> just have one dll instead, but having 4 dlls is OK for me right now.
>
> I am using Premake for this task and I just "plug" it in to the wxLua source
> tree under the build directory and it works great. If I could get a few
> ideas on what actually needed to be done to link a wx.dll as a single dll I
> could probably add this to my solution. This could maybe help others as well
> (including yourself ;) ) I could help you with how I set it up. I don't know
> if they are ready for every bodies eyes just yet, but they are very close.

I would try to build wxWidgets and wxLua staticly then link wx.dll to
all those libs. I think it should work, but you may get a ton of
warnings about not exporting any function other than luaopen_wx(), but
they are harmless.

> They give you build files for all of VC 6-2005, Code::Blocks, and GNU make
> files.

The GNU makefiles should work already, but the Code::Blocks ones would
be nice. Someone else provided some, but I had then renamed all the
files to handle breaking the bindings up by the wxWidgets libs and
forgot to ask for them again.

Regards,
    John

On Tue, Apr 8, 2008 at 6:01 AM, andre arpin <ar...@ki...> wrote:
> John Labenski <jlabenski@...> writes:
>
>  I agree it is just that wxLuaFreeze would have had to create a new program so
>  I use the name lux.

Ok I see, you want the equivalent of wxLuaFreeze, but using the wx.dll
instead os staticly linking to the rest of wxLua.

>  Yes what I like to have is Lua with wx.dll.
>  I can compile wx.dll using the library specified by wxlua.
>  It works for most programs, so it is probably the right libraries.
>  When it fail it is because of an addressing error.
>  I have try to narrow the problem down.
>  binding fail when you open a folder.
>  editor when you open a 3 th file.
>  One of my own program fail when I try to open a file.
>
>  The all seem to be memory related. I do not undestand LUA enough to be able to
>  find the exact cause of the problem. It is usable but not really stable.

I think you have a misconfigured build, try to clean it *all* and
rebuild and take note of any warnings. Do you have any of the problems
with the binaries at sourceforge?

>  Why using the name wx.dll. Wouldn't wxlua.dll more appropriate. One could
>  imagine wxlua.dll being used with the regular wx.dll then the name would not
>  conflict. Maybe I am confused.

I don't think anyone else makes a wx.dll? Do they? We use wx.dll for
historical reasons, though it would make sense to call it wxlua.dll to
make it play nicely in a system lib dir.

Regards,
    John

On Tue, Apr 8, 2008 at 12:49 PM, andre arpin <ar...@ki...> wrote:
> John Labenski <jlabenski@...> writes:
>
>  > Can you reproduce it my running from the command line and pressing
>  > Ctrl+C or killing the process? I haven't been able to, but I will try
>  > doing the logoff thing tomorrow.
>
>  Only happen on log off or shut down (where I found the problem initially).

I don't have the foggiest idea why it only happens when you log out
since killing it should do the same thing. Cygwin lets you send
various kill signals, but none of them does what logging off does.

However the fix is fairly easy and it does make sense. When Lua
garbage collects or you call :delete() on a userdata object, wxLua
nulls the metatable so that an error is generated rather than
crashing. This should be completely invisible to people for garbage
collection since it won't be garbage collected if you have a variable
pointing to it, but it is useful for :delete().

wxLua tries to explicitly delete the wxWindows (the wxFrame) before
anything else when shutting down to try to ensure that it exits
gracefully. I wonder if logging out of MSW causes the event loop to be
suspended and that is why the config is somehow garbage collected
before the wxFrame is deleted?

Here's a fix.

function CloseWindow(event)
...
    if config and getmetatable(config) then
        ConfigSaveFramePosition(frame, "MainFrame")
        config:delete() -- always delete the config
    end


Regards,
    John

John Labenski <jlabenski@...> writes:

> Can you reproduce it my running from the command line and pressing
> Ctrl+C or killing the process? I haven't been able to, but I will try
> doing the logoff thing tomorrow.
> 

Only happen on log off or shut down (where I found the problem initially).

Andre

On Mon, Apr 7, 2008 at 11:38 PM, John Labenski <jla...@gm...> wrote:

> Try to explain your problems. You are right that, currently we do not
> have a build to create a single monolithic wx.dll as I am not sure how
> to persuade Bakefile to generate something like that (at least not
> yet, but I do see the advantage of having that build so I will work on
> it).
>
> Regards,
>    John
>

OK I will try to explain what I am doing. I made an application at work that
wraps our (Works) shared library. In this library I added many things to
vanilla Lua interpreter and it makes other, non-programmers be able to write
tests and applications without bothering a Software Engineer. Now as the
project when on I was asked to support GUI from my application. This
prompted me to use wxLua as a Lua module, because:
  1. Not all people/scripts need a GUI.
  2. wxLua already exists and is really good once built.
  3. Re-use of other common libraries without re-building my application
would be MUCH easier
      to maintain.

So the real problem is deployment of my application. Once the wxLua module
is used I need to include 8+ dlls along with my application. Now that sounds
OK for you or me, but my goal it to have these scripts be easy enough to
deploy that our customers can use these scripts. They can't be expected to
know anything about how to get this to work. Also the skill level for the
"non-programmers" is not high enough to also create an installer for all the
scripts they write, so that they can deploy them to other people. So in this
case I see a benefit to wxLuaFreeze, but I can't make "my" additions to Lua
as a Lua module at this point because it would be too much work and time.
And wxLua already supports wx as a Lua module.

Another problem is using the default build files fail for me. It is the
OpenGL libraries that fail. Now you and I have talked a few times about this
and it just doesn't work for me. So I have actually created my own set of
build files that work exactly as I need (plus they include OpenGL too so I
don't know what is going wrong), except I am linking against the wxWidgets
dll as a monolithic target. I build with MinGW and not VC and I think this
is part of the reason the current build files don't work. I would rather
just have one dll instead, but having 4 dlls is OK for me right now.

I am using Premake for this task and I just "plug" it in to the wxLua source
tree under the build directory and it works great. If I could get a few
ideas on what actually needed to be done to link a wx.dll as a single dll I
could probably add this to my solution. This could maybe help others as well
(including yourself ;) ) I could help you with how I set it up. I don't know
if they are ready for every bodies eyes just yet, but they are very close.
They give you build files for all of VC 6-2005, Code::Blocks, and GNU make
files.

Hope this helps explain my wxLua use.
-- 
Regards,
Ryan

debug.trace does not seems to work when using wx.dll. 

Andre

Here is a simpler test.

Start the editor and create 3 new documents.

It fail for me.

Andre

John Labenski <jlabenski@...> writes:

> Look at the samples and you'll see that the wx.dll module is always
> "required", but of course if you're running the wxLuaFreeze executable
> it is already loaded so require "wx" does nothing.
> 
> So, I don't think we need a new program lux.exe, since lua.exe does
> exactly the above.
> 
> Bottom line, wxLua and wxLuaFreeze are linked to the equivalent to
> wx.dll and automatically load it into Lua.
> 

I agree it is just that wxLuaFreeze would have had to create a new program so 
I use the name lux.

Yes what I like to have is Lua with wx.dll. 
I can compile wx.dll using the library specified by wxlua.
It works for most programs, so it is probably the right libraries.
When it fail it is because of an addressing error.
I have try to narrow the problem down.
binding fail when you open a folder.
editor when you open a 3 th file.
One of my own program fail when I try to open a file.

The all seem to be memory related. I do not undestand LUA enough to be able to 
find the exact cause of the problem. It is usable but not really stable.

Why using the name wx.dll. Wouldn't wxlua.dll more appropriate. One could 
imagine wxlua.dll being used with the regular wx.dll then the name would not 
conflict. Maybe I am confused.

Andre

On Wed, Apr 2, 2008 at 2:51 PM, Ryan Pusztai <rpu...@gm...> wrote:
> On Wed, Apr 2, 2008 at 12:57 AM, John Labenski <jla...@gm...> wrote:
>
> > On the other hand, why not just use a staticly built wxLuaFreeze as
> > your Lua executable? It is the minimal version of a wxLua program and
> > can run any Lua program that lua.exe can. Is there any reason to want
> > to dynamically load wx.dll?
>
> I have created my own custom application that uses the Lua module loading
> mechanism, so it is very useful in this case. Also in this case wxLuaFreeze
> is not good enough to run my code written for my custom application. One of
> the beautiful things about Lua is this idea of "plug-ins" / modules. This

Ok, yes it does make sense to use the shared lib if you're going to
have multiple programs running.

> has been quite a pain for me to get working, or even build wxLua using your
> shipped build files. I need a single dll or the same monolithic static
> library. Do you have any help is this case?

Try to explain your problems. You are right that, currently we do not
have a build to create a single monolithic wx.dll as I am not sure how
to persuade Bakefile to generate something like that (at least not
yet, but I do see the advantage of having that build so I will work on
it).

Regards,
    John

On Thu, Apr 3, 2008 at 10:20 AM, andre arpin <ar...@ki...> wrote:
>  >
>
>  What I would like is to be able to do is to replace lua.exe by lux.exe.
>
>  lux X.lua which is a normal lua program run normally
>  lux W.lua which uses wx.dll runs the same way as wxlua W.lua
>
>  How would you configure wxLuaFreeze to do just that?

Look at the samples and you'll see that the wx.dll module is always
"required", but of course if you're running the wxLuaFreeze executable
it is already loaded so require "wx" does nothing.

So, I don't think we need a new program lux.exe, since lua.exe does
exactly the above.

Bottom line, wxLua and wxLuaFreeze are linked to the equivalent to
wx.dll and automatically load it into Lua.

Regards,
    John

On Thu, Apr 3, 2008 at 10:08 AM, andre arpin <ar...@ki...> wrote:
> problem:
>  wxlua editor.wx.lua
>
>  logoff

Do you mean logoff as in log out the current user of MSWindows?

>  an error occur when config:delete is executed. The error message is misleading
>  but removing this line clear the problem.

What is the message and what platform?

>  config may already be deleted at this point
>
>  If it is kept it should probably be conditionnal but I could not find any
>  usable state information that could be used.
>
>  remove
>     config:delete() -- always delete the config
>  at line 2333

The config should not be deleted since the frame is sending the
wxEVT_CLOSE_WINDOW event which should be sent before Lua will garbage
collect anything.

Can you reproduce it my running from the command line and pressing
Ctrl+C or killing the process? I haven't been able to, but I will try
doing the logoff thing tomorrow.

Regards,
    John

On Wed, Apr 2, 2008 at 1:05 PM,  <ah...@ar...> wrote:
> Hi!
>
>  I cannot open a print preview window on the mac using the version
>  2.8.7.0 of wxLua. It works fine in version 2.8.4.1. When calling
>  wxPreviewFrame:Show(true) I get the error "Could not start document
>  preview". A quick googling revealed that people using wxPython also
>  have had similar problems. Could it be a bug in wxWidgets? I could not
>  find any info about this on the wxWidgets page.
>
>  Ideas?
>

Sorry no, it doesn't look like the BUG has been closed in wxWidgets yet.

http://sourceforge.net/tracker/index.php?func=detail&aid=1845194&group_id=9863&atid=109863

I assume that they will want to fix it before the next release however.

Regards,
    John

Ryan Pusztai <rpusztai@...> writes:

> 
> 
> On Wed, Apr 2, 2008 at 12:57 AM, John Labenski <jlabenski-
Re5...@pu...> wrote:
> On the other hand, why not just use a staticly built wxLuaFreeze as
> your Lua executable? It is the minimal version of a wxLua program and
> can run any Lua program that lua.exe can. Is there any reason to want
> to dynamically load wx.dll?
> 


What I would like is to be able to do is to replace lua.exe by lux.exe.

lux X.lua which is a normal lua program run normally
lux W.lua which uses wx.dll runs the same way as wxlua W.lua

How would you configure wxLuaFreeze to do just that?

Andre

problem:
wxlua editor.wx.lua

logoff 

an error occur when config:delete is executed. The error message is misleading 
but removing this line clear the problem.

config may already be deleted at this point 

If it is kept it should probably be conditionnal but I could not find any 
usable state information that could be used.

remove 
    config:delete() -- always delete the config
at line 2333

Andre

On Wed, Apr 2, 2008 at 12:57 AM, John Labenski <jla...@gm...> wrote:

> On the other hand, why not just use a staticly built wxLuaFreeze as
> your Lua executable? It is the minimal version of a wxLua program and
> can run any Lua program that lua.exe can. Is there any reason to want
> to dynamically load wx.dll?


I have created my own custom application that uses the Lua module loading
mechanism, so it is very useful in this case. Also in this case wxLuaFreeze
is not good enough to run my code written for my custom application. One of
the beautiful things about Lua is this idea of "plug-ins" / modules. This
has been quite a pain for me to get working, or even build wxLua using your
shipped build files. I need a single dll or the same monolithic static
library. Do you have any help is this case?
-- 
Regards,
Ryan

Hi!

I cannot open a print preview window on the mac using the version  
2.8.7.0 of wxLua. It works fine in version 2.8.4.1. When calling  
wxPreviewFrame:Show(true) I get the error "Could not start document  
preview". A quick googling revealed that people using wxPython also  
have had similar problems. Could it be a bug in wxWidgets? I could not  
find any info about this on the wxWidgets page.

Ideas?

//Sebastian Ahlman

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

> 
> So... in order to get the single wx.dll, I think we need to build
> static libs for everything (wxWidgets and wxLua) and then link the
> wx.dll to them. I suppose that this could work; however we use
> bakefile to generate the build files and I am not sure that you can
> specify that all the other libs are static, but the lib we build is
> dynamic. I can look into it, but I don't have high hopes.
> 
> On the other hand, why not just use a staticly built wxLuaFreeze as
> your Lua executable? It is the minimal version of a wxLua program and
> can run any Lua program that lua.exe can. Is there any reason to want
> to dynamically load wx.dll?
> 

If you decide to write a number of scripts using wxlua it would be nice if you 
could use a single dll and a large number of small script file. 

I do not care which mode we compile mono, multilib, etc. Any one would do.

Andre

I should note that I get a quite a few warnings, but I'm not sure how
to fix or appropriately silence them. They're typically "pointer
truncation from 'void *' to 'long'"  or the other way around.

I haven't gone though them all. but for the most part they're for
wxWidgets functions that take or return a void* pointer, but are used
in wxLua to allow Lua programs to store an integer (perhaps an index
into a table with extra data) for convenience.

Regards,
    John


On Wed, Apr 2, 2008 at 12:57 AM, John Labenski <jla...@gm...> wrote:
> On Tue, Apr 1, 2008 at 12:13 PM, andre arpin <ar...@ki...> wrote:
>  > >
>  >  > I don't use VC2005, I use VC6, but this doesn't seem right. The wxLua
>  >  > module is uses DLLs from the other libs. If you want to link against
>  >  > the other libs (not the DLLs) you should use the monolithic build
>  >  > which will generate a single wx.dll that only depends on the wxWidgets
>  >  > DLLs.
>  >  >
>  >  > I can try w/ VC2008 tomorrow.
>  >
>  >  I seems to have the same problems with vc2008.
>  >  It seems to me that if wx.dll was compiled using multilib then only wx.dll
>  >  would be necessary to use wxlua facilities which would be great. No worry
>  >  about having dll's out of sync.
>
>  The multilib DLL debug compiles and runs ok w/ 2008, aka VC 9, for me.
>  I had to rem out the call in the wxlua adv lib for
>  wxGridCellWorker::GetRef() however. I added it recently to debug some
>  wxGrid problems, however I use a #define hack to add the function
>  which works for static libs, but not for DLLs. I will remove it later.
>
>  modules/wxbind/src/wxadv_bind.cpp
>     int returns = 0; //(self->GetRef());
>
>  Additionally, I had to edit msw/setup.h and set this to get the gl dll built.
>  #define wxUSE_GLCANVAS       1
>
>  ------------------------------
>
>  So... in order to get the single wx.dll, I think we need to build
>  static libs for everything (wxWidgets and wxLua) and then link the
>  wx.dll to them. I suppose that this could work; however we use
>  bakefile to generate the build files and I am not sure that you can
>  specify that all the other libs are static, but the lib we build is
>  dynamic. I can look into it, but I don't have high hopes.
>
>  On the other hand, why not just use a staticly built wxLuaFreeze as
>  your Lua executable? It is the minimal version of a wxLua program and
>  can run any Lua program that lua.exe can. Is there any reason to want
>  to dynamically load wx.dll?
>
>  Regards,
>     John
>