How to correct custom code syntax error on flexsim 2017.

Question

question

Kari Payton asked Dec 21, '16 Phil BoBo edited Mar 22, '17

How to correct custom code syntax error on flexsim 2017.

In Flexsim 2016 my code works fine, but when I opened the model in 2017 I get the following error:

This is my code. The purpose is to offset operators around the workstation.

treenode current = param(1);
treenode activity = param(2);
treenode token = param(3);
treenode processFlow = ownerobject(activity);
/***popup:LabelArray:*/
/**Object from Label Array*/


#define LastEntry 2147483647


treenode involved = /**\nInvolved: *//***tag:involved*//**/token/**/;
int index = /**\nIndex: *//***tag:index*//**/getlabel(token, "OpNum")/**/;


Variant result = getlabel(involved, /**\nLabel: *//***tag:labelname*//**/"Operators"/**/);


treenode Op = NULL;


switch (getvartype(result)) {
	case VAR_TYPE_TREENODEARRAY: {
		treenodearray array = result;
		if (index == LastEntry)
			Op = array[arraysize(array)];
		if (index > 0 && arraysize(array) >= index) {
			Op = array[index];			
		}
	} 
}


setloc(Op, xloc(Op), yloc(Op) + (index - 1), 0);

Software Version:

Choose One

flexscript error

codeerror.png (33.4 KiB)

5 |100000

Attachments: Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Answer 1 · 2016-12-21T16:00:01Z

Sam Stubbs answered Dec 21, '16 Phil BoBo edited Mar 22, '17

The problem is 2017 has a new array type. So the old macro VAR_TYPE_TREENODEARRAY no longer is recognized. If you go to the user manual. (Help > User Manual) Under the "What's New?" section it explains.

The relevant passage is as follows:

"This version introduces a new Array type, which is an array of variants, enabling a more feature rich array usage. In doing this, we are deprecating the old array types of doublearray, intarray, stringarray, and treenodearray. Specifically, the old array types are now just aliases for the standard Array type. This means that you can now, technically, put a string into a doublearray and vice versa, because they are all just Arrays. Hence we encourage you to just use Array in your code instead of the old array types.

This change has also introduced a problem regarding the Variant type. In previous versions, the Variant could hold each of the four types of arrays, and it had a type value associated with each type, which you could get with the getvartype() command, comparing that value to one of VAR_TYPE_INTARRAY, VAR_TYPE_DOUBLEARRAY, VAR_TYPE_STRINGARRAY, or VAR_TYPE_TREENODEARRAY. Now, however, since we've merged all of those types into one, all of those values would theoretically be the same value, introducing issues if you had code that switches on getvartype(), or in some cases if you had a series of if/else compares on that value. Depending on the specific nature of that code, it would be hard to predict exactly how that code would behave going forward. Thus, we have decided to get rid of those old macros for each array type. Now there is just the macro VAR_TYPE_ARRAY.

If you have existing code that uses the older macros, you will get compile errors when you open your model in version 17.0. We do this specifically so that you will be notified of code that needs to be updated. There are also several pick list options in the process flow module that use these older macros. Version 17 includes update scripts that will hopefully update all of those pick options in existing models to use the new VAR_TYPE_ARRAY macro instead of the old macros."

So you just need to switch VAR_TYPE_TREENODEARRAY for VAR_TYPE_ARRAY.

· 2

5 |100000

Attachments: Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

David Chan commented · Mar 22, 2017 at 06:08 AM

@Sam Stubbs

Good day. I received complaints from customers that the changes should be done automatically especially when they upgrade model from 2016.

David

0 ·

Phil BoBo ♦♦ David Chan commented · Mar 22, 2017 at 03:51 PM

There is no way for us to know what the code needs to be changed to automatically, as explained in the note:

"Now, however, since we've merged all of those types into one, all of those values would theoretically be the same value, introducing issues if you had code that switches on getvartype(), or in some cases if you had a series of if/else compares on that value. Depending on the specific nature of that code, it would be hard to predict exactly how that code would behave going forward."

If you have custom code that uses these macros, then FlexSim can't determine what exactly your custom code needs to be changed to. The modeler needs to update them manually.

0 ·

question