Using a Variable in a Calculation

[akappy]

I have a looping script to extract a series of words from some raw text.

Sample Text:

tagWORDtag2

tagWORD2tag2

tagWORD3tag2

I should be able to extract, WORD, WORD2 and then WORD3 in three iterations of the loop.

I set the variable "$num=$num+1" before each iteration.

I am trying to use a calculation to extract the text as follows:

Middle (

Fieldname ;

Position ( Fieldname ; "tag" ; 1 ; $num) +3;

Position ( Fieldname ; "tag2" ; 1 ; $num) - Position (Fieldname ; "tag" ; 1 ; $num)-3

)

The first iteration does get the first occurrence, "WORD", each additional iteration is returning a blank.

Any suggestions?

[comment]

AFAICT, the calculation in your example fails because the word "tag" is contained in "tag2".

However, it DOES return a result when $num is greater than 1, so I guess your example doesn't fit your real data.

[akappy]

The calculation has no trouble with "tag" vs "tag2" and this is a fair representation of the actual data. If I use a specific number, ie. 1, 2 or 3, instead of $num, it works correctly and extracts WORD, WORD2 or WORD3 respectively. My only issue is getting the variable to work.

I am actually parsing a short XML file as I do not have the skills to build an XSLT to import using XML functionality. The real tags look more like and . All other aspects of the parsing work correctly.

[Fitch]

As Michael points out, it's going to fail because the +$n occurrence of "tag" is going to be found in "tag2."

If you really want to work out the problem, I'd use a Let statement to clarify the calc, or create separate variables that you could watch in the Data Viewer.

If you just want to get your project done, I recommend this Custom Function.

[comment]

The real tags look more like and .

Well, then the example is NOT "a fair representation of the actual data". We don't have a crystal ball here, we only know what you choose to tell us. Very often, "looks like" is far enough from "is" to make a significant difference.

You didn't post the actual script either. Since the calculation (as far as I can tell from the description) should work, I am guessing the problem is with setting the variable. Again, I don't know how literally to take what you write:

I set the variable "$num=$num+1" before each iteration.

This could be read in a number of ways. If the variable $num has the value of 1, and you really set it to $num=$num+1 then the resulting value will be 0 (False).

[comment]

I recommend this Custom Function.

I wouldn't.

[akappy]

Comment and Fitch, thanks to you both. You've given me a lot to chew on, I'll work with these suggestions and let you know how I make out.

Andy

[akappy]

Still no joy. Whether I use my original calculation (single variable), the two variable version, or the custom function, I only get exactly as desired if I put an actual number for the Occurrence in the Position function. If I use 1 I get "firstpdf", if I use 2, I get "secondpdf". That works just fine. However, if I try to use the variable, $pdfnum or $$pdfnum, I get the first instance just fine in $$insert, the rest return a blank to $$insert, which I'm watching in Data Viewer.

In the script example below Line #16 (and disabled #17) are the lines of interest. Line #17 was my last sample of the calculation using separate variables for the start and end positions. Line #16 is using the custom function from NRGSoft, which I've named ExtractXML.

Here is a snippet of the XML source which is imported into the field: "BaseImportXML::RAW Text".

-------------------------

24517

CT

13

2

15

TEST

True

firstpdf

secondpdf

first insert

second insert

third insert

fourth insert

fifth insert

-----------------------

Here is the relevant portion of the script:

------------------

1 • Go to Layout [ “BaseImportXML” (BaseImportXML) ]

2 • Perform Find [ Specified Find Requests: Find Records; Criteria: BaseImportXML::InsertFlag: “0” ] [ Restore ]

3 • Go to Record/Request/Page [ First ]

4 • Loop

5 • Set Variable [ $$orderid; Value:BaseImportXML::OrderID ]

6 • Set Variable [ $$totalquantity; Value:BaseImportXML::TotalQuantity ]

7 • Set Variable [ $$ordinal; Value:1 ]

8 • Set Variable [ $pdfnum; Value:1 ]

9 • Set Variable [ $pdfnum2; Value:1 ]

10 • Set Variable [ $$insertnum; Value:1 ]

11 • Set Variable [ $$date; Value:BaseImportXML::EntryDate ]

12 • Set Variable [ $$pdfcnt; Value:BaseImportXML::PDFCnt ]

13 • Set Variable [ $$insertcnt; Value:BaseImportXML::InsertCnt ]

14 • #Get PDFs

15 • Loop

16 • Set Variable [ $$insert; Value:ExtractXML ( BaseImportXML::RAW Text ; "PDF" ; 1 ) ]

17 • // Set Variable [ $$insert; Value:Middle ( BaseImportXML::RAW Text ; Position (BaseImportXML::RAW Text;"";1;$pdfnum)+5; Position (BaseImportXML::RAW Text;"";1;$pdfnum2)-Position (BaseImportXML::RAW Text;"";1;$pdfnum)-5) ]

18 • Go to Layout [ “Inserts” (Inserts) ]

19 • New Record/Request

