Stoned again?

[Mandu]

Has something happened between fmp8 and fmp9 to mess up the technique for making objects appear and disappear from a layout? I'm referring to this technique:

-- Define unstored calc uc_Charge = "Charge"

-- Define self-relationship ShowIfCharged based on uc_Charge = PaymentMethod

-- Create 1-row portal based on ShowIfCharged whose dimensions are 217x63.

-- Place a 215x61 box containing some text atop the portal, being absolutely sure it nests fully within the portal.

Finally, I want this text box, if shown, to slide upwards. I select the portal and all the stuff lying inside it, and set sliding on / directly above / reduce enclosing part.

It worked on Mac in FMP 8. I moved it to Win FMP 9 and it slides okay but it won't disappear when PaymentMethod != uc_Charge (not equal).

Any ideas?

Thanks,

Chap

[Robert Schaub]

uh would'nt this

Define unstored calc uc_Charge = "Charge"

need to be stored and indexed to use in a relationship?

[mr_vodka]

Not if its on the parent side of the self join which I think the OP is doing.

[mr_vodka]

Can you post a copy of your file?

[Mandu]

That's correct -- the unstored calc is on the left side, i.e. the parent side, of the self-join relationship.

[Mandu]

I really wish I could . . . it's 10 MB, though, and I don't know what's taking up all the room.

[mr_vodka]

Well see if you can make a copy without any data. Also try reindexing your PaymentMethod field.

[Mandu]

Zipped clone is attached.

I don't know how to re-index a field....

When it prompts for initials, enter: clh

and you'll get the standard menus.

ChapOMatic_CLONE.zip

[Robert Schaub]

Confused.

You said uc_charge was defined as "Charge"

In you clone it is defined as

an if statement

If ( PaymentMethod = "Charge" ; uc_Total ; 0 )

[Mandu]

Argh! I'm sorry - it's uk_Charge. k for constant.

[mr_vodka]

I don't know how to re-index a field...

Under the field properties, go under storage options. Just turn the Indexing to None and save. Then you can go back into it after saving everything and turn indexing back on.

BTW what layout is all this on?

[Mandu]

Okay, I reindexed. Same problem.

The layout in question is PrintInvoice layout. On the lefthand side is a Received By: box for a signature. That's the box I want to disappear if PaymentMethod is not Charge. It is sitting in the magic portal.

[mr_vodka]

This does not look right. The way you currently have it setup, if there is ANY record that has the payment type of "Charge" the "GagMe" relationship will return a true. If you want it record specific, you will have to also match by RecordID.

[Mandu]

Yes! That is the problem. Thank you.

As I understand it, the way this technique works is by placing all "conditionally visible" objects into a one-row portal, and then doing something to render the relationship upon which the portal is based either valid (i.e. show objects) or invalid (hide objects). In my case, the objects in the portal aren't even fields in the related table - they're just graphic and text objects.

Since I'm using a script to prepare this Preview, the script could assist in this; for instance:

If [ PaymentMethod != "Charge" ]

   // do something to invalidate the relationship

   // that the portal uses.

End If

It doesn't seem like it needs to get as complicated as it's getting, with unstored calcs and record ids. Is there perhaps a simpler way of making a rectangular area -- and its contents -- appear or disappear on a layout through the actions of a script?

