pspp-dev
[Top][All Lists]
Advanced

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

Re: dict_var_resized


From: Jason Stover
Subject: Re: dict_var_resized
Date: Mon, 4 May 2009 10:56:02 -0400
User-agent: Mutt/1.5.18 (2008-05-17)

On Mon, May 04, 2009 at 07:09:07AM +0800, John Darrington wrote:
> On Fri, May 01, 2009 at 08:23:08PM -0700, Ben Pfaff wrote:
>      John Darrington <address@hidden> writes:
>      
>      > dict_var_resized exists for one purpose only -  it informs the GUI
>      > that the size of a variable has changed.  That way, the var sheet 
>      > always displays the correct information, even if a variable changes
>      > due to some low level operation (eg: running syntax).
>      
>      Right.  So if the variable doesn't belong to a dictionary, then
>      there's nothing to do.
>      
>      > Solution 2:  If that's not possible, then I think it'll be acceptable
>      >     to simply test for d == NULL inside dict_var_resized and do
>      >     nothing in that situation.
>      >
>      > I'd prefer solution 1 if at all possible.
>      
>      I don't understand why solution 1 is preferable.  Why isn't this
>      just a bug in dict_var_resized?  I note that, for example,
>      dict_var_changed does test for the null-dictionary case.
> 
> 
> Then perhaps this would be the better solution after all.
>
> ...
>
> Incidently, the code I posted in my previous email was possibly
> confusing because var_create_internal is supposed to take the
> casereader index as its argument, not the width of the variable as I
> had implied.  We'd need to create a new function in variable.c to do
> what Jason wants.

I thought I needed to call var_set_width to store enough characters
for the variable's values. Should I stop worrying about the size of
the variable, and instead call value_resize on union values if
necessary?

I just used solution 1 by dropping var_set_width, and it ran. Given
the discussion, there seems to be no reason for me to call
var_set_width, as John suggested. It's simpler code, too.

-Jason







reply via email to

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