Jump to content

ProCap greater than or equal operator issue


chrisnutt

Recommended Posts

Hi,

I am showing a member of my team how to set up Progressive Captures and we have come across a bit of an issue. We were doing a silly ProCap (zTO be deleted - Rob Training) to show what the system can do. It's about Liverpool players, as he supports Liverpool (he is good at his job though, to be fair). We set up a question about shirt numbers in to the custom field h_custom_26 (for integers) and had a branch go off in two directions. For shirt numbers less than or equal to 11, go here (first team). For shirt numbers equal to or higher than 12 go there (squad). We put in Mo Salah, shirt number 7. But it keeps going off to the squad node. We've both double checked that we're using the right operator for greater than or equal to (>=) and less than or equal (<=).

What's going on? Is there something we're both missing?

Chris

Link to comment
Share on other sites

Hi @chrisnutt

Sorry, I hope you don't mind me asking for a bit of clarification.  Is your decision node that you are trying to set up the branching on in Progressive Capture or the BPM?  You mentioned a field called h_custom_26 which sounds like a custom field on a request which would suggest that you are trying to do the decision node in the BPM.  As a request is not created until the end of progressive capture has completed and successfully raised a request, a field such as h_custom_26 wouldn't be available in Progressive Capture. 

Regards,

James

 

Link to comment
Share on other sites

Hi @James Ainsworth

No worries, clarify away! We're setting up a Progressive Capture. I mention the custom field as I thought someone might ask if the field was an integer.

Obviously, this isn't urgent as we're talking about something we discovered in a training session. But it could affect us some point down the line.

Chris

Link to comment
Share on other sites

1 hour ago, chrisnutt said:

It's about Liverpool players, as he supports Liverpool (he is good at his job though, to be fair)

Apologies, but are you looking to get some help here or am I missing something? Because... with that statement... hmm...  :P :D  

Link to comment
Share on other sites

Just now, Victor said:

Apologies, but are you looking to get some help here or am I missing something? Because... with that statement... hmm...  :P :D  

Hmmmm, I'm not sure how to take being mocked about my football team before I've even posted on this forum :P !

Link to comment
Share on other sites

Thanks, @James Ainsworth

I understand that the field type doesn't really apply at this stage. But that still doesn't really address the issue. We have a progressive capture where someone is putting in a value of 7 for "shirt number" and a branch node with a custom expression that says if "shirt number" is less than or equal to 11 go to the first team node else if "shirt number" is greater than or equal to 12 go to the squad node, but the progressive capture takes them to the squad node. See screenshots if I am not being clear. I fully expect to discover I'm doing something silly.

@Victor I support Reading so draw your own conclusions... :)

Chris

 

First screenshot is at the bottom.

playerdetails6-procap.png

playerdetails5-squad.png

playerdetails4-firstteam.png

playerdetails3customexpression-squad.png

playerdetails2-customexpression1-11.png

playerdetails1-shirtnumber.png

Link to comment
Share on other sites

17 minutes ago, RobW said:

Hmmmm, I'm not sure how to take being mocked about my football team before I've even posted on this forum

Ahem... where was it... ah yes, here:

 image.png

So, first place errr.. nope...second then! .. err...nope...  ok, must be third, podium still, right!!!... oh, wait...  :P 

 

 

@RobW @chrisnutt - if you try a hard match (e.g. Shirt Number = 7) does that take you to the correct path? Wondering if the custom field values are treated as characters instead of numbers...
 

Link to comment
Share on other sites

@chrisnutt right, I can confirm now that the values are considered strings, not numbers, this is why it does not work how you/we would think it would... when using comparison operators (e.g > or <) with strings they are evaluated in alphabetical order. So, for example, with strings/characters, "2" is greater than "11" because, alphabetically, "2" comes after "11" ... So, the way you can try the PCF (and it should branch as needed) is if you put a zero in front of single digit numbers: 

image.png

Link to comment
Share on other sites

Thanks @Victor

I'm glad I wasn't being silly! I was thinking along these lines originally

Is this something worth looking at? Perhaps creating a field for numbers?

Certainly, something for us to keep in mind for now, though.

Thanks for your help.

Chris

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...