Why doesn't this logical syntax work?


#1

Further adventures with my lineitemarray conundrum. Here is some actual code:

local CodeArray, idx

CodeArray=lineitemarray("Item CodeΩ",cr())         //performs correctly

idx = 1
if "AT-12ATP-12FT-8FTP-8" contains «Item CodeΩ»    //do any of the Item Codes match any of these?  (this test returns True)
    Loop                                           //therefore, process each line to populate some other arrays for further processing
        message "match: "+array(CodeArray,idx,cr())    //this returns "match: ATP-12"
        if "AT-12ATP-12FT-8FTP-8" contains array(CodeArray,idx,cr())    //but this fails!

That last line should be the equivalent to

 if "AT-12ATP-12FT-8FTP-8" contains "ATP-12"

but it doesn’t interpret it that way - it evaluates as False, and the whole procedure falls apart.


#2

That logical syntax should work. How did you determine that it didn’t?


#3

This statement here is suspect, but it did evaluate as true, or you would not have gotten to the message.

«Item CodeΩ» will be a specific code, depending on which field is currently active, so you are not testing to see if any match any. You are testing to see if any match this.


#4

Because the code following it in that IF block was bypassed.

I was thinking that as I looked over my code (I wrote it a long time ago), but that test has always led to the correct interpretation in Pan 6. That part may require improvement, but I don’t think it is influencing the other issues.


#5

This still leaves me wondering how you know it was bypassed. Clearly you were expecting it to do something that you aren’t seeing it do, but I don’t know what that is. I don’t know if it’s possible that an error in that code is leaving you with the false impression that it was never reached.


#6

There are some more assignments, and message statements to go with them, that never happen. Code following the Loop fails because nothing happened inside the loop (the IF block never did anything).


#7

Try this to see if it is True or False

If “AT-12ATP-12FT-8FTP-8” contains «Item CodeΩ»
Message "True"
Message «Item CodeΩ»
Else
Message "False"
Message «Item CodeΩ»
EndIf

Robert Ameeti


#8

Robert: In my sample record, which has an ATP-12 on one line and FTP-8 on the next, both return True, with the correct ItemCode. No surprise there, but I may have discovered something.

Seems like evaluating the array on the fly isn’t working so well. I modified the IF statement after the Loop statement like this:

local xtemp
Loop
    xtemp = array(CodeArray,idx,cr())
    message "match: "+xtemp           //returns correct value
    if "AT-12ATP-12FT-8FTP-8" contains ytemp

this works - statements after the IF statement do execute. Does the message statement corrupt something in the array itself? This was also not working before I put the message statement in.

Found another 6->X anomaly. Part of what happens inside the IF block is to evaluate the price of each item (an array was constructed of the prices earlier, not shown here for simplicity sake). The prices were “money type” in 6, and they carry a “$” as part of the value in X. Guess what, val( of the prices come out to zero, instead of 27.00 or whatever. Easily fixed with stripchar(, but it’s another place where X just doesn’t do things the expected way. I feel like the bomb-sniffing dog sometimes…


#9

I would like to point out my typo in the above code; I typed it into this editor rather than copy/pasted from my actual code. The variable in question is xtemp, where it says “ytemp” it really means “xtemp”. And this code works.

But I remained puzzled as to why this:

if "AT-12ATP-12FT-8FTP-8" contains array(CodeArray,idx,cr())

returns false in all cases, and this:

xtemp = array(CodeArray,idx,cr())
if "AT-12ATP-12FT-8FTP-8" contains xtemp

returns true (when it is in fact true). Is there a known issue here that I need to watch out for, or is this a bug?

Also, I feel very blind without the Design sheet in X - I don’t know where to find out what data type my fields are. In 6 I defined many line items in my Invoice as “Money/numeric” but in my struggles with this procedure I discovered that unit prices were being interpreted by my procedure as containing a “$”, which is making them text type, and I have to strip the “$” to use val( to get their numeric values. Is this a side effect of converting from 6? I’d like to keep these items numeric, how do I change that in X? Does X have a type equivalent to Money in 6, so I can both display it as money but also calculate with it as a number without conversion? Or did something just go screwy in this case during the translation from 6?


#10

Click on the Properties pane in the toolbar and everything you need to know about a field is displayed:

But you can’t look at the properties of all fields at once, as was possible in P6.


#11

I would put a message array(CodeArray,idx,cr()) line in before the test to check that I was looking for what I thought I was looking for.


#12

It took me a bit to realize that you were doing this in the Data Sheet; doing it in a form doesn’t work. I rarely use the Data Sheet but now I know where to find this - thank you. So I find my lineitem field is Number(float), with an output pattern of “$#,.##”. So far, so good, looks just like money. But when I make a lineitemarray of this, the $ is included and I have to strip it if I want to use it as the number it actually is. And that doesn’t seem right (it didn’t do this in 6).

As to your next reply, you’ll see that I’ve done exactly this in code I quoted earlier. It is the “contains array(etc.)” that fouls it up; if I set a variable to that same array value, then use that variable instead, it works. And that sounds like a bug as well.


#13

That’s about the limit of my help Scott - I’ve never used line items and I don’t want to start now. I’ll punt this back to Dave or Robert.