Table Relations - Search Function

[ptc-5176406]

Pro/E WF4.0 M220

Syntax:

IF search(ASM_MBR_PARAMETER,"string")>0

statement

ENDIF

Error:

Invalid data type combination at left side of expression

As far as I can tell, this is a limitation of Pro/E (or at least the build I am using). The parameter is a string and I can use the extract function, but any search function using a parameter as the argument always returns an errror. Any help would be greatly appreciated!

This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

[James62]

Try the following syntax:

SEARCH_PARAM=search(asm_mbr_user_parameter,"string")

IF SEARCH_PARAM>0

statement

ELSE

statement otherwise

ENDIF

The first line of the code, the assign operation, cannot be declared upfront somewhere in the top of the relations. This is important, You should define this kind of assign operation right before the if statement where you use the conditional with the parameter that comes from this assign operation, else you might get the same error you get above.

In report table relations, conditional operators such as <, >, ==, <> cannot be used along with system parameters such as asm_mbr_name, asm_mbr_type, etc. You have to first make a copy of those by assigning them to another param.

Make sure you only work with one system parameter such as asm_mbr_name at a time, and then close it with ENDIF before working with another. IF statements can be stacked one into another, but I doubt stacked IFs will ever work with conditional operators as said above.

[ptc-5176406]

Thank you for the help Jakub.

I had tried declaring a separate integer parameter as the result of a search function prior to posting without success. After reading your post I attempted assigning a parameter again hoping that I had just made a syntax error the first time.

Unfortunately, I still receive the same error message (indication that ASM_MBR_PARAMETER, which is a string, is not a compatible data type for the search function). Even defining a string parameter within the repeat region relations that is equal to the ASM_MBR_PARAMETER and attempting to search the new table parameter results in an error.

I am starting to believe that searching a string parameter is not possible in table relations.

[James62]

It is possible. I do have a relation to find underscorer in the asm_mbr_name parameter in my repeat region relations.

This relation works on Creo Parametric 2.0 M020, but not on M030, M040, M050, M060 because it is bugged there. It's supposed to be fixed in Creo Parametric 2.0 M070.

This same bug happened to be in some of the Wildfire 4 subversions, which goes about 7 years back, but it was propably resolved back then. I'd think it was resolved in the latest WF4 subversions which i guess is M220. It has just leaked in Creo 2.0 M030 somehow.

I do have WF4 M220 at work, but I can't even figure out how to add a model to a drawing there. It's just so different compared to Creo 2.0.

If you can build some dummy assembly with a dummy assembly drawing to test this issue then maybe I can help you out. It really shouldn't be that hard.

[ptc-5176406]

I've attached a zip file containing a drawing with the associated assemblies & parts.

The DESCRIPTION parameter has been added to all parts & sub-assemblies and is shown in the repeat region. In the relation code, I'm trying to look for a specific string & adjust another parameter accordingly. What I'm actually trying to accomplish is a bit more complicated, but this is just an example of the search function not working.

Thanks a ton for helping me with this headache!

[James62]

Good, I took your example repeat region relation:

POSITION=search(asm_mbr_description,"SUB")

IF POSITION>0

QUANTITY="--"

ELSE

QUANTITY=rpt_qty

ENDIF

And then changed asm_mbr_desctiption to asm_mbr_name, and the relation verified succesfully.

So you could use this kind of relation:

POSITION=search(asm_mbr_name,"SUB")

IF POSITION>0

QUANTITY="--"

ELSE

QUANTITY=rpt_qty

ENDIF

But only if you are going to follow some sort of model naming convention that can always tell what models in your assembly are sub-assemblies. This might work if you are just trying to exclude the quantity in the resulting assembly component list (repeat region).

Or are you trying to do something else? I am not sure.

Anyway, as you can see, the search function in repeat region does not work for user defined parameters pulled from assembly models, such as asm_mbr_description, or DESCRIPTION on the model level. This function only works for system params like asm_mbr_name. That means you propably can't have the repeat region alone to care about all of your assembly parameters as you would like. I've tested your relation on both Creo Parametric 2.0 M020, and Pro/E WF4 M220, and it works as you describe, so this is propably not a bug.

Well, should I check Creo Parametric 2.0 M070 since I know PTC devs were messing with repeat region relations lately? I should, but that still won't make any difference for you as you are on WF4.

I don't know if you have to have this kind of DESCRIPTION parameter, and if you wouldn't be ok just with naming the sub assemblies in some sort of appropriate way so that your repeat region alone would be able to process it as you would like. If you really need to have this user defined DESCRIPTION parameter, and the resulting QUANTITY based of off that, then you could add a relation to all your parts, and subassemblies like this:

IF search(DESCRIPTION,"SUB")>0

SUB_PREFIX_CHECK=true

ELSE

SUB_PREFIX_CHECK=false

ENDIF

Part and assembly relations can handle the search function with no problem. Then you can modify your repeat region relation of the top level assembly drawing as shown on the following picture:

I am simply using a true or false check to either existing or not existing assembly parameter there, which seems to work as you can see on the picture.

There's a bunch of variations to both of these solutions, and I guess you are deep enough in this to know what you are really after. If you are still unsure about something, then let me know, and I can try to explain further.