[Paraview] "had to make up a value for selection": what am I doing wrong?
Utkarsh Ayachit
utkarsh.ayachit at kitware.com
Fri Sep 5 08:33:13 EDT 2008
Great, in that case, I shall commit the fix to CVS sometime today.
Utkarsh
Takuya OSHIMA wrote:
> 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 <utkarsh.ayachit at kitware.com>
> 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 <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