Hi Andrew
If I'm honest, until just now I'd never tried to build the test applications.
I actually don't see the same behaviour as you. Without the patch I see no 
window appearing. Only with the patch applied do I see the expected output.
The bug will only appear if IMPLEMENT_PLAPP_NO_MAIN is called by 
wxwidgets_app.cpp after IMPLEMENT_APP in wxPLplotDemo.cpp or user code. As 
these macros are in global scope and in different files could the execution 
order be compiler dependant? This could explain why we see different behaviour. 
I'm compiling on Windows with MSVC++ Express, based on solution/project files 
generated by CMake.
 
Phil
 

________________________________
 From: Andrew Ross <andrewr...@users.sourceforge.net>
To: phil rosenberg <philip_rosenb...@yahoo.com> 
Cc: "plplot-devel@lists.sourceforge.net" <plplot-devel@lists.sourceforge.net> 
Sent: Friday, 29 June 2012, 11:57
Subject: Re: [Plplot-devel] wxWidgets initialisation bug
  

Hi Phil,

I'm certaintly no expert on the wxwidgets driver, but your suggestion
does seem sensible. I've checked and it doesn't break either "make
test_wxPLplotDemo" or "make test_c_wxwidgets" which I take as a good
sign. I notice that wxPLplotDemo does derive a class from wxApp not
wxPLplotApp, but it doesn't seem to have the same problems you've had.
Have you looked at this to see what is different? 

Werner could you confirm that this fix is the right thing to do and 
we can get it committed.

Andrew


On Thu, Jun 28, 2012 at 06:08:38PM -0700, phil rosenberg wrote:
> Hi
> I'm emailing with a patch which I believe fixes a bug in the wxWidgets driver.
> ?
> The problem occurrs when trying to include plplot in a wxWidgets application 
> that is separate to PLplot - i.e. when the user wants to use their own 
> derivation of wxApp rather than wxPLplotApp.
> The bug manifests itself as an apparent hang before any windows have 
> appeared. In the past I've worked around it by removing wxwidgets_app.cpp and 
> all reference to its contents from plplot before compilation, but this is 
> clearly not ideal.
> ?
> After some digging I found that the bug boils down to a static function 
> pointer which the user assigns defining the wxApp derived class to use. 
> Unfortunately after the user has assigned this function pointer PLplot 
> reassigns it meaning a wxPLplotApp is used instead of the user's wxApp.
> ?
> The fix is to simply check if the pointer is NULL (as initialised by 
> wxWidgets)?before assignment. This ensures wxPLplotApp is only used if the 
> user hasn't assigned their own function first.
> ?
> I have tested this from the perspective of avoiding the crash, but I've never 
> used wxPLplotApp before. If someone has this up and running could they check 
> it doesn't cause any problems?
> ?
> Cheers
> ?
> Phil


> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to