octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Updaters and default property values


From: Ben Abbott
Subject: Re: Updaters and default property values
Date: Mon, 12 Mar 2012 14:03:13 -0400

On Mar 12, 2012, at 1:08 PM, Rik wrote:

> Ben, Michael,
> 
> We should put some thought into how to address this issue.  The interaction 
> between default properties and functions with updaters is already broken.  
> See this bug report (https://savannah.gnu.org/bugs/?35662).
> 
> Briefly, Octave does traverse down through the C++ code and eventually calls 
> set_<property>() for each default.  However, at the time the code is called 
> the axes are not completely set up and therefore the update_<property> 
> functions can fail when they rely on a second property which has not yet been 
> initialized.  A second issue is that I don't believe there is any guaranteed 
> order of execution for the default properties.  Even though the defaults may 
> have been coded in the order 1,2,3 in an m-file the actual routines could be 
> called in the order 2,1,3 or whatever.
> 
> This sort of Catch-22 seems like a common coding problem and maybe there is a 
> common solution to apply in this regard.
> 
> My thought had been to preserve the set functionality of set property but 
> disable updaters while initializing an axis (or figure).  For example, the 
> code of an average set_<property> function WITH an updater looks like this
> 
> void set_<property> (const octave_value& val)
> {
>   if (! error_state)
>     {
>       if (<property>.set (val, true))
>         {
>           update_<property> ();
>           mark_modified ();
>         }
>     }
> }
> 
> I was thinking of modifying the if conditional to
> 
> if (<property>.set (val, true) && ! init_axes)
> 
> where init_axes would choke off the further call to update_<property>.
> 
> Is there a better way?
> 
> --Rik

Rik, thanks for this.

I was suspicious that the updaters weren't working correctly due to the order 
of initialization, or that some properties had not yet been assigned values 
when the updating was done.

I like your idea, but am not sure about the details (since my reading of the 
code is still limited).

Do you mean ...

(1) Disable updating and assign the factory defaults. By "factory defaults" I 
mean those encompassed in the BEGIN_PROPERTIES/END_PROPERTIES blocks. These 
would need to be fully consistent. For example, papertype = "usletter", 
papersize = [8.5 11.0], orientation = "portrait".

(2) Enable updating and assign the default<object><property> values, and as 
each property is the updaters run their course.

I think that would work provided the order of setting the properties and 
running the updating doesn't change the result. In the case of the paper* 
properties, I think this should work.

Ben
 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]