Hi Jim > >> I personally am a bit uncomfortable with the way plbuf_bop() calls >> wr_command(). Although I can see the code reuse benefits somehow it >> feels wrong that we start generating sub commands within commands and >> I can't quite put my finger on why it feels wrong. Perhaps someone >> else might have comments. If I'm honest I would much rather see a call >> to c_plscmap() in plP_bop() which gives the code reuse, but without >> the uncomfortable feeling. > > I'm confused by this comment. The wr_command( pls, (U_CHAR) BOP ) indicates > the BOP command when the buffer is executed (e.g. by a resize). The key > thing that it does is restore the state at BOP. > > Do you mean the the two commands for saving the colormaps? A call to > c_plscmap() would not work in plbuf_bop() because the colormap needs to be > written to the buffer. I could easily remove the plbuf_control(…) and > substitute the two wr_data() commands. I did PLSTATE_CMAP# way originally > because I was relying the colormap being restored as a PLSTATE_CMAP# > operation when the buffer was executed. However, to fix the bug you > identified the original approach does not work. >
It was the latter that worried me, i.e. the setting of the colormaps. Presumably though a call to c_plscmap* in plP_bob will result in a call to plP_state and via this call to the colourmaps being saved in the buffer. Anyway, this is a minor point really and only a question of style - I don't think there is a "right answer" here, many ways to skin a cat and all that. Anyway, I have made the one character fix of changing the function name as you suggest and I've run the code through quite a few of the examples, including those that check the text and I've checked that the colourmaps issue is gone with wxWidgets so I'm happy to commit the changes which I'll do now. Phil ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
