Hi, On Sunday 04 July 2010, Prasenjit Kapat wrote: > A question regarding the following function (or nextPlot() or > firstPlot() or ...) in rkwindowcatcher.cpp.
I'll in a somewhat different order: - I think the only safe assumption regarding the state of the history is that the R code knows the "true" state of the history at all times, while the code in RKWard does not. This will become even more relevant once you implement history length/size limits. But also, sine rk.next.plot() and friends are publicly visible, we should assume people might use them from R, directly, even though it will be used via the tool-buttons *most* of the time. - The calls to updateHistoryActions() in the C++ code really are not very important for that reason. In adding them, I was thinking about the corner case where R is still busy (or replaying the plot takes a considerable amount of time). Here the idea was to give a graphical indication immediately, while .rk.graph.history.gui() will not be called immediately. And it was easy to do... Of course if this is not always correct, as you write, then maybe it is not worth doing. (Side note: The C++-code also only takes care of updating the actions in the current device, while - if history length changes - all devices will need to be updated). > Does it matter if updateHistoryActions (...) is called before or after > calling RKGlobals::rInterface ()->issueCommand (...)? Technically, no. Commands run asynchronously, and while you can never tell whether the command will get run immediately or later, RKWard will not see anything about that command (including the callback from .rk.graph.history.gui()) until the next iteration of the event loop. Thus, putting updateHistoryActions() after issueCommand() would not make a difference. But since updateHistoryActions() *will* happen first, it makes sense to place it first for readability. I see that I did not do so, consistently. > If the R command (in the variable 'c') changes the length of the > history then, is the updateHistoryAction (....) call aware (or > unaware) of this change? I think it is not! It is not, or at least only in some cases (for instance when clearing the history, we know that the new length (and position) will be 0, so in clearHistory() we have updateHistoryActions (0, 0). > I was trying to avoid calling .rk.graph.history.gui () from the replay > (...) function (ie comment line 179 in public_graphics.R of rev. 2930) > and hoping that the (uncommented) updateHistoryActions (...) calls > would take care of the job. Again, I think the only safe assumption is that the R code is in charge of the history, not the other way around. > But, in a situation where the current plot > is unsaved and the user clicks the "previous" button, although > recordUnsaved () does save this plot, the updated history length (one > more plot was added) does not get passed on to > RKCaughtX11Window::previousPlot. As a result the updateHistoryActions > () call still uses the old history_length value (which is one less > than the updated length). And hence a little chaos. I had not thought of that case. I guess it's hard to tell whether this will happen from the C++ code. Thus, perhaps it's really best to simply remove those calls to updateHistoryActions(), and let .rk.graph.history.gui() take care of it. Regards Thomas
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
