Bug in VI Server activation

[Aitor Solar]

Maybe this is too easy to workaround to be considered a bug, but is annoying anyway.

This code activates the TCP interface to the VI Server, the only difference between the two cases (true and false) is the property order. In the development environment, both cases work fine. But in an exe, only the second one (first activate, then assign port number) works, the other reports using port 3363 (LV default port, IIRC) even if you have designed another one.

BTW, the INI file fot he exe is empty.

Saludos,

Aitor

[Mads]

This is not a bug, it's the established way LV decides the order in which to do things: If you have a property node it will execute the actions on it from top to bottom. All you have to do in the first case is to swap the positions of the properties.

QUOTE (Aitor Solar @ Jul 15 2008, 12:06 PM)

Maybe this is too easy to workaround to be considered a bug, but is annoying anyway.

This code activates the TCP interface to the VI Server, the only difference between the two cases (true and false) is the property order. In the development environment, both cases work fine. But in an exe, only the second one (first activate, then assign port number) works, the other reports using port 3363 (LV default port, IIRC) even if you have designed another one.

http://lavag.org/old_files/monthly_07_2008/post-1450-1216115877.jpg' target="_blank">

BTW, the INI file fot he exe is empty.

Saludos,

Aitor

[Aitor Solar]

QUOTE (Mads @ Jul 15 2008, 02:10 PM)

This is not a bug, it's the established way LV decides the order in which to do things: If you have a property node it will execute the actions on it from top to bottom. All you have to do in the first case is to swap the positions of the properties.

I know, but that doesn't explain why it works in the development environment and not in the executable. And I can't see why it shoudn't work, anyway: first I set the port I want to use (while the server is off) and then I activate the server through that port. In fact, seems to be more logical for me than the other way (first activate the server through a default port and then changing that port). What if there's already some application using the default port? It will launch an error before you can change that port to avoid conflicts.

Saludos,

Aitor

[LAVA 1.0 Content]

QUOTE (Aitor Solar @ Jul 15 2008, 08:17 AM)

I know, but that doesn't explain why it works in the development environment and not in the executable. And I can't see why it shoudn't work, anyway: first I set the port I want to use (while the server is off) and then I activate the server through that port. In fact, seems to be more logical for me than the other way (first activate the server through a default port and then changing that port). What if there's already some application using the default port? It will launch an error before you can change that port to avoid conflicts.

Saludos,

Aitor

I don't have a good reply but here are my first thoughts.

IN the dev env the port may already be active for LV reasons.

Set "ignore errors inside node" to let the property node complete before returning the error.

Done thinking,

Ben

[Yair]

I ran into this a while back and reported it using the beta mechanism. If I remember correctly, it was considered a bug (the default values being used when the server is enabled), but I don't have access to that information at the moment.

[shoneill]

QUOTE (Yair @ Jul 15 2008, 05:14 PM)

I ran into this a while back and http://forums.lavag.org/-t11036.html&view=findpost&p=46464' target="_blank">reported it using the beta mechanism. If I remember correctly, it was considered a bug (the default values being used when the server is enabled), but I don't have access to that information at the moment.

I would agree with the bug nomenclature....

The port should be settable regardless as to whether the server is active or not.

Shane.

[Yair]

QUOTE (shoneill @ Jul 15 2008, 06:16 PM)

The port should be settable regardless as to whether the server is active or not.

Just to nitpick, the problem isn't with the port number not being settable but with the default values overriding the set values when the server is enabled.

[Rolf Kalbermatter]

QUOTE (Yair @ Jul 15 2008, 10:58 AM)

Just to nitpick, the problem isn't with the port number not being settable but with the default values overriding the set values when the server is enabled.

It's definitly wrong!

I would be not surprised at all if the first order wouldn't work as it is not a common feature for a server to change it's port number after it has started. But that setting the port and then starting does not work is really doing things backwards

RolfKalbermatter