numberfield synching problem

[meathome]

I wanted to simplify handling if a skill or ability is editable or not. I added a hidden number field to the windowclass for the item in the windowlist using the hn template. This number has a default value of 1 and is called iscustom. This numberfield updates read only status and visiblity for other elements in the window in its onValueChanged() function.
The windowlist has an onDrop function that adds a new entry and sets this numberfield to 0 for the entry. The idea is that items manually added to the list will have the default iscustom value of 1 and thus editable fields while items dropped on it will have an iscustom value of 0 and read only fields.
This works as expected as long as it all happens on a single machine, but as soon as a client is involved it gets strange. When a client drops a skill on the list it will be editable on the client side and read only on the gm side. When the gm drops a skill on the list it will be editable on the gm side and read only in the client side.
It seems like I have some big logic issue in the way I want it to work but am unable to work out why it behaves in this way.

[Zeus]

Are you setting the fields to be editable/non-editable in the onInit() function of the list or the entries themselves? If not, this maybe causing the issue your experiencing. If your only setting the read-only states during onValueChanged() this will only fire on the session that drives the change. I guess you want to check the hn field for 0 or 1 and then set fields editable appropriatley as soon a the window is opened, this should then trigger when other clients/users open the window on other clients.

Also depending upon underlying database node ownership, only the creator of the node will be able to edit as only that user will own the database nodes, regardless the GM should always be able to read/write database nodes regardless of ownership.

[meathome]

Thanks for the reply. I was also calling the update function in onInit() just forgot to mention it.
I discovered the reason and find it really strange. If I set a default value with <default>1</default> then the issue happens. I removed the default value and changed it so that the entry is set to custom on a value of 0 and suddenly it works. I dont really understand why. It is as if the default tag causes the number value to change to the default value on the other side of the network connection after the entry is received....
But at least it works as I intended now.

[Moon Wizard]

The challenge with the "default" tag is that the default only applies to the control creating the object. So, if another if the value is accessed by any other control without the same default tag, then you can end up with some interesting disconnects. I had to track down an item identification issue not that long ago, related to this.

Regards,
JPG