I was investigating why the find dialog causes an error when you close it. It seems that wxRuby2 is returning a new ruby object when you call Event.get_dialog. This causes some big problems when you''re expecting you''re going to get back the same ruby pointer that you put in. In a brief check over the source I don''t see anything that preserves the original ruby object pointer or any way to tie a CPP object back to a ruby object. I do see you can find the CPP from the ruby. Is this a ''known'' problem that has an easy workaround? Or is this something much more structural that has to be addressed at the core of the Swig files? Roy
Roy Sutton wrote:> I was investigating why the find dialog causes an error when you close > it. It seems that wxRuby2 is returning a new ruby object when you call > Event.get_dialog.(snip)> Is this a ''known'' problem that has an easy workaround? Or is this > something much more structural that has to be addressed at the core of > the Swig files?We had to solve this in non-swig wxruby by keeping a map of all ruby objects that were passed into wx, and whenever an object was returned back out of wx, we checked to see if it matched up with one that was passed in. I think we could do the same thing in swig. I''m not sure if it can be done via a typemap, or if it would have to be a post-process step, or if there''s a clean .i way. I know wxPython has the same issue, so it would be interesting to see how they solved it. Hm. We already keep a map of all known ruby->cpp objects to avoid double-freeing them. wx.i has the functions: GcMapPtrToValue GcGetValueFromPtr GcMarkDeleted GcIsDeleted I don''t actually see the case you''re referring to. Where does FileDialog use an event to carry an object value? Kevin
FindDialogEvent.cpp -- get_dialog Sorry if I was unclear on where it goes. I will check those functions out. Any thoughts on the two patches I sent earlier? I''d like to get those cleaned up. Roy Kevin Smith wrote:> Roy Sutton wrote: > >> I was investigating why the find dialog causes an error when you >> close it. It seems that wxRuby2 is returning a new ruby object when >> you call Event.get_dialog. > > (snip) > >> Is this a ''known'' problem that has an easy workaround? Or is this >> something much more structural that has to be addressed at the core >> of the Swig files? > > > We had to solve this in non-swig wxruby by keeping a map of all ruby > objects that were passed into wx, and whenever an object was returned > back out of wx, we checked to see if it matched up with one that was > passed in. > > I think we could do the same thing in swig. I''m not sure if it can be > done via a typemap, or if it would have to be a post-process step, or > if there''s a clean .i way. I know wxPython has the same issue, so it > would be interesting to see how they solved it. > > Hm. We already keep a map of all known ruby->cpp objects to avoid > double-freeing them. wx.i has the functions: > GcMapPtrToValue > GcGetValueFromPtr > GcMarkDeleted > GcIsDeleted > > I don''t actually see the case you''re referring to. Where does > FileDialog use an event to carry an object value? > > Kevin > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > >
I''m investigating this a bit more... I tried turning on wxDEBUG and testing GcGetValueFromPointer. It seems that a director is never created for FindReplaceDialog so there''s no mapping available. Looking at the director code that''s included I somewhat expected the director to be added in somewhere. Any other thoughts? Kevin Smith wrote:> Roy Sutton wrote: > >> I was investigating why the find dialog causes an error when you >> close it. It seems that wxRuby2 is returning a new ruby object when >> you call Event.get_dialog. > > (snip) > >> Is this a ''known'' problem that has an easy workaround? Or is this >> something much more structural that has to be addressed at the core >> of the Swig files? > > > We had to solve this in non-swig wxruby by keeping a map of all ruby > objects that were passed into wx, and whenever an object was returned > back out of wx, we checked to see if it matched up with one that was > passed in. > > I think we could do the same thing in swig. I''m not sure if it can be > done via a typemap, or if it would have to be a post-process step, or > if there''s a clean .i way. I know wxPython has the same issue, so it > would be interesting to see how they solved it. > > Hm. We already keep a map of all known ruby->cpp objects to avoid > double-freeing them. wx.i has the functions: > GcMapPtrToValue > GcGetValueFromPtr > GcMarkDeleted > GcIsDeleted > > I don''t actually see the case you''re referring to. Where does > FileDialog use an event to carry an object value? > > Kevin > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > >
At least on my system, FindReplaceDialog does get a director. It''s declared in src/FindReplaceDialog.h, and you can see the stuff that fixdeleting.rb inserted into the .cpp file in the function: free_wxFindReplaceDialog Kevin Roy Sutton wrote:> I''m investigating this a bit more... I tried turning on wxDEBUG and > testing GcGetValueFromPointer. It seems that a director is never > created for FindReplaceDialog so there''s no mapping available. Looking > at the director code that''s included I somewhat expected the director to > be added in somewhere. Any other thoughts? > > Kevin Smith wrote: > >> Roy Sutton wrote: >> >>> I was investigating why the find dialog causes an error when you >>> close it. It seems that wxRuby2 is returning a new ruby object when >>> you call Event.get_dialog. >> >> >> (snip) >> >>> Is this a ''known'' problem that has an easy workaround? Or is this >>> something much more structural that has to be addressed at the core >>> of the Swig files? >> >> >> >> We had to solve this in non-swig wxruby by keeping a map of all ruby >> objects that were passed into wx, and whenever an object was returned >> back out of wx, we checked to see if it matched up with one that was >> passed in. >> >> I think we could do the same thing in swig. I''m not sure if it can be >> done via a typemap, or if it would have to be a post-process step, or >> if there''s a clean .i way. I know wxPython has the same issue, so it >> would be interesting to see how they solved it. >> >> Hm. We already keep a map of all known ruby->cpp objects to avoid >> double-freeing them. wx.i has the functions: >> GcMapPtrToValue >> GcGetValueFromPtr >> GcMarkDeleted >> GcIsDeleted >> >> I don''t actually see the case you''re referring to. Where does >> FileDialog use an event to carry an object value? >> >> Kevin >> _______________________________________________ >> wxruby-users mailing list >> wxruby-users@rubyforge.org >> http://rubyforge.org/mailman/listinfo/wxruby-users >> >> >> > > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users
Yes, it does get a director but it''s created not owning the object so the director doesn''t track the memory for GC so the commands you pointed out before don''t work. Also, I know that a few objects don''t get directors. I''ll invetigate fixdeleting a bit more. Kevin Smith wrote:> At least on my system, FindReplaceDialog does get a director. It''s > declared in src/FindReplaceDialog.h, and you can see the stuff that > fixdeleting.rb inserted into the .cpp file in the function: > free_wxFindReplaceDialog > > Kevin > > > Roy Sutton wrote: > >> I''m investigating this a bit more... I tried turning on wxDEBUG and >> testing GcGetValueFromPointer. It seems that a director is never >> created for FindReplaceDialog so there''s no mapping available. >> Looking at the director code that''s included I somewhat expected the >> director to be added in somewhere. Any other thoughts? >> >> Kevin Smith wrote: >> >>> Roy Sutton wrote: >>> >>>> I was investigating why the find dialog causes an error when you >>>> close it. It seems that wxRuby2 is returning a new ruby object >>>> when you call Event.get_dialog. >>> >>> >>> >>> (snip) >>> >>>> Is this a ''known'' problem that has an easy workaround? Or is this >>>> something much more structural that has to be addressed at the core >>>> of the Swig files? >>> >>> >>> >>> >>> We had to solve this in non-swig wxruby by keeping a map of all ruby >>> objects that were passed into wx, and whenever an object was >>> returned back out of wx, we checked to see if it matched up with one >>> that was passed in. >>> >>> I think we could do the same thing in swig. I''m not sure if it can >>> be done via a typemap, or if it would have to be a post-process >>> step, or if there''s a clean .i way. I know wxPython has the same >>> issue, so it would be interesting to see how they solved it. >>> >>> Hm. We already keep a map of all known ruby->cpp objects to avoid >>> double-freeing them. wx.i has the functions: >>> GcMapPtrToValue >>> GcGetValueFromPtr >>> GcMarkDeleted >>> GcIsDeleted >>> >>> I don''t actually see the case you''re referring to. Where does >>> FileDialog use an event to carry an object value? >>> >>> Kevin >>> _______________________________________________ >>> wxruby-users mailing list >>> wxruby-users@rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wxruby-users >>> >>> >>> >> >> _______________________________________________ >> wxruby-users mailing list >> wxruby-users@rubyforge.org >> http://rubyforge.org/mailman/listinfo/wxruby-users > > > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > >
Maybe Matching Threads
- common.i patch
- [710] trunk/wxruby2/swig/common.i: Added extern keyword to Gc functions and moved common header includes to %runtime
- [1070] trunk/wxruby2/swig/fixdeleting.rb: Remove old, now unused, fixdeleting script
- Patch to 0.0.39
- [Fwd: [ wxruby-Bugs-6144 ] error: cast from ‘void*’ to ‘int’ loses precision]