• State Not Answered
  • +1 person also asked this people also asked this
  • Replies 4 replies
  • Subscribers 14 subscribers
  • Views 204 views
  • Users 0 members are here
Options
Related

Setting .Description / .DescAttrName / .ShortDesc in scripting

Richard Köhlerstrand

Hi, 

As Language support on Objects was introduced in Application Server it will no longer allow for scripts to write to .Description of a object attribute.

As we have several customers with solutions where this is used in different ways (and for different reasons) we explored a workaround for this.

So the following will not work anylonger and data will not change in runtime

MyValue.Description = "This is nice";

Reason for this is that the .Description is now an datatype InternationalString.

The only workaround we have found so far is to change the Type of the primitive back to MxString, ie in OnScan of the Object.

This will allow for runtime updates from scripts in new versions.

The effect of the Type change is that Initial value is lost (Empty until set script executes), but we can now update the Description

The following will fix the issue of Empty, but it means that Initial value set in design time is discarded.

I would expect same applies to any non referenced description, such as .DescAttrName

Here the workaround seem to break down some. and a normal case is that .DescAttrName (Alarm description) is set to Me.MyAttribute.Description

Result is that it will use the design time value, and not update in runtime.

What I'm looking for is a way to set the description in a proper way in runtime.

I was trying the following without any success.

Since we have at least five customers at the moment where this is an issue, I would like to explore if anyone here has any experience in resolving this change in behavior?

Parents
  • 0

    I think a runtime equivalent of PutInternationalString(lcid, value) will be required but I'm not sure if something like that is available or not.

    Just setting the text like a normal string will not do, since it is quite common to see applications where the server (or the AppEngine credentials to be specific) is running with a different locale than that of the clients, which can cause all kinds of confusion. You probably need to have one line of script to update each locale supported by the specific application. Come to think of it, it could perhaps be useful if one could submit a collection of lcid/text pairs to a method and sett multiple locales in one shot.

    For sure, using GRAccess to set the attribute value will require that you also deploy changes to the affected object which seems contraproductive and using GRAccess in runtime is potentially problematic in terms of messing with default values. Sorry, I know you've heard my rant about runtime GRAccess many times before Smile

  • 0 in reply to rickard.norin

    Perhaps there are some unknown workaround for this, to many times there has been something that's impossible, If you ask, but after finding the right Aveva person/Engineer, it has been a known workaround for years.

    Yes, I'm thinking of BigString where it was officially "impossible", but you found solutions here and there where someone got a tip where setting your string to MyStringAttribute.Type = "MxBigString" just worked Slight smile

    I understand that an "Official answer" packs a better punch and comes with some responsibility from Aveva, but that's why I'm asking here on the forum. where we are known to make the impossible, possible.

    As mentioned, we have several installations out there where logic helps us make our solution more dynamic, setting .Description / .DescAttrName / .ShortDesc using scripting.

    All these solutions has to be re-built if the customer upgrades, and they are turning to us for a workaround, when waiting for the next version where a fix might be available is not possible.

    So that's why we are looking for creative ways of keeping the dynamic part and still upgrade.

    And I totally understand that any work-around, other than finding a way of setting the string in all possible languages will break the newly introduced feature of language switching on objects.

    But we have customers that has been using this method since version 2.1 without any indication of that this could be a problem.

Reply
  • 0 in reply to rickard.norin

    Perhaps there are some unknown workaround for this, to many times there has been something that's impossible, If you ask, but after finding the right Aveva person/Engineer, it has been a known workaround for years.

    Yes, I'm thinking of BigString where it was officially "impossible", but you found solutions here and there where someone got a tip where setting your string to MyStringAttribute.Type = "MxBigString" just worked Slight smile

    I understand that an "Official answer" packs a better punch and comes with some responsibility from Aveva, but that's why I'm asking here on the forum. where we are known to make the impossible, possible.

    As mentioned, we have several installations out there where logic helps us make our solution more dynamic, setting .Description / .DescAttrName / .ShortDesc using scripting.

    All these solutions has to be re-built if the customer upgrades, and they are turning to us for a workaround, when waiting for the next version where a fix might be available is not possible.

    So that's why we are looking for creative ways of keeping the dynamic part and still upgrade.

    And I totally understand that any work-around, other than finding a way of setting the string in all possible languages will break the newly introduced feature of language switching on objects.

    But we have customers that has been using this method since version 2.1 without any indication of that this could be a problem.

Children
No Data
© 2024 AVEVA Group Limited or its subsidiaries. All Rights Reserved.