20 • Set Field [ Inserts::OrderID; $$orderid ]

21 • Set Field [ Inserts::Insert; $$insert ]

22 • Set Field [ Inserts::Ordinal; $$ordinal ]

23 • Set Field [ Inserts::Type; "PDF" ]

24 • Set Field [ Inserts::DateStamp; $$date ]

25 • Set Field [ Inserts::PageCount; 4 ]

26 • Set Variable [ $pdfnum; Value:$pdfnum+1 ]

27 • Set Variable [ $pdfnum2; Value:$pdfnum2+1 ]

28 • Set Variable [ $$ordinal; Value:$$ordinal+1 ]

29 • Exit Loop If [ $$pdfnum>$$pdfcnt ]

30 • End Loop

---------------------

[comment]

Shouldn't you go back to the BaseImportXML layout before setting the variable $$insert?

[Fitch]

Andy Knasinski's a pretty smart guy - what is it you don't like about his custom function? I've used it and it works as advertised.

[akappy]

That did the trick. I was not returning to the BaseImportXML table when I should have been. Problem solved.

Any suggestions on a better way to create these records in the Inserts table? I thought about using a Portal, but I don't see how to script a new record in the Portal

Thanks,

Andy

[comment]

I see no advantage in using a portal, on the contrary. Ever since $variables became available, the simplest and most straightforward method is to load the values you need, go to the other table, create a new record and set the fields to the variables.

[akappy]

Thanks once again.

[comment]

Andy Knasinski's a pretty smart guy - what is it you don't like about his custom function? I've used it and it works as advertised.

How much time do we have? :

To start with, there is a big difference between an XML element and an XML attribute. The function is actually designed to extract an element, but the parameter defining the element is called "Attribute". A semantic quibble, perhaps, but I am mentioning this because you need to know this if you want to handle XML.

Fact is, if you try to extract an element that does have an attribute or two, the function won't work.

As for the actual calculation, let's take an example or two:

IsEmpty ( XML ) or IsEmpty ( attribute ) or PatternCount ( xml ; "<" & attribute & ">" ) = 0

Do we really need the first two conditions? Actually, do we need this test at all? We'll be looking for

Position ( XML ; "<" & attribute & ">" ; 1 ; Get_Instance )

right after this - couldn't we use the result of this to see if we have a fish in the pond?

And what would happen if we didn't test at all, and went right away to the calculation? The answer is: nothing.

BTW, the expression "<" & attribute & ">" appears 3 times in the calc, and the above Position() expression twice - why not define them as variables?

Or take this:

Middle ( XML ; Position ( XML ; "<" & attribute & ">" ; 1 ; Get_Instance ) + attribute_length + 2 ;

xml_length - ( xml_length - Position ( XML ; "" & attribute & ">" ; 1 ; Get_Instance ) ) - ( Position ( XML ; "<" & attribute & ">" ; 1 ; Get_Instance ) + Attribute_Length + 2 ) )

What does it do? If you tidy it up a little, take away redundant parentheses and replace repetitive expressions with variables, you'll get::

Middle (

XML ;

start + attribute_length + 2 ;

[color:red]xml_length - xml_length + end - ( start + Attribute_Length + 2 )

)

Do you see what I see?

[Raybaudi]

To give an hand to Andy, it must be said that it was 2004, Apr 29 and the function is the # 1 of the brian's list; at that time most of us write ¶ between quotes.

[LaRetta]

So? If the horse was great transportation in the 1800's, should we continue to ride them?

Oh. Well ... maybe with gas prices we should! But don't confuse constructive criticism of a process or calculation with criticism of the person. I see so many people in the FileMaker world confusing the two. There is no need to [color:green]challenge a person but there is great need ( and SHOULD BE ) to [color:green]challenge a method as being the best if it no longer is ( or even never was ).

Our value is NOT tied to a calculation, file or process. I've no doubt that Andy is a wonderful person. I've also no doubt that what he produced is MUCH better than *I* could ever come up with!! But that's not the issue here ... I want to know the best ways always and so should everyone on these Forums and, as things change, better methods appear or people discover better ways. I recall some people jumping on -Queue- for fine-tuning their work; well, it was ridiculous ... we should have thanked him for it just as I do Comment, Ray, Mr. Vodka and anyone else with enough guts to stand up and say they see a better way ... including YOU, Daniele. :wink2:

Edited June 6, 2008 by Guest
Changed green words from defend to challenge

[Raybaudi]

I didn't say that the calc is perfect and that comment was wrong to criticize it...

My words were given as a little help to Andy's preparation of four years ago !

[LaRetta]

Oh. If it were ME, and you responded thus, I'd have felt that you thought I was a bad guy and bullie for mentioning anything and that you felt the need to defend. That's why I posted. Comment was commenting on the calc when asked; that's all. Bless ANYONE who posts with corrections, better ways or alternate approaches; always and forever.

UPDATE: I also see you changed your response a bit. No problem. :wink2:

Edited June 6, 2008 by Guest
Added update