[Paraview] "had to make up a value for selection": what am I doing wrong?

Takuya OSHIMA oshima at eng.niigata-u.ac.jp
Mon Aug 4 10:58:05 EDT 2008


It looks to me as if a bugfix (1. in my previous post) surfaced
another possible bug that had been hidden somewhere in the server-GUI
property link (2. and 3.). I really appreciate your inspection.

Thanks,

Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN

From: Utkarsh Ayachit <utkarsh.ayachit at kitware.com>
Subject: Re: [Paraview] "had to make up a value for selection": what am I doing wrong?
Date: Mon, 04 Aug 2008 07:51:01 -0400

> Mark,
> 
> Thanks for the investigation. Let me take a look at it. Problem is 
> indeed due to arrays appearing.
> 
> Utkarsh
> 
> Olesen, Mark wrote:
> > Taking Takuya's hint, I reverted to revision 1.6 of
> > 
> >   Qt/Components/pqSignalAdaptorSelectionTreeWidget.cxx
> > 
> > and it did indeed stop the multitude of "had to make up a value" that
> > were cluttering up my message window.
> > 
> > The problem arises in my cases when the number of entries in a
> > vtkDataArraySelection changes - eg, new fields or mesh parts appear or
> > disappear between time-steps.
> > Perhaps this hint might help in localizing the problem.
> > 
> > 
> > /mark
> > 
> >> -----Original Message-----
> >> From: paraview-bounces at paraview.org [mailto:paraview-
> >> bounces at paraview.org] On Behalf Of Takuya OSHIMA
> >> Sent: Tuesday, July 29, 2008 3:12 PM
> >> To: paraview at paraview.org
> >> Subject: Re: [Paraview] "had to make up a value for selection": what
> >> am I doing wrong?
> >>
> >> Hi ParaView developers,
> >>
> >> As I got no answer so far from the list, I did some digging with a
> >> debugger. As a result it's looking more like a bug in ParaView, but
> >> I'm not confident yet. So far what I found are threefold:
> >>
> >> 1. If I revert the following modification to
> >> pqSignalAdaptorSelectionTreeWidget.cxx on 2008-07-02
> >>
> >> Index: pqSignalAdaptorSelectionTreeWidget.cxx
> >> ===================================================================
> >> RCS file:
> >> /cvsroot/ParaView3/ParaView3/Qt/Components/pqSignalAdaptorSelectionTre
> >> eWidget.cxx,v
> >> retrieving revision 1.6
> >> retrieving revision 1.7
> >> diff -r1.6 -r1.7
> >> 187,188c187,190
> >> <
> >> <   this->Internal->Property->ResetToDefault();
> >> ---
> >>>   // Domain changes should not change the property values. This is
> >> overriding
> >>>   // the value loaded from state files etc.
> >>>   // this->Internal->Property->ResetToDefault();
> >> , the "had to make up a value" message disappeared and reader worked
> >> as expected. This coincides with my thought that the problem started
> >> at around a month ago.
> >>
> >> 2. After doing AddArray() to the selection object in the reader,
> >> ParaView does seem to recognize the newly added item, since in
> >>
> >> void vtkSMArraySelectionInformationHelper::UpdateProperty(
> >>   vtkIdType connectionId,  int serverIds, vtkClientServerID objectId,
> >>   vtkSMProperty* prop)
> >>
> >> numArrays turned out to have the expected number of arrays, and the
> >> results of GetArgument() were precisely expected values. I could
> >> confirm the new item is added to prop (the last argument in the
> >> function prototype above) through SetElement(). The address prop
> >> pointed to was 0x078c5b38 in the tracked case.
> >>
> >> 3. However, when
> >>
> >> void pqSignalAdaptorSelectionTreeWidget::domainChanged()
> >>
> >> was executed later, the address this->Internal->Property pointed to
> >> was 0x078cd688, which was different from what prop pointed
> >> to. Naturally, the object this->Internal->Property pointed to did not
> >> contain the new item. Thus the missing item triggered the "had to make
> >> up
> >> a value" message in
> >>
> >> QList<QVariant> pqSMAdaptor::getSelectionProperty(vtkSMProperty*
> >>   Property, unsigned int Index).
> >>
> >> So my question after all is, where and why has prop (the object at
> >> 0x078c5b38) gone?  Even with a debugger, tracking what had been going
> >> on behind 100+ call tree stack was simply out of my skill range. Can
> >> you comment if this behavior is expected, or a bug?
> >>
> >> Thanks,
> >> Takuya
> >>
> >> Takuya OSHIMA, Ph.D.
> >> Faculty of Engineering, Niigata University
> >> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
> >>
> >>
> >> From: Takuya OSHIMA <oshima at eng.niigata-u.ac.jp>
> >> Subject: [Paraview] "had to make up a value for selection": what am I
> >> doing wrong?
> >> Date: Fri, 25 Jul 2008 13:48:28 +0900 (JST)
> >>
> >>> Hi,
> >>>
> >>> My reader for the latest CVS head has a selection list within its UI
> >>> panel associated with its corresponding vtkDataArraySelection
> >> object,
> >>> as shown below in its XML representation. The selection list is
> >>> initialized when RequestInformation() is called for the first time,
> >>> and works perfectly as long as the contents of the list remain
> >>> unchanged.
> >>>
> >>> However if the reader try to add items to the selection list later
> >>> within RequestData(), the newly added items always appear unchecked
> >> in
> >>> the UI panel regardless of the status in its corresponding
> >>> vtkDataArraySelection, and messages saying "had to make up a value
> >> for
> >>> selection" are shown in the output window a number of times equal to
> >>> the number of items added.
> >>>
> >>> If I remember correctly this piece of code worked fine until rather
> >>> recent CVS (within a month or so, but not so sure).
> >>>
> >>> What am I doing wrong?
> >>>
> >>>         <StringVectorProperty
> >>>             name="CellArrayInfo"
> >>>             information_only="1">
> >>>             <ArraySelectionInformationHelper attribute_name="Cell"/>
> >>>         </StringVectorProperty>
> >>>         <StringVectorProperty
> >>>             name="CellArrays"
> >>>             command="SetCellArrayStatus"
> >>>             number_of_elements="0"
> >>>             repeat_command="1"
> >>>             number_of_elements_per_command="2"
> >>>             element_types="2 0"
> >>>     	    information_property="CellArrayInfo">
> >>>             <ArraySelectionDomain name="array_list">
> >>>                 <RequiredProperties>
> >>>                     <Property name="CellArrayInfo"
> >>>                         function="ArrayList"/>
> >>>                 </RequiredProperties>
> >>>             </ArraySelectionDomain>
> >>>         </StringVectorProperty>
> >>>
> >>> Takuya OSHIMA, Ph.D.
> >>> Faculty of Engineering, Niigata University
> >>> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
> >>> _______________________________________________
> >>> ParaView mailing list
> >>> ParaView at paraview.org
> >>> http://www.paraview.org/mailman/listinfo/paraview
> >> _______________________________________________
> >> ParaView mailing list
> >> ParaView at paraview.org
> >> http://www.paraview.org/mailman/listinfo/paraview
> > This e-mail message and any attachments may contain 
> > legally privileged, confidential or proprietary Information, 
> > or information otherwise protected by law of EMCON 
> > Technologies, its affiliates, or third parties. This notice 
> > serves as marking of its "Confidential" status as defined 
> > in any confidentiality agreements concerning the sender 
> > and recipient. If you are not the intended recipient(s), 
> > or the employee or agent responsible for delivery of this 
> > message to the intended recipient(s), you are hereby 
> > notified that any dissemination, distribution or copying 
> > of this e-mail message is strictly prohibited. 
> > If you have received this message in error, please 
> > immediately notify the sender and delete this e-mail 
> > message from your computer.
> > 
> > _______________________________________________
> > ParaView mailing list
> > ParaView at paraview.org
> > http://www.paraview.org/mailman/listinfo/paraview
> > 


More information about the ParaView mailing list