I'm using a number of Client tags to keep track of certain aspects of system operation, such as the type of product being worked with at each node. I've noticed that if there are clients running and a developer saves the system, all the Client tags are reset to whatever value they are currently set to in the Designer.

Is there any way of suppressing this functionality? At the moment, saving the system while clients are running means that the system loses track of where it is, forcing the users to log out then back in again.

This is true, the client tags, being part of the project, will get updated on a save. I think we should add some logic in the client to retain their client tags' current values on a hot-update. Of course, this is going to have frustration-inducing effect on the other end - when you have client tags that are constants and you effectively can't change them until you log out of a client and log back in...

Well, without being in any way biased , I would vote for retaining client tag values on a hot-update. I reckon it would make most sense that client tags which are constants should be set in the Client start script or would remain uninitialised. Client tags in the Designer would remain local to the Designer. Is this possible?

The client startup script doesn't run during a hot-update. Not sure what you meant about tags remaining local to the designer...

Tags not specifically set in the client assume the value set in the Designer when the project was last saved. This means that you can be doing some testing in the Designer and save the project, unintentionally sending the values of the tags in the Designer out to every running client.

I think it would be nicer if the values in the Designer didn't affect the clients - this is what I mean by values remaining local to the Designer.

Although the client startup script doesn't run during a hot-update, when a client first runs the value of constants will need to be set somewhere - the client startup script seems the obvious place.

Taking the concept of least surprise...

The definition of client tags is that they are local to the client. I think it's fair to expect the designer to act as a client.

I like the idea of the startup script been required to initialize any tags that require it.

Ok so it sounds like the following would be a decent policy:

On a hot-update, client tags get the following treatment:
1) Any new client tags get added with the value last seen in the Designer
2) Any deleted client tags get removed
3) Any client tags whose value has ever been changed during the client session retain their value.
4) Any client tags whose value has not been changed receive the last value seen in the Designer.

So setting constant values in the client startup script would in effect override the values in the Designer (and would cause any future changes to the values in the Designer to be ignored)? In this case I think you scheme sounds ideal

This is done for the next release (7.1.5)

Hi Carl,

I've now tested this functionality in version 7.1.5 (with Windows XP, Java 1.6.0_21) and it doesn't seem to work properly. As a test I initialised a number of [Client] variables in the Client Startup Script and displayed their values on a window in the client. When I first saved the project in the Designer, the value of these variables did not change.

However, when I saved the project a second time, the values of the variables were all overwritten by the values set in the Designer.

Yep, you're right. It has been fixed for the next release.