Hi Utkarsh,

Thanks a lot, it did fix the issue!

Takuya

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


From: Utkarsh Ayachit <[EMAIL PROTECTED]>
Subject: Re: [Paraview] "had to make up a value for selection": what am I doing 
wrong?
Date: Thu, 04 Sep 2008 15:01:33 -0400

> Takuya,
> 
> Can you try the attached patch and see if that fixes the issue?
> 
> Now the pqSMAdaptor tries to obtain the array status from the information 
> property is not available in the property itself.
> 
> Utkarsh
> 
> 
> 
> Takuya OSHIMA wrote:
> > Hi Utkarsh,
> > I had another look into the issue again, and concluded that it's a bug
> > in ParaView. The tracker ID is #7583.
> > The main problem was indeed in the removal of the
> > this->Internal->Property->ResetToDefault() call. Before the removal
> > the ResetToDefault() call subsequently executed
> > vtkSMArraySelectionDomain::SetDefaultValues() which copies the
> > contents of associated information property to the
> > StringVectorProperty.
> > However with the removal now there's nothing which links the
> > information property and the StringVector property, despite the
> > server-client downlink (client/server stream->information
> > helper->information property->array selection domain->string vector
> > property) worked properly until the update of ArraySelectionDomain
> > which interfaces the two properties. Hence the StringDomain of the
> > newly added array name is found in
> > pqSMAdaptor::getSelectionProperty(vtkSMProperty*, unsigned int) while
> > the corresponding StringVectorProperty is not, which led to the "had
> > to make up a value for selection" text output.
> > I think the fix intended by the removal of ResetToDefault() must be
> > done elsewhere.
> > For clarification, I attached a pseudo reader plugin to demonstrate
> > the problem. Just build as a usual plugin, load into ParaView, and try
> > reading any stub file with the *.pseudo extension. After clicking
> > Apply, you'll see the "had to make up..." message every time you move
> > the timestep back and forth.
> > Takuya OSHIMA, Ph.D.
> > Faculty of Engineering, Niigata University
> > 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
> > From: Utkarsh Ayachit <[EMAIL PROTECTED]>
> > 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: [EMAIL PROTECTED] [mailto:paraview-
> >>>> [EMAIL PROTECTED] On Behalf Of Takuya OSHIMA
> >>>> Sent: Tuesday, July 29, 2008 3:12 PM
> >>>> To: [email protected]
> >>>> 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 <[EMAIL PROTECTED]>
> >>>> 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
> >>>>> [email protected]
> >>>>> http://www.paraview.org/mailman/listinfo/paraview
> >>>> _______________________________________________
> >>>> ParaView mailing list
> >>>> [email protected]
> >>>> 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
> >>> [email protected]
> >>> http://www.paraview.org/mailman/listinfo/paraview
> >>>
_______________________________________________
ParaView mailing list
[email protected]
http://www.paraview.org/mailman/listinfo/paraview

Reply via email to