GUI "refresh" wierdness

[Guest xionmark]

Hi,

This is a problem that's been plauging me for a long time, more an annoyance than a bug, but I'd like to be able to fix it.

What happens is that some fields in the GUI are not always "active" when they should be after the OP has been first created or when the .hip file is first opened up. I see that the disableParms() function is called, usually at least 2 times upon the creation of the OP or when opening the .hip file.

In this example, notice the "Start/End" field is disabled:

After toggeling the "Animated" menu above it, the "Start/End" field then becomes active.

The disableParms() function starts by disabling all parms, then based on the state the SOP is in will enable a selection of the parms, please see the code fragment below. What's weird is this is the function that gets called when the user changes any GUI parm, yet it the parms aren't always set correctly when disableParms() is called in those 2 circumstances, adding a new OP and when first opening the .hip file.

Any ideas? Suggestions?

Thanks!

--Mark

    unsigned changed = 0;

	// First turn them all off
	for(int i=0; i < 28; i++)
  enableParm(i, 0);

	// If we're writing an SD file
	if(!mySD_BIN) {

  // change the state of the Start/End GUI widget
  if(myStaticAnim) {
 	 changed  += enableParm(4, 1);
  }
  else {
 	 changed  += enableParm(4, 0);
  }

   	 changed  += enableParm(3, 1);  // non-animated/animated
   	 changed  += enableParm(7, 1);  // obj color
   	 changed  += enableParm(8, 0);  // tex filename (not yet implemented)
   	 changed  += enableParm(9, 1);  // apply object transforms
  
	}
	// else we're writing a particle BIN file
	else {

   	 changed  += enableParm(3, 0);  // non-animated/animated
  // start/end (particle exports are always animated)
  changed  += enableParm(4, 1);	// start/end
   	 changed  += enableParm(10, 1);  // fluid name 
   	 changed  += enableParm(11, 1);  // fluid type 
   	 changed  += enableParm(12, 1);  // FPS
   	 changed  += enableParm(13, 1);  // scene scale
   	 changed  += enableParm(14, 1);  // radius
   	 changed  += enableParm(15, 1);  // pressure min
   	 changed  += enableParm(16, 1);  // pressure max
   	 changed  += enableParm(17, 1);  // pressure avg 
   	 changed  += enableParm(18, 1);  // speed min
   	 changed  += enableParm(19, 1);  // speed max
   	 changed  += enableParm(20, 1);  // speed avg
   	 changed  += enableParm(21, 1);  // temp min
   	 changed  += enableParm(22, 1);  // temp max
   	 changed  += enableParm(23, 1);  // temp avg
   	 changed  += enableParm(24, 1);  // emitter pos
   	 changed  += enableParm(25, 1);  // emitter rot
   	 changed  += enableParm(26, 1);  // emitter scale
	}

	// Always on
    enableParm(0, 1);  // GUI switcher
    enableParm(1, 1);  // fname
    enableParm(2, 1);  // SD/BIN
    enableParm(5, 1);  // echo to console
    enableParm(6, 1);  // write file 

	if(DEBUG > 0)
  cout << "disableParms()-changed: " << changed << endl;

    return changed;
}

[edward]

disableParms() gets called for every parm change because one might want to disable/enable parameters based on the values of other parameters. So if those other parameters change, then you would want to know about them.

You're using these member variables in the disableParms() method which is likely to be a bad idea. I'm guessing that you're only assigning them in your cookMySop() method which might get called AFTER disableParms(). Or worst yet, your sop hasn't cooked yet and so they contain garbage values. Try re-evaluating the parameters in your disableParms() to determine what should be enabled.

[Guest xionmark]

You're using these member variables in the disableParms() method which is likely to be a bad idea. I'm guessing that you're only assigning them in your cookMySop() method which might get called AFTER disableParms(). Or worst yet, your sop hasn't cooked yet and so they contain garbage values. Try re-evaluating the parameters in your disableParms() to determine what should be enabled.

15177[/snapback]

Hi Edward,

The member variables get initialized through the constructor, they're always good values. That's why I find it strange some parameters aren't always enabled when I would expect them to be. I've checked the return value of the various enableParm() calls too.

The thing is, it's not consistent ... yet the values that I monitor from the disableParms() calls are consistent.

--Mark

[edward]

The member variables get initialized through the constructor, they're always good values.  That's why I find it strange some parameters aren't always enabled when I would expect them to be.  I've checked the return value of the various enableParm() calls too.

15182[/snapback]

I don't know then. Perhaps you should only call enableParm() once per parameter within disableParms().

[George]

Also, I'm not sure if it will help with your update problem, but I would use the version of enableParm that uses the token rather than the parm index. It may expose a hidden index problem?

[Guest xionmark]

Also, I'm not sure if it will help with your update problem, but I would use the version of enableParm that uses the token rather than the parm index.  It may expose a hidden index problem?

15203[/snapback]

Hi,

That's a good idea, I'll try it this evening.

Thanks!

--Mark