Tue 08 Oct 2013 10:59:16 PM UTC, comment #10:
The committed patch works for me against the examples in this bug report. Marking it as fixed and closing report.
|
Tue 08 Oct 2013 10:42:00 PM UTC, comment #9:
Thanks for following up. I did some simple tests, which all worked.
I made a trivial change to the log and pushed it.
http://hg.savannah.gnu.org/hgweb/octave/rev/07a4597fcbac
|
Tue 08 Oct 2013 10:10:37 PM UTC, comment #8:
First of all this bug happens for any kind of axes property (not only "axesunits")
To clone a particular property <TYPE><PROP> (such as axesunits here), an orphan dummy object of type TYPE is created and stored for further use (see dprop_map).
The first time you call addproperty a new axes is created to clone its "units" property: one of the initialization stages (get_boundingbox) requires retrieving parent figure bounding box, but the axes has no valid parent figure.
The second time, the dummy axes already exists and the error does not occur.
Attached is a patch that "fixes" this issue: if the axes parent is invalid, default_figure_position () is used to compute the axes bounding box.
It happens that only axes objects seams to require informations about their parent but it could be the case for other objects. A more robust way of fixing this maybe to build a proper figure tree (in dprop_map) instead of individual objects.
(file #29332)
|
Tue 02 Jul 2013 07:33:00 AM UTC, comment #7:
Ok. That is a different problem. Please file a separate bug report. Be sure to include the example.
|
Tue 02 Jul 2013 06:55:40 AM UTC, comment #6:
Ok, the bug with gnuplot is raised when trying to manipulate the new property. Can you confirm that the following code (ran with gnuplot toolkit) :
... always raises an error, either in dev version or in release (I am on 3.6.3, not 3.6.4)?
|
Tue 02 Jul 2013 01:26:21 AM UTC, comment #5:
Pantxo,
I've confirmed the error occurs on my first attempt (with both fltk and gnuplot)
If I use "units" in place of "myunits" with fltk, I also see the same error, but on the second attempt it works.
I see the same behavior with gnuplot.
|
Mon 01 Jul 2013 03:18:24 PM UTC, comment #4:
For me, the first call unconditionally returns an error (by "first" I mean in an octave session). After that, the addproperty behaves as expected (provided you don't use "units" as property name + gnuplot) so that I am not surprised that parsing/argument checking is correct.
Your example also work for me but it's not an option as I am currently implementing Matlab's annotation, which involves a property called units and not myunits :-)
Should I also report the fact that "units" instead of "myunits" leads to an error with gnuplot in a separate bug?
|
Mon 01 Jul 2013 12:59:34 PM UTC, comment #3:
hmmm ... I think the problem is that a full update must happen before addproperty(). The following works for me when typed at the command line.
Regarding the second erroneous command, what struck me was that the command was parsed correctly, and a valid error was given.
|
Mon 01 Jul 2013 11:17:01 AM UTC, comment #2:
About the second erroneous command you provided, AFAICS it works as expected: the 4th argument is supposed to be the default value (not the list of allowed values as for radio type), so that the provided string is not supposed to be an allowed value for axesunits property type.
I digged into graphics.in.h to try to find the origin of the error message and found that it may come from a virual member (base_graphics_objct::get_properties (void), line 2843) that inconditionnally returns this error. However there is no reason why this function should be called only once in a session.
|
Mon 01 Jul 2013 07:46:28 AM UTC, comment #1:
I can confirm this bug with the developers sources.
As a work around try,
Due to the erroneous command below, I suspect the fix to the sources is trivial.
|
Sun 30 Jun 2013 10:24:10 AM UTC, original submission:
Calling addproperty as followes:
gives inconsistent result.
The first call raises an error, while a second call won't raise any visible error and the new property works fine with set and get.
Additionnal info:
- tested on linux mint 14 (stable 3.6.3 and recent devel version) and on mac os x (fink-3.6.3).
- does not depend on the graphics_toolkit.
- also tried with a line instead of the hggroup and it gave me the same result.
- things are worst if I use "units" as the property name (but this is probably another bug): with gnuplot toolkit trying to manipulate the new property results in errors
|