isAnswer() use with dpConnects to disconnected dist systems

Discussions about product bugs & problems!
Note: This is no replacement for the Official ETM Support!
3 posts • Page 1 of 1
tpjctrl
Posts:145
Joined: Tue May 08, 2018 10:30 am

isAnswer() use with dpConnects to disconnected dist systems

Post by tpjctrl »

I've spotted a strange behaviour, although maybe this is simply by design, then again it might cause someone issues, so I'll mention it here.

Let's assume you have a control script like this:

main()
{
dpConnect("callBack", "DIST1:var1.VALUE", TRUE);
}

void callBack(string dp, bool val)
{
if(isAnswer())
{
// initialise some variables
}
else
{
// do normal callback things
}
}

Now let's assume you start this script when DIST1 is offline - this works fine, the dpConnect returns a 0, but the WantAnswer = TRUE doesn't result in anything as the dist system is offline, so nothing happens apart from registering the dpConnect. Let's then assume that the dist system comes back online - this will cause the dpConnect to get triggered, but this time around it will execute the callback function but only the lower part inside the "else".

To me the above isn't exactly right as the callback function runs for the first time when the dist system comes back online, shouldn't the isAnswer() return a 1 in that first trigger after DIST1 comes back online?

Btw it's pretty simple to bypass this issue by simply creating an initialise flag and checking that at the start of the callback (then setting the flag inside the "initialise" section), but a lot of times isAnswer() is used without giving much though to what happens with dist systems connecting / disconnecting and it can lead to loads of issues if this behaviour is not known.

tpjctrl
Posts:145
Joined: Tue May 08, 2018 10:30 am

Re: isAnswer() use with dpConnects to disconnected dist systems

Post by tpjctrl »

OK so after doing a bit more testing, it's the WantAnswer bit which is actually causing the strange behaviour. If it's TRUE the dpConnect is triggered whenever the DIST1 system comes back online - now this in itself is odd, why would this happen? there's no change in the "tracked" (by the dpConnect) value, there's no changes to the timestamp. I kind of understand it triggers because the dpConnect is re-registered with the DIST1 now being back online, but then if that's the case, the isAnswer() should return TRUE on that particular execution (assuming the dpConnect was initially registered when DIST1 was offline).

If WantAnswer is set to FALSE, the dpConnect doesn't get triggered regardless of the DIST1 being online / offline, the dpConnect will only react to proper dp changes.

leoknipp
Posts:2928
Joined: Tue Aug 24, 2010 7:28 pm

Re: isAnswer() use with dpConnects to disconnected dist systems

Post by leoknipp »

A dpConnect() to a distributed system currently not connected will only work if the DP identification for the remote system is already loaded.
To check if a the dpConnect() really worked or not you have to call getLastError().

Possibly the function you are looing for is isRefresh() and not isAnswer().
isAnswer is only "TRUE" for the first time after calling the dpConnect().

Best Regards
Leopold Knipp
Senior Support Specialist

3 posts • Page 1 of 1