(In any event, you've answered my original question, and thanks again!)

Chap

[mr_vodka]

Use can trying using a tab control with no border lines. Have two tabs. The first one would be blank and the second one would have your box section. As part of your script, if you want it to show on a report, use Go to Field [] (since you are on v8). Otherwise, it wont show.

[Søren Dyhr]

I took a look at the template, and the question seems to be issues with the visibility "trick". Please note that with the later versions have this technique left centerfield or at least given place to other ways, all kinds of dynamics in the interface layer of the solution can now use/abuse visible as well as invisibel tabs....

A brilliant way this is used is in this template:

http://www.databasepros.com/FMPro?-DB=resources.fp5&-lay=cgi&-format=list.html&-FIND=+&resource_id=DBPros000691

--sd

[Mandu]

I've got the Tab trick working, mostly. I attached a demo file. Clicking Show and Hide basically works, except in Browse mode it leaves an artifact in the form of a thin (one-px) vertical line. The line doesn't appear in Preview mode.

What I can't yet get working is sliding upward. The text box underneath the magic rectangle refuses to float upward when the rectangle is invisible.

Any thoughts?

Thanks,

Chap

MagicRectangle.fp7.zip

[Mandu]

Think I'm going to cry.

The layout "PrintInvoice layout" contains a one-row portal whose sole purpose is to disappear (along with the enclosed text) if the Payment Method is not "Charge".

The relationship that makes this happen is called "ValidWhenPaymentMethodIsCharge". It's a self-relationship of LineItems, matching uc_Payment_Method_Is_Charge with c_One. uc_Payment_Method_Is_Charge is an unstored calc that evaluates to a number; 1 if Invoice::PaymentMethod = "Charge", "" otherwise. c_One is a stored calc that evaluates to 1.

And indeed, uc_Payment_Method_Is_Charge is being set correctly, depending on the PaymentMethod in the parent record. I've verified that.

But the portal (and the text it contains, "Received By____") will not disappear when uc_Payment_Method_Is_Charge is not 1.

Would someone wander into this mess and tell me why it's not working? When prompted for initials, enter CLH.

I'd be so amazingly grateful.

Chap

_Clone.fp7.zip

[mr_vodka]

I have modified your file. Good luck.

Clone_fixed.zip

[Mandu]

Thanks.

I was taking my guidance from the following:

http://databasepros.com/button2.html

If you have a moment, could you explain what the crucial difference in the two techniques is?

[mr_vodka]

I did not alter the technique. However, your relationship for your portal needs to be for each different invoice. Therefore, you need to join on InvoiceID as well as the specific "Charge" criteria. Otherwise, if the first record in your found set is set to "Charge" then the relationship will be valid for all the records regardless of different invoices.

[Mandu]

I don't get it.

My self relationship in Clone.fp7 was:

demo I mentioned also uses a self-relationship:

uc_PayMethod_Was_Charge = c_One

Neither field is global.  



The  

Conditional_Calculation = Constant

Neither of these is global, either.

But the demo works, and mine doesn't -- until I add the qualifier that the ID's must match, too.

Apparently there's something in my solution that's significantly different from the demo, but I'm not seeing it. The unstored calculation? The fact that the calculation refers to a field in a related table, rather than in the current table? The portal not being positioned exactly 12 pixels from an unreferenced global auto-enter Summary field and a cherry on top? I don't see how my incorrect solution is any less record-specific than the demo is.

As my mother used to say, WTF?

[mr_vodka]

I think you are missing the overall point of this technique. It is not that you have to use a global or a constant necessarily... I mean you could modify your file to use one if you wish but since you already had a calc field called 'uk_Charge' that returned the string "Charge" I just used that instead of modifying a bunch of calcs.

The overall point is that in order for the portal items to disappear, there has to be NO related records that the portal can display. With the orig demo, John uses a calc to either return a value of 1 or 0 and then he uses a constant to join it to.

Technically you could do the same by creating a calc that returns a flag result as well such as PaymentMethod = "Charge". This will return 1 if its true and then you can match it to your constant without adding the additional match field.

Clone_v3.zip

[Mandu]

I understand that the point is to create a relationship that results in either no records, or some records, and using a portal to view those related records. What I don't understand is why "my" technique doesn't accomplish that, when it seems so similar to the demo.

What I don't understand - I think - is: what happens when a calculation field (let's call it IsCharge) is used in the relationship. If the calculation is PayMethod = uk_Charge, I would think that IsCharge would be 1 in every record where the PayMethod is uk_Charge, and thus joining by IsCharge = uk_One would yield exactly the same results as joining by PayMethod = uk_Charge.

I can see how there would always be many records joined by the relationship PayMethod = uk_Charge. What I can't see is how this would be any different than joining on IsCharge = uk_One.

In other words, why would there be only one record (at most) where IsCharge is 1?

Or am I even further off the mark than before?

[Mandu]

In fact, I'm so baffled by this that I wrote a dead-simple example (MagicRectangle.fp7). There's only one table, with several fields:

Two calculation fields (one stored, one unstored) that evaluate to 0 or 1 depending on whether the record serial ID is even or odd.

Two "constant calculations" (one stored, one unstored) that evaluate to 1.

And there are several relationships that try different ways to self-join by matching the Even/Odd calculation with the constant 1.

Only one of them correctly causes the portal to appear or disappear according to the evenness of the record ID.

MagicRectangle.fp7_2.zip

Edited April 14, 2008 by Guest
updated demo file to show all 8 possibs.

[mr_vodka]

I am not sure what you are getting at... As stated earlier, the UNSTORED calc on the CHILD side WILL NOT WORK. So both the boxes on the right hand side will not show anything.

As for the upper left hand side ( I think this is where you keep missing the point ) is that it is working as it should. No matter what record you are are in, it will keep matching records 1,3,5,7,9 since they are related when matching to the value of 1.

[Mandu]

I guess this is what I'm confused about:

In a relational DB, every record has the same set of fields. And in Filemaker, this is true too (ignoring repeating fields). Even a "global" field can (and should) be thought of as belonging to each record. Text fields, number fields, date fields, container fields -- every record has the same set.

The same goes for calculation fields. Stored? Unstored? Only difference is when the evaluation occurs.

When I look at the sample file I posted, I see all ten records listed, along with their fields. The calculations that result in constants all show 'ODD' (1). The Even/Odd calculations show either EVEN or ODD (0 or 1) as appropriate.

Looking at this list, one might suppose (at least, *I* might) that a self-relationship matching the Even/Odd indicator with the constant '1' would yield an identical join whether matching uc_EvenOddIndic to uc_1, uc_EvenOddIndic to c_1, or any of the remaining six possible permutations. And, in fact, I might predict that the number of joined records would always be 5, since there are that many records with odd ID numbers. (In which case, the portal would never disappear and this whole technique wouldn't even work!)

But. The relationship that matches uc_EvenOddIndic with c_1 apparently matches zero records, or more than zero records, depending on what the current record is. Even though I can see, looking at the record list, that uc_EvenOddIndic remains rock-solid ODD or EVEN, regardless of what the current record happens to be, a join based on matching uc_EvenOddIndic to 1 will yield different results depending on what the current record is.

I mean, to me it's as nonsensical as saying that 1+2 doesn't equal 2+1. In fact, it's as nonsensical as saying that 1+1 sometimes doesn't equal 1+1. I think the secret must lie in some subtlety involving unstored calculations, but I'm damned if I can figure it out.

[mr_vodka]

I think the concept of the self join is confusing you... Take it out of that context and think about a simple parent child relationship. The behavior of an unstored calc has nothing to do with why your two left examples do not match.

ParentChild.zip

[Søren Dyhr]

Perhaps you should investigate this template, and carefully read the instruction.

http://www.kevinfrank.com/download/county-highlight-in-portal.zip

--sd