Hi Phil: I have now had more of a chance to read your e-mail so I have some more detailed responses to it below.
On 2017-03-03 16:02-0000 Phil Rosenberg wrote: [...] > So a couple of things spring to mind. Firstly you must at some point > renter the event loop to allow the viewer to start doing stuff again. > If you are sat in a loop in you communication code just waiting for > something to happen then it never will because the execution point is > in your communication code and not dealing with the mouse pointer. I am glad you brought up wxPLViewer events because I am still trying to understand those. For example, I presume (from the name) that wxPlFrame::OnCheckTimer is called every time the event timer fires, and that will continue at various rates (depending on what is set) until the timer is killed when m_header.completeFlag is true. And similarly, wxPlFrame::OnMouse is called every time there is a mouse event, and so on for all other events in the event table. So until the timer is stopped, I assume the net effect is wxPlFrame::OnCheckTimer (which in turn calls ReadTransmission that processes all the different transmission types sent by -dev wxwidgets) is effectively run simultaneously with wxPlFrame::OnMouse and the rest of the responses to different events. Have I got what goes on in event processing interpreted correctly? Of course, in direct answer to your concern, if ReadTransmission just blocked waiting for a semaphore, then wxPLViewer would hang, but that blocking should not happen unless -dev wxwidgets has incorrectly terminated its transmission type requests to ReadTransmission, and there is no sign of that type of bug in the code right now according to debug messages being printed out by ReadTransmission. In fact, according to those, readTransmission returns (as does OnCheckTimer that called it), and the hang occurs elsewhere (before the example 1 plotbuf that is created before transmissionType == transmissionLocate is sent from the -dev wxwidgets side) is plotted. So the first order of business is to get those plotbuf commands plotted. > calling wxYield will go check the event loop, deal with that stuff > then return, but it's often not the best solution because nested calls > to wxYield aren't permitted. If possible it is better to return from > your function and use some other event to trigger your return > communication. Perhaps this could be at the end of the method that > deals with capturing mouse activity. Just to remind you, all that transmissionLocate does is call SetPageAndUpdate() (just like what happens for most other transmission types), and then it sets m_locateMode = true; which has no effect on the rest of transmissionLocate but which has a profound effect on how wxPlFrame::OnMouse is executed, i.e., that event immediately returns with that variable is false and processes a mouse event whenever that variable is true. So all that may be working fine, and the issue is simply to get the plbuf commands plotted. > Another thing is that to cause the plot to be redrawn you must tell > wxWidgets that there is something new to draw. I think the method for > this is Refresh(). Then you must allow the event loop to be entered to > allow the redraw to actually take place. SetPageAndUpdate (referred to above) does normally call Refresh() if there is anything more to be plotted. So it appears the current ReadTransmission code does everything you suggest, i.e., handles transmissionLocate flawlessly. However, I now realize there is an issue in wxPlFrame::OnMouse which attempts (when m_locateMode = true) to collect mouse information and send it back to -dev wxwidgets and evidentially that is happening in the wrong order (before the plot is displayed). How can I absolutely assure that the plot is displayed before wxPlFrame::OnMouse is entered? > A final thing to think about is that locate must be dealt with > immediately. It sounded like you were holding locate requests and > continuing to send plot commands. Locate is dealt with as follows (which I think you can classify as "immediately"). The code in question is in the patch I sent you. We have the following sequence of calls in wxPLDevice::Locate TransmitBuffer( pls, transmissionLocate ); m_outputMemoryMap.receiveBytes( true, &m_header, sizeof ( MemoryMapHeader ) ); *graphicsIn = m_header.graphicsIn; The first sends both transmissionLocate and plbuf to wxPLViewer which processes those in ReadTransmission as I have described above (also confirmed by debug messages). Then that code returns and after that the plot should be displayed (which isn't happening for some reason) and the event loop should be running. After that when a mouse event occurs wxPlFrame::OnMouse should be entered and that method collects information about that mouse event in a header, sends that header back to -dev wxwidgets with transmitBytes which is received by the above receiveBytes command and sent back to example 1 for printout via graphicsIn. I hope that is clear. In any case, my next steps are to confirm that wxPlFrame::OnMouse is being entered properly each time a mouse button is clicked, and to try to discover why there is no display of the plot before that happens (for both -DPL_WXWIDGETS_IPC2=ON and -DPL_WXWIDGETS_IPC2=OFF). > As I said I haven't looked at the code, just read your email, but > these are the first places to look as a guess. > > Also there is a debug #define which when used means that plplot does > not launch the viewer, instead it just sits and waits for you to > launch it manually. This way you can launch the viewer in a debugger > to see what is going on in there. Thanks again, Phil, for these remarks which seem to imply I am on the right track so I am likely looking for a small bug rather than a gross misdesign. By the way, I have now looked at the third (deprecated) version of the code, and that is more sophisticated in how it treats keyboard and mouse events, e.g., special crosshairs in locate mode). So I plan to do a lot more with wxPlFrame::OnKey and wxPlFrame::OnMouse once I can get the plot displayed properly before they are entered. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
