Bug #1143

jcom.parameterArray: Weird behavior in @mode array

Added by Trond Lossius almost 7 years ago. Updated almost 7 years ago.

Status:ClosedStart date:2012-05-09
Priority:NormalDue date:
Assignee:Trond Lossius% Done:

0%

Category:-Spent time:-
Target version:MVC for 0.6
Branch:0.6-alpha OS:

Description

Steps to reproduce:

  1. Start Max
  2. Open jcom.parameterArray.maxhelp
  3. Create a new message object
  4. Connect leftmost outlet of the jcom.parameterArray items[6] object to the right inlet of the message box, in order to be able to monitor the output from jcom.parameterArray
  5. Click the array message box connected to jcom.parameterArray items[6] object
  6. Click the 1 message box in order to address instance [1].
  7. Change values in the float number box. Expected result: A list containing 6 numbers. The first should reflect the value of the float number box, while the rest should reflect the default value of the remaining instances (probably 0.0).. Observed result: A single float is output.
  8. Click the 4 message box in order to address instance [4].
  9. Change values in the float number box. Expected result: A list containing 6 numbers. The fourth should reflect the value of the float number box, the first the most recent value for the first instance, while the rest should reflect the default value of the remaining instances (probably 0.0).. Observed result: A list of two values is output, containing the values of instance 1 and 4. Values are missing for instance 2, 3, 5 and 6.

History

#1 Updated by Théo de la Hogue almost 7 years ago

  • Status changed from New to Resolved

Hi Trond,
this is due to the value/default attribute of the Data class (eg parameter | message | return)

If it is not set, this attribute have no value. Changing this is in the Data class certainly very sensitive so I did something specific for the jcom.parameterArray :

if there is no value/default :

if type is string : put "none" 
else : put 0

else : put value/default

is this good for you ?

best

#2 Updated by Trond Lossius almost 7 years ago

  • Status changed from Resolved to Closed
  • Assignee changed from Théo de la Hogue to Trond Lossius

Thanks, Theo, this seems a good solution. The issue seems to be fixed now. I've made an automated test and will commit that shortly.

Also available in: Atom PDF