Conditional Color Repetition?

[LaRetta]

I've attached a file showing basic worksheet I'm working on. These repetitions will pre-fill with statistical data and also allow User entry.

There are 5 portal rows side by side. The child records are one per year (as specified in StartDate plus numb_months (the number of months to jump ahead). Records are then created which span this period. There will be NO need to ever report on these worksheets. If the block being displayed is between (and including) the start month/year and the end month/year, I would like the repetition to turn white so it is clear what period of time is 'predicted.' So in 2007, January - April will remain grey but the remainder of 2007 would be white. Arrows scroll forward/backward through the years as well (although I left that off).

Will I need to break the repetition fields into individual representations and attach each conditional format that way? If so, I am still dealing with repetitions and, although a card-carrying member of the Repeaters Club, they don't particularly like me (yet) so I would appreciate knowing what kind of calculation I would use. This is an attempt to spiff up the UI and I can't change (much) of the structure - it needs to be presented tomorrow.

I call upon the great Repeater Masters in hopes of salvation ...

LaRetta

Conditional_Reps.zip

Edited June 18, 2008 by Guest

[mr_vodka]

How about something like this?

*Edit sorry fixed a bug

Conditional_Reps_mod_v1.2.zip

Edited June 19, 2008 by Guest

[mr_vodka]

Oh also, you may want to keep in mind this point of repeating fields with conditional formatting.

The screen will need a refresh of some sort.

[comment]

This is not a good starting point. The problem is that for the purposes of conditional formatting, a portal field knows it's repetition number but not it's portal row number. This can to be calculated in a rather roundabout way*, or you could hard-code it into your conditional formatting (meaning each repeating field would have its own formula). The field in the first portal row could use:

Let ( [

m = Month ( Main::gStartDate ) ;

n = Main::g_num_months ;

i = Get ( CalculationRepetitionNumber )

] ;

i ≥ m and i < m + n

)

The field in the second portal row would have:

i = Get ( CalculationRepetitionNumber ) + 12

and so on.

Or you could just use another calculation field, as John has done.

P.S.

1. Why are there two relationships? Do you expect to create records by filling data?

2. Why are there so many rectangles on your layout?

---

(*) see http://www.fmforums.com/forum/showtopic.php?tid/195983/post/293846/

[LaRetta]

Hey JOhn! Your calc does the trick quite nicely! It is a very clever solution! I kept seeing the 12 reps and the year and thinking it was a natural to work as I had expected but, as Michael says, the perspective (from portal) tripped me up. Thank you for saving me for tomorrow (well actually, I found out that the deadline is Friday). I have to admit that I laughed when you responded because, well, it was because of the thread you started (linked in your post) that I felt the need to establish The Repeaters Society. And your post was about conditional formatting of repeaters. I loved the irony of it resurfacing and you helping me with it.

Hey, Michael! I had a sort on the relationship so I didn't think it mattered the order the rows were in. But I saw several issues with the functionality; partiularly the one I put up on Forums as sample. I was originally asked to create a mock-up screen display only but if it had SOME functionality that would be cool. So I did what I never do ... I began putting together the UI before considering the structure. Simply, I didn't (and don't) have time to think it through. But if I am going to do it, I might as well do it right and/or learn everything possible as I go. But I tend to over-think and then I wouldn't have it ready. So I was forcing myself to just DESIGN. Ha ha.

The rectangles? Well, I use repeaters rarely (only because I'm unfamiliar with them) but I thought we couldn't have lines BETWEEN each repetition. I could have sworn that was true and I wanted lines so I grabbed another solution which had a nice grid and used it. And now I see in John's demo that we can. Wow, has it always been like that?

Two relationships? As I was playing with the demo (and was going to put the script in it to create the child records), I realized that someone could create double the records using my original script which would go to Child and loop create according to year and number of months to generate. I wanted only possibility of ONE per year so I decided I should use Allow Creation, joining:

Main::MainID = Child::MainID

AND

Main::g_year = Child::Year

I planned to only set the creation date in the child. Then, if someone tried to generate it again, it wouldn't create a second duplicate year. Then I realized I was missing a way to REMOVE a year if someone changed the span. But then I realized I was again overthinking a solution which was fine if it was only a mock up although *I* wanted it fully functioning. Whew! I was again, tonight, reminded this is mostly a mock up. But it will become a true solution (or at least what portions we decide would work well) down the road in few months so it is NOT lost effort - as long as I don't get too side-tracked and then miss the deadline. That would be VERY VERY BAD because it needs to be demo'd. ha ha!

I can't thank you both enough for helping me. I suppose the best way to say 'thank you' would be to shut up. :yep:

[LaRetta]

And now I realized that, if someone typed the value, it would create the child record.

And THIS is why I prefer thinking things through! Some people can create wonderfully bang-zoom! Not I ... I need to consider carefully from 50 angles first and I STILL don't create wonderfully. Go figure.

I think I'll make this change in the mock up tomorrow. Ha ha!

[comment]

I wonder: do you realize how much simpler this could be if you rotate the view 90 degrees (months are columns, years are rows)?

[comment]

Hold the presses: as soon as I said that, I realized it can be made simple in the original configuration, too. All the instances of the repeating field can use the same formula for conditional formatting, and no additional calculation fields are required. And there is a workaround for the refreshing issue.

Conditional_Reps_2.fp7.zip

[mr_vodka]

Cool

Its nice that putting the field in the back of the stack order will refresh the other fields.

[mr_vodka]

Taking a page from your refresh method, I have modified my file as well.

Conditional_Reps_mod_v1.3.zip

[LaRetta]

Oh, you two are great! The reason I didn't turn the design sideways was because this is how it was originally requested and I didn't think of turning it. And now I'm glad I didn't because it showed me these wonderful ideas of yours! Also, the years would rarely run more than 5 for a project (although a few may take 10 years) so this view shows the longer entities vertical. And now we can grey out those unneeded AND it refreshes!

My mind spins with possibilities! I'm excited to realize that these techniques will serve me in many other areas as well.

ROCKIN'

UPDATE: Oh, also, the dollar amounts can be six to seven-digit in each field so 12 columns probably wouldn't have worked if we turned it. I just realized that ...

Edited June 19, 2008 by Guest

[comment]

LOL, with 7 digits per month they should be able to afford a screen wide enough.

[LaRetta]

Thanks for the morning belly laugh! Well yes, management could have wider screens but many staff have 17" but that doesn't discount your humor one bit!

One final question ... I'm looking at these month names and wondering why I hard-coded them (they are simple labels). Since they never change, couldn't I use a repetition field as well - the idea originally was that - how nifty that rep 1 is January etc. And I thought ... if I used a different calculation for the horizontal label then I might control what it said and it might say anything I specified (in the calculation itself). And you know how that gets me thinking, ie, reps could be values from a value list...

Ah well, back to reality woman ... but can't a rep be month ...

OMG. Michael? I just went to move the labels from your demo ... they aren't labels!!!

Now I'm truly tickled - you were way ahead of me! You already did that! And I'll bet there are more surprises in these demos than I've seen already!!

Edited June 19, 2008 by Guest

[LaRetta]

Oh, this is so fun ...

GetValue ( ValueListItems ( Get ( FileName ) ; "fruit" ) ; Get ( CalculationRepetitionNumber ) )

... can we use LIst() as well? Oh, I ADORE repetitions!!

Edited June 19, 2008 by Guest
Added adoration sentence

[comment]

Of course they aren't labels - much easier to align a repeating field with another. But I made a mistake: I should have left it a Date field and format it to show the month name only.

BTW, did you know it's much easier to align duplicate objects side-by-side if the object's width equals a multiple of 6 + 1?

[comment]

can we use LIst() as well?

Why not?

GetValue ( List ( Child::Field ) ; Get ( CalculationRepetitionNumber ) )

creates a makeshift portal.

[LaRetta]

It is strange but, now I can remove the gShowMonths field from underneath and it still refreshes. I think the new calculation fixed the refresh - otherwise, is it a platform difference? I think not but please confirm ...

If I could, I'd spend all my time studying FileMaker. What fun!!!

[LaRetta]

Maybe it refreshes now because gShowMonths is IN the conditional calc itself ...

[comment]

What new calculation?

[LaRetta]

The one you said would work for ALL fields ...

Let ( [

m = Portal Child::Year * 12 + Get ( CalculationRepetitionNumber ) ;

n = Year ( Parent::gStartDate ) * 12 + Month ( Parent::gStartDate )

] ;

m ≥ n and m < n + Parent::gShowMonths

)

When I download your demo and remove the [color:red]gShowMonths from behind, it refreshes by itself!

UPDATE: As opposed to the first post where you said each column would need its own calc - sorry for being unclear. It's the HOLD THE PRESSES post!

I mean it is IN the body of the calc and not in the Let() portion.

Edited June 19, 2008 by Guest
corrected red & added sentences

[comment]

It doesn't work for me without the field in the background.

[LaRetta]

Ooops. I had not tested it thorougly enough; something you would think I have learned by now.

With smaller month numbers it appears to work fine but not larger numbers. And, ehm Michael? YOur text below the chart clearly states, "This ensures screen refresh." It surely does. :wink2:

[Miguels]

Yes Laretta, it's refreshing because of the conditional formatting.. check out variables, and conditional formatting webex seminar on filemaker site.. instead of having the calc in a field, you can actually do your calc in the conditional format area and it refreshes first.. http://filemaker.com/support/webinars/seminars.html#cu10

[LaRetta]

Yes Laretta, it's refreshing because of the conditional formatting..

Hmmm, that is not my impression at all. Conditional formatting does NOT cause the fields on top to refresh. In fact, it is the conditional formatting in the top fields which does NOT refresh.

The top fields are forced to refresh because FileMaker must redraw (and refresh) the field UNDER those fields (because the value changes). So anything on top of that number field must also be redrawn (refreshed).

That is MY hit on it ... Am I wrong?

BTW, my name is LaRetta. :wink2:

[LaRetta]

I will, however, view all the videos you referenced. They must be fairly new; I crawl that site quite often. Thanks for the link!

[LaRetta]

Well dang ... when I click the Conditional Format one, it brings up Scripting by JMO.

[mr_vodka]

The link seems to be broken. It is going to the wrong webex event. If you go directly to this link it should work.

https://filemakerevents.webex.com/ec0600l/eventcenter/recording/recordAction.do?siteurl=filemakerevents&theAction=poprecord&recordID=23008642

[LaRetta]

BTW, did you know it's much easier to align duplicate objects side-by-side if the object's width equals a multiple of 6 + 1?

1) I can't replicate what you are explaining and 2) I don't see the theory behind it (see attached).

I may be getting twisted because, in first test, I overlapped the inner lines and in Test 2 I didn't and I was unsure which I should be testing or whether it mattered. I also was unsure whether you meant align horizontally or distribute evenly. I see 1 - 2 - 2 - 2 - 1 and I can wildly guess but I am able to disprove each of my guesses. :idunno:

AlignMultiple6.zip

Edited June 24, 2008 by Guest
Forgot the file

[comment]

Let's see if I can make it clearer: it's easier to place duplicate objects next to each other so that their borders overlap when the object's dimension equals a multiple of 6 + object's borderwidth.

The theory behind this is that the grid is 6x6 pixels.

[LaRetta]

Okay, that fits. I might suggest slight revision then:

... The theory behind this is that the grid is 6x6 pixels [color:green]by default.

AND

... it's much easier to align duplicate objects side-by-side if the object's width [color:green]equals grid unit spacing + line width.

It seems that the grid unit can be changed and line width will sure make a difference as well. I have not played with this aspect of layouts at all and I shall now! Thank you for bringing it up!

Edited June 25, 2008 by Guest
Rearranged sentences

[comment]

Thank YOU for reminding me that grid spacing can be changed.