wxlua-users Mailing List for wxLua

wx.dll is mostly working and is very useful using window xp Visual Studio 2005.
I have encounter the following problem.
Index value to variables in _G may not be available ( maybe only within event )
Reproducing the problem
create wx.dll
run:
 lua editor.wx.lua auidemo.wx.lua bindings.wx.lua calculator.wx.lua
at line 397 attempt to index a field '?' (a nil value)
the line is 
 local pageText = openDocuments[id].fileName or "untitled.lua"
the index 'id' in openDocuments has vanish
---------------------------- Testing
add
 wx.wxMessageBox(type(openDocuments[id]), tostring(id), wx.wxOK, frame)
 wx.wxMessageBox(type(openDocuments[100]), tostring(100), wx.wxOK, frame)
just before the line
 local pageText = openDocuments[id].fileName or "untitled.lua"
run the same test.
notice that when id 102 is used that both 
openDocuments[id] is nil the expected problem and also
openDocuments[100] is nil we know that is not true.
If you keep tracing then openDocuments[102] reappears.
NOTE:
I have a dump program which shows that openDocuments has the index 100, 101 
and 102 when it is not found. (dumping _G)
-------------------------------- More info
I have also encounter some memory error in lua while usin wx.dll but this is 
probably related. I will try to narrow the problem but I am not very familiar 
with the code. 
Thanks for all your work.
Andre

Hello,
I've started writing a program using wxLua.
It's a great tool, and I use it with pleasure!
But.. I've found that some methods from wxWidgets are
unavailable in wxLua (and not documented as such):
e.g..
wxFileName::RemoveLastDir()
wxFileName::GetPathWithSep(wxPathFormat format = wxPATH_NATIVE)
or
wxMenuItem::SetItemLabel(const wxString& label) -- available is only 
::SetText which is marked
 in wxWidgets documentation as deprecated.
Are wxLua bindings synchronized with wxWidgets in any automatic way?
What is best way to report such remarks? Did you prefer just such
email, or diff on a *.i files?
Best Regards
PiotrS.
-- 
Piotr Strzelczyk
Sopot, Poland
e-mail: pi...@ep...; skype: piotrstrz

Is there a way to statically link wxLua (with luamodule) to a project? I am using mingw.
- Greg
_________________________________________________________________
Sympatico/MSN Autos wants to put YOU in a 2008 Eclipse! Click here to enter!
http://g.msn.ca/ca55/212 

andre arpin <arpin@...> writes:
Should have mentionned that this applies to mod_luamodule
mod_luamodule_mono does not compile in VS2005 as well maybe related I do nnot 
know.
Andre

The compile fail. The following changes create a usable dll.
Change where made within VS2005 but should apply to other version
change:
C++
(preprocessor)
WXUSINGDLL to WXMAKINGDLL_BINDWXADV 
LINKER
(general)
(additional library directories)
change all the vc_dll to vc_lib
(input)
(additional dependencies)
replace all the libraries by the one from the app_wxlua project in the 
debug multilib unicode configuration.
--------> 
This configuration is create like it was using a DLL instead of creating one.
I understand that the changes cannot be done where I pointed then out, but 
this hopefully demonstrate what is the problem.
Andre

On Wed, Mar 26, 2008 at 6:58 AM, John Labenski <jla...@gm...> wrote:
> On Sat, Mar 8, 2008 at 5:28 AM, Eero Pajarre <epa...@gm...> wrote:
> > Actually after looking more at the code, I think that doing a
> > IncRef in Set operations is the better way, instead of this ungc-change.
> ...
>
> > As a related note, I think that the target should be, that IncRef/DecRef are
> > not be part of wxLua Lua-API. Incorrectly using DecRef will lead to program
> > crash, and I would rather have a "crash-proof-API".
>
> I think this could work... so long as it's done in all the right
> places, but we have to also make sure that we have removed them all
> from Lua before the grid is deleted because the m_control member of
> the editors will not be NULLed and the wxGridCellEditor will try to
> delete it again. This is apparently has not been a problem in C++
> since people either do not keep the editors around or they are members
> of their own wxGrids and are deleted before the grid itself is
> deleted.
>
Cannot help feeling that this is getting ugly...
(Should this be taken to the wxWidgets people? the
fact that an editor tries to destroy its owner feels backward)
The other alternative I considered would be letting wxGrid adopt the
editors etc by "killing" the lua variable for the editor or attribute
at the point
when it is given to the attribute or grid to own.
This approach also has its problems. (like the "global editors"
wxGridCellBoolEditor() etc)
 Eero

Thanks, both fixed in CVS.
-John
On Thu, Mar 20, 2008 at 5:09 PM, andre arpin <ar...@ki...> wrote:
> wxldtarg.cpp
> note change < and > to () so it does not look like top posting
> This is a critical change:
>
> the buffer size is modified by wx2lua
> so buf.length() does not reflect the right size.
> compile may fail
> 134c134,135
> ( int rc = m_wxlState.LuaDoBuffer(wx2lua(buf), buf.Length(),
> ---
> ) wxLuaCharBuffer buffer(buf);
> ) int rc = m_wxlState.LuaDoBuffer(buffer, buffer.Length(),
> -------------------------------------------------------------------------
>
> wxluasocket_bind.cpp
> Minor change:
> This does not cause any problem
> file and filename are interchanged (just odd when you read the code)
> 238c238
> ( const wxString fileName = wxlua_getwxStringtype(L, 3);
> ---
> ) const wxString file = wxlua_getwxStringtype(L, 3);
> 240c240
> ( const wxString file = wxlua_getwxStringtype(L, 2);
> ---
> ( const wxString fileName = wxlua_getwxStringtype(L, 2);
> 244c244
> ( bool returns = (self->Run(file, fileName));
> ---
> ) bool returns = (self->Run(fileName, file));
>
> Andre
>
>
> -------------------------------------------------------------------------
> 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/
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>

On Sat, Mar 8, 2008 at 5:28 AM, Eero Pajarre <epa...@gm...> wrote:
> On Fri, Mar 7, 2008 at 7:00 PM, Eero Pajarre <epa...@gm...> wrote:
> > On Fri, Mar 7, 2008 at 6:45 PM, John Labenski <jla...@gm...> wrote:
> >
> > > After looking into it a little more, I think the best solution is to
> > > use the %ungc tag in the interface file so that we have:
> > > wxGrid::SetCellEditor(int row, int col, %ungc wxGridCellEditor *editor)
> > > This means that Lua will not try to delete the editor and it's up to
> > > the wxGrid (actually wxGridCellAttr) to delete it by calling DecRef().
> >
> > This sounds correct to me (based on wxwidgets code)
>
> Actually after looking more at the code, I think that doing a
> IncRef in Set operations is the better way, instead of this ungc-change.
...
> As a related note, I think that the target should be, that IncRef/DecRef are
> not be part of wxLua Lua-API. Incorrectly using DecRef will lead to program
> crash, and I would rather have a "crash-proof-API".
I think this could work... so long as it's done in all the right
places, but we have to also make sure that we have removed them all
from Lua before the grid is deleted because the m_control member of
the editors will not be NULLed and the wxGridCellEditor will try to
delete it again. This is apparently has not been a problem in C++
since people either do not keep the editors around or they are members
of their own wxGrids and are deleted before the grid itself is
deleted.
>From my debugging I found that when the grid is destroyed we need to
have cleared all references in wxLua to renderers, editors, and
attributes by settings them to nil and running the garbage collector
or calling (ren:delete() to force it to be deleted immediately).
Simply calling IncRef() isn't enough, we have to make sure that we've
removed them from Lua and there is no way to detect the deletion in
any reasonable way with the given C++ api.
rend = wx.wxGridCellBoolRenderer()
rend:IncRef() -- could hide this in SetCellRenderer()
grid:SetCellRenderer(0, 1, rend)
rend = nil
edit = wx.wxGridCellBoolEditor()
edit:IncRef() -- could hide this in SetCellEditor()
grid:SetCellEditor(0, 1, edit)
edit = nil
collectgarbage("collect")
======================
ohhh, I may have found a found a way. It's ugly...
We can get at the m_control of the wxGridCellEditor class and NULL it this way.
#define wxGridCellEditorDummyFriend \
public: \
void NullControl() { m_control = NULL; }
When Lua wants to delete the wxGridCellEditor we catch it, search the
wxWindows (may be a slow process) for the pointer to the m_control, if
it's gone we call the above function to NULL it and DecRef() the
editor normally to delete it.
If the above works as planned then yes, we can simply do as you say
and call IncRef() from within any function that takes a
wxGridCellWorker derived class and requires IncRef() and it should all
work.
I will test the hack above in the next few days.
Regards,
 John

On Tue, Mar 25, 2008 at 7:35 AM, Eero Pajarre <epa...@gm...> wrote:
> > >>
> > >> WXDLLIMPEXP_WXLUA wxString lua2wx(const char* luastr)
> > >> {
> > >> return wxString(luastr, *wxConvCurrent);
> > >> }
> > >>
> > >> const WXDLLIMPEXP_WXLUA wxCharBuffer wx2lua(const wxString& wxstr)
> > >> {
> > >> wxCharBuffer buffer(wxstr.mb_str(*wxConvCurrent));
> > >> return buffer;
> > >> }
> > >>
>
> I also noticed that I need this patch so that my (WindowsXP
> non-unicode-wxWidgets)
> system does not change iso-latin strings when they go through
> wxTextCtrl:SetValue - GetValue
> pair.
>
> Shouldn't this change be in CVS already? :-)
>
> (Doesn't seem to be there)
Thanks for reminding me, I had completely forgotten about it. In CVS now.
Regards,
 John

You're right, thanks. Fixed in CVS.
Regards,
 John
On Sun, Mar 23, 2008 at 2:46 PM, andre arpin <ar...@ki...> wrote:
> please change
> case wxLUASOCKET_DEBUGGER_CMD_DEBUG_CONTINUE
> in bool wxLuaDebugTarget::HandleDebuggerCmd(int debugCommand)
>
> from:
> case wxLUASOCKET_DEBUGGER_CMD_DEBUG_CONTINUE:
> {
> ret = Continue();
> break;
> }
>
> case wxLUASOCKET_DEBUGGER_CMD_DEBUG_CONTINUE:
> {
> m_forceBreak =false;
> ret = Continue();
> break;
> }
>
> thank you
>
> Andre
>
>
> -------------------------------------------------------------------------
> 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/
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>

On Thu, Mar 20, 2008 at 12:43 PM, Eero Pajarre <epa...@gm...> wrote:
> Today I noticed that I would have liked to use wxTextCtrl:ChangeValue
> (It differs from SetValue, because it does not generate events
> when it changes the value)
>
> The function seems to be added on wxWidgets 2.7.1, so it is not
> that odd that it is not included yet.
>
Thanks, added to CVS.
Regards,
 John

Thanks for reporting this, fixed in CVS.
Regards,
 John
On Mon, Mar 17, 2008 at 9:58 AM, andre arpin <ar...@ki...> wrote:
>
> file wxlua_bind.cpp line 1043
>
> static int LUACALL wxLua_function_ungcobject(lua_State *L)
> {
> bool ret = false;
> if (wxluaO_isgcobject(L, 1))
> {
> ret = wxluaO_undeletegcobject(L, 1);
> }
>
> lua_pushboolean(L, ret);
> return 1;
> }
>
>
> the second argument for
>
> wxluaO_isgcobject and
> wxluaO_undeletegcobject
>
> should be cast to a (void *)
>
> Andre
>
>
> -------------------------------------------------------------------------
> 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/
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>

> >>
> >> WXDLLIMPEXP_WXLUA wxString lua2wx(const char* luastr)
> >> {
> >> return wxString(luastr, *wxConvCurrent);
> >> }
> >>
> >> const WXDLLIMPEXP_WXLUA wxCharBuffer wx2lua(const wxString& wxstr)
> >> {
> >> wxCharBuffer buffer(wxstr.mb_str(*wxConvCurrent));
> >> return buffer;
> >> }
> >>
I also noticed that I need this patch so that my (WindowsXP
non-unicode-wxWidgets)
system does not change iso-latin strings when they go through
wxTextCtrl:SetValue - GetValue
pair.
Shouldn't this change be in CVS already? :-)
(Doesn't seem to be there)
 Eero

please change
 case wxLUASOCKET_DEBUGGER_CMD_DEBUG_CONTINUE
in bool wxLuaDebugTarget::HandleDebuggerCmd(int debugCommand)
from:
 case wxLUASOCKET_DEBUGGER_CMD_DEBUG_CONTINUE:
 {
 ret = Continue();
 break;
 }
 case wxLUASOCKET_DEBUGGER_CMD_DEBUG_CONTINUE:
 {
 m_forceBreak =false;
 ret = Continue();
 break;
 }
thank you 
Andre

wxldtarg.cpp
note change < and > to () so it does not look like top posting
This is a critical change:
the buffer size is modified by wx2lua
so buf.length() does not reflect the right size.
compile may fail
134c134,135
 ( int rc = m_wxlState.LuaDoBuffer(wx2lua(buf), buf.Length(),
 ---
 ) 				wxLuaCharBuffer buffer(buf);
 ) int rc = m_wxlState.LuaDoBuffer(buffer, buffer.Length(),
-------------------------------------------------------------------------
wxluasocket_bind.cpp
Minor change:
This does not cause any problem 
file and filename are interchanged (just odd when you read the code) 
238c238
 ( const wxString fileName = wxlua_getwxStringtype(L, 3);
 ---
 ) const wxString file = wxlua_getwxStringtype(L, 3);
240c240
 ( const wxString file = wxlua_getwxStringtype(L, 2);
 ---
 ( const wxString fileName = wxlua_getwxStringtype(L, 2);
244c244
 ( bool returns = (self->Run(file, fileName));
 ---
 ) bool returns = (self->Run(fileName, file));
Andre

Today I noticed that I would have liked to use wxTextCtrl:ChangeValue
(It differs from SetValue, because it does not generate events
when it changes the value)
The function seems to be added on wxWidgets 2.7.1, so it is not
that odd that it is not included yet.
(The function was not SO important to me that I would have modified
the sources myself....)
 Eero

file wxlua_bind.cpp line 1043
static int LUACALL wxLua_function_ungcobject(lua_State *L)
{
 bool ret = false;
 if (wxluaO_isgcobject(L, 1))
 {
 ret = wxluaO_undeletegcobject(L, 1);
 }
 lua_pushboolean(L, ret);
 return 1;
}
the second argument for 
wxluaO_isgcobject and
wxluaO_undeletegcobject
should be cast to a (void *)
Andre

On Fri, Mar 7, 2008 at 7:00 PM, Eero Pajarre <epa...@gm...> wrote:
> On Fri, Mar 7, 2008 at 6:45 PM, John Labenski <jla...@gm...> wrote:
>
> > After looking into it a little more, I think the best solution is to
> > use the %ungc tag in the interface file so that we have:
> > wxGrid::SetCellEditor(int row, int col, %ungc wxGridCellEditor *editor)
> > This means that Lua will not try to delete the editor and it's up to
> > the wxGrid (actually wxGridCellAttr) to delete it by calling DecRef().
>
> This sounds correct to me (based on wxwidgets code)
>
Actually after looking more at the code, I think that doing a
IncRef in Set operations is the better way, instead of this ungc-change.
The problem is that if the same Editor or CellAttr is used multiple times
it will lead program touching already deleted memory. The wxGrid will try to
do a DecRef for each usage, which is not good.
In C++ code I assume this is avoided by using IncRef in application code,
or by not reusing CellAttr/Editor.
As a related note, I think that the target should be, that IncRef/DecRef are
not be part of wxLua Lua-API. Incorrectly using DecRef will lead to program
crash, and I would rather have a "crash-proof-API".
 Eero

On Fri, Mar 7, 2008 at 6:45 PM, John Labenski <jla...@gm...> wrote:
> After looking into it a little more, I think the best solution is to
> use the %ungc tag in the interface file so that we have:
> wxGrid::SetCellEditor(int row, int col, %ungc wxGridCellEditor *editor)
> This means that Lua will not try to delete the editor and it's up to
> the wxGrid (actually wxGridCellAttr) to delete it by calling DecRef().
This sounds correct to me (based on wxwidgets code)
> You can retrieve it using :
> wxGridCellEditor* GetCellEditor(int row, int col)
> and the returned wxGridCellEditor will not be garbage collected by Lua.
>
Here I disagree, It looks to me that GetCellEditor does
do a IncRef before returning the editor pointer, so I think that wxLua should
DecRef it when it is done.

On Fri, Mar 7, 2008 at 9:32 AM, Eero Pajarre <epa...@gm...> wrote:
> > I got rid of the previous crash, but still there is something causing
> > memory corruption according to the "free"-function with debugging
> > builds. My code calls Lua incremental GC during execution, so
> > I guess I maybe more sensitive for these, but this is of course
> > good so that the bugs don't stay hidden.
> >
>
> SetColAttr and related functions seem also be part of the problem,
> and IncRef makes the symptoms less, but these functions also
> contain a call to wxluaO_undeletegcobject so I guess I should need
> to understand more of wxLua internals...
Heh, hopefully it won't be too difficult.
> Also using IncRef here is propably not ok in case the same Attribute
> set is used on multiple colums/rows, although a minor memory leak
> is not the worst thing now.
>
> (I have been using IncRef so that the wxWidget object does
> not get destroyed when the Lua object is garbage collected, after the
> wxWidget-object has been given to
> the custody of some other object)
After looking into it a little more, I think the best solution is to
use the %ungc tag in the interface file so that we have:
wxGrid::SetCellEditor(int row, int col, %ungc wxGridCellEditor *editor)
This means that Lua will not try to delete the editor and it's up to
the wxGrid (actually wxGridCellAttr) to delete it by calling DecRef().
You can retrieve it using :
wxGridCellEditor* GetCellEditor(int row, int col)
and the returned wxGridCellEditor will not be garbage collected by Lua.
This is not perfectly ideal in that I would think this code should be
all you need.
edit = wx.wxGridCellBoolEditor(...) -- same for wxGridCellXXXRenderer
-- ref count for edit == 1
edit:IncRef()
-- ref count for edit == 2
grid:SetCellEditor(1,2,edit)
-- ref count for edit == 2
*** If you have the code below it works great, without it the program
crashes in the way I described before. When the wxGrid is destroyed,
it destroys the children windows including the m_control of the
wxGridCellEditor and then later Lua will delete the wxGridCellEditor
(which is completely valid since it has a ref count of 1), but the
m_control pointer is not NULL, but points to nothing since it was
deleted, and the wxGridCellEditor tries to delete it again.
edit = nil
collectgarbage("collect")
-- ref count for edit == 1 and the wxGrid will delete it
A vaguely similar scenario happens for Renderers and Attributes.
Regards,
 John

> I got rid of the previous crash, but still there is something causing
> memory corruption according to the "free"-function with debugging
> builds. My code calls Lua incremental GC during execution, so
> I guess I maybe more sensitive for these, but this is of course
> good so that the bugs don't stay hidden.
>
SetColAttr and related functions seem also be part of the problem,
and IncRef makes the symptoms less, but these functions also
contain a call to wxluaO_undeletegcobject so I guess I should need
to understand more of wxLua internals...
Also using IncRef here is propably not ok in case the same Attribute
set is used on multiple colums/rows, although a minor memory leak
is not the worst thing now.
(I have been using IncRef so that the wxWidget object does
not get destroyed when the Lua object is garbage collected, after the
wxWidget-object has been given to
the custody of some other object)

On Thu, Mar 6, 2008 at 9:28 PM, John Labenski <jla...@gm...> wrote:
> I found that if you do this it works, but there's obviously something
> wrong that needs to be fixed.
>
> rend = wx.wxGridCellBoolRenderer(...) -- same for wxGridCellXXXEditor
> rend:IncRef()
> rend:IncRef()
> grid:SetCellRenderer(1,2,rend)
>
I don't actually use setCellRenderer, but the same thing happens
with wxGridCellAttr and SetRenderer / SetEditor.
I have now added IncRef to wxadv_bind.cpp for these two
functions. I think this suits the wxWidgets documentation
which says that the GridCellAttr takes the object ownership
when these functions are called (well at least it says this for
SetRenderer)
I got rid of the previous crash, but still there is something causing
memory corruption according to the "free"-function with debugging
builds. My code calls Lua incremental GC during execution, so
I guess I maybe more sensitive for these, but this is of course
good so that the bugs don't stay hidden.
 Eero

I found that if you do this it works, but there's obviously something
wrong that needs to be fixed.
rend = wx.wxGridCellBoolRenderer(...) -- same for wxGridCellXXXEditor
rend:IncRef()
rend:IncRef()
grid:SetCellRenderer(1,2,rend)
Regards,
 John
On Thu, Mar 6, 2008 at 11:55 AM, Eero Pajarre <epa...@gm...> wrote:
> There is also some other kind of corruption, even if the grid
> is not destroyed.
>
> It might be related to the life time of the GridCellEditors or Renderers as
> those are created and destroyed quite often.
>
> Currently my grid ends up with bad CellRenderer:
> (no wxLua code on stack, but probably the renderer has been
> deleted earlier....)
>
> > t_console.exe!wxGrid::DrawCell(wxDC & dc={...}, const
> wxGridCellCoords & coords={...}) Line 7595 + 0x2d bytes C++
> t_console.exe!wxGrid::DrawGridCellArea(wxDC & dc={...}, const
> wxGridCellCoordsArray & cells={...}) Line 7516 C++
> t_console.exe!wxGridWindow::OnPaint(wxPaintEvent & __formal={...})
> Line 4015 C++
> t_console.exe!wxAppConsole::HandleEvent(wxEvtHandler *
> handler=0x014861f0, void (wxEvent &)* func=0x008445f0, wxEvent &
> event={...}) Line 321 C++
> t_console.exe!wxEvtHandler::ProcessEventIfMatches(const
> wxEventTableEntryBase & entry={...}, wxEvtHandler *
> handler=0x014861f0, wxEvent & event={...}) Line 1227 C++
> t_console.exe!wxEventHashTable::HandleEvent(wxEvent & event={...},
> wxEvtHandler * self=0x014861f0) Line 899 + 0x1c bytes C++
> t_console.exe!wxEvtHandler::ProcessEvent(wxEvent & event={...})
> Line 1287 + 0x1c bytes C++
> t_console.exe!wxWindow::HandlePaint() Line 4562 + 0x1c bytes C++
> t_console.exe!wxWindow::MSWWindowProc(unsigned int
> message=0x0000000f, unsigned int wParam=0x00000000,
>
>
>
> -------------------------------------------------------------------------
> 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/
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>

There is also some other kind of corruption, even if the grid
is not destroyed.
It might be related to the life time of the GridCellEditors or Renderers as
those are created and destroyed quite often.
Currently my grid ends up with bad CellRenderer:
(no wxLua code on stack, but probably the renderer has been
deleted earlier....)
>	t_console.exe!wxGrid::DrawCell(wxDC & dc={...}, const
wxGridCellCoords & coords={...}) Line 7595 + 0x2d bytes	C++
 	t_console.exe!wxGrid::DrawGridCellArea(wxDC & dc={...}, const
wxGridCellCoordsArray & cells={...}) Line 7516	C++
 	t_console.exe!wxGridWindow::OnPaint(wxPaintEvent & __formal={...})
Line 4015	C++
 	t_console.exe!wxAppConsole::HandleEvent(wxEvtHandler *
handler=0x014861f0, void (wxEvent &)* func=0x008445f0, wxEvent &
event={...}) Line 321	C++
 	t_console.exe!wxEvtHandler::ProcessEventIfMatches(const
wxEventTableEntryBase & entry={...}, wxEvtHandler *
handler=0x014861f0, wxEvent & event={...}) Line 1227	C++
 	t_console.exe!wxEventHashTable::HandleEvent(wxEvent & event={...},
wxEvtHandler * self=0x014861f0) Line 899 + 0x1c bytes	C++
 	t_console.exe!wxEvtHandler::ProcessEvent(wxEvent & event={...})
Line 1287 + 0x1c bytes	C++
 	t_console.exe!wxWindow::HandlePaint() Line 4562 + 0x1c bytes	C++
 	t_console.exe!wxWindow::MSWWindowProc(unsigned int
message=0x0000000f, unsigned int wParam=0x00000000,

On Thu, Mar 6, 2008 at 3:50 AM, Eero Pajarre <epa...@gm...> wrote:
> My memory corruption error may very well be the same problem
> as reported under wxGridCellRenderer/ wxGridCellEditor problem.
>
> Current evidence points to that direction.
>
> (I am now wondering should wxadv_bind.cpp use
> wxLUA_IMPLEMENT_wxGridCellWorker_ENCAPSULATION
> instead of wxLUA_IMPLEMENT_ENCAPSULATION
> for wxGridCellChoiceEditor etc...
>
> Changing that seems to help on the crashing)
Yes, I found and fixed that problem (wxGridCellWorker derived classes
have protected destructors so you cannot call 'delete' on them, you
must call DecRef()), but there is another problem that is not as
simple.
When the wxGrid is destroyed; wxWidgets will also delete all the
children windows of the wxGrid, including any wxControls that the
wxGridCellEditors have created. However the wxGrid has no mechanism to
set the m_control pointer in the wxGridCellEditor to NULL if the
wxControl is deleted by someone else, wxWidgets in this case. This
means that when the wxGridCellEditor itself is destroyed it will try
to delete the m_control a second time since it's not NULL. I need to
find out why this works in C++, but not with wxLua. As far as I can
tell there should be absolutely no difference.
Regards,
 John