Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 356420

Summary: Grace setters not called for params object used for a new instance
Product: [Technology] RTSC Reporter: Missing name <connell>
Component: CoreAssignee: Dave Russo <d-russo>
Status: CLOSED INVALID QA Contact:
Severity: normal    
Priority: P3    
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Case A screen shot
none
case b screen shot
none
xdc file
none
grace page
none
xs with setters none

Description Missing name CLA 2011-08-31 20:54:51 EDT
Build Identifier: 3.22.1.21

This problem was seen with the following:

xdc tools 3.22.1.21

BIOS 6.32.3.41

CCS 4.2.4.00031 

NDK 2.21.00.01 (with additional modifications to checked in version, however).

This problem is happenine for an NDK Telnet module which has instance variables that are co-dependent and use GetSet.onSet() to keep them in sync. (The Telnet module is meta only, and so does not support internal variables)

I have a Grace view that uses a set of 4 checkboxes that allow the user to enable/disable certain features for their telnet server.  This works by having a setter function map to each check box.  The setter fxn then updates a "flags variable" (called "mode"), which stores the result of OR-ing all of the check boxes together.

There is also a setter for the opposite case - if the user updates the 'mode' variable, a setter is called so that the checkboxes reflect the same value that was set for 'mode'.

However, there is one case in which the value of 'mode' and the check box flags can become out of sync; this is when the 'mode' and 'flags variables' are incosistently set within the Telnet.params() object.

Here's the code (Case A):

	var telnet0Params = new Telnet.Params();
	telnet0Params.IfIdXValid = true;
	telnet0Params.mode = 11;
	telnet0Params.CallByIP = false;
	telnet0Params.RestartIPTerm = true;
	telnet0Params.ResolveIP = true;
	var telnet0 = Telnet.create(telnet0Params);

In the above code, I would expect setting CallByIP, RestartIPTerm, ResolveIP (the check box variables) to these values to cause 'mode' to be set to 14, since changes to these variables are tied to a setter which updates mode.  However, this does not happen, mode is out of sync with the check boxes.

The following code does work, however (Case B):

    telnet0.mode = 5;

The following code *does not* work! (check boxes still out of sync):

telnet0.IfIdXValid = true;
telnet0.ResolveIP = false;
telnet0.CallByIP = true;
telnet0.RestartIPTerm = true;

It seems that the setters do not run for when the params values are assigned to the actual instance object?

see attachments for screen shots and files to reproduce.



Reproducible: Always

Steps to Reproduce:
install ndk, BIOS and XDC versions mentioned above.

may need to use attached files for ti.ndk.config package - Telnet.*

open attached *.cfg file.  May need to comment out other components not needed (UIA, etc.) if those aren't installed.
Comment 1 Missing name CLA 2011-08-31 20:55:45 EDT
Created attachment 202572 [details]
Case A screen shot
Comment 2 Missing name CLA 2011-08-31 20:57:58 EDT
Created attachment 202573 [details]
case b screen shot
Comment 3 Missing name CLA 2011-08-31 20:58:28 EDT
Created attachment 202574 [details]
xdc file
Comment 4 Missing name CLA 2011-08-31 20:58:42 EDT
Created attachment 202575 [details]
grace page
Comment 5 Missing name CLA 2011-08-31 20:58:59 EDT
Created attachment 202576 [details]
xs with setters
Comment 6 Dave Russo CLA 2011-09-02 21:24:54 EDT
This looks like its a bug.  Try changing *.xs from
    /* Run them once to ensure mode and check boxes are initialized */
    updateModeFlags("mode", this.mode);
    updateCheckBoxes("mode", this.mode);

to
    /* ensure mode and check boxes are consistently initialized */
    updateCheckBoxes.call(this, "mode", this.mode);

The calls to updateModeFlags() and updateCheckBoxes() are broken because these functions reference "this" to do their work.  When you explicitly call such functions you need to make sure that the this pointer is properly set.  In your case, the "this" pointer refers to the capsule object rather than the instance object that you intended.
Comment 7 Dave Russo CLA 2011-11-09 18:55:45 EST
closing "ancient" resolved bugs