gmmac

I have the same problem, but with the unwanted space at the bottom of the body, and over the footer. No matter how many records I choose, the space is the same size (is not proportional). Nice picture!

In advanced, you can use custom menus to have "show all" show certain records based on the current layout....of course, you have to alter the finds etc. The 10x extra work. Which I'm about to start right now. Good luck to ya!

Comment--I had not yet made a value list show only related values--your solution works perfectly. I can take it from here. Thank you!!

I've been poking around for a custom function or a calculation that does in v. 8.0 what list() function does in 8.5 and higher: I have a table of users, and a table of donations they have made, often multiple donations in a year. I want a single field which can show every year they have donated (then I'll have to eliminate duplicates and extract gaps, but that's another matter). I'm sure this has been done many times before, but I haven't found this particular case searching the forums. Thanks for any help.

Fair enough--you could get around the validation and searching with some pain in the neck extra work. But Comment's last points tip the point--the idea to have conditional field names is probably the best solution. They could under-lay your actual fields so they looked like they were actually the field itself.

I think you're in the wrong place to get help (this is tips & techniques--So your post may be moved). If or Case functions should work, just use: IF (Invoice date ≥ 11/30/2008 AND Invoice Date ≤ 12/31/09 ; Sub total * .175 ; Sub total * .15 )

How about simply auto-entering the field names' names when records are created, and setting field behavior to "select entire contents of field when entered"?

Ah, yes. A hack, as I said, and I am always making things more complicated than necessary. Thank you! Meanwhile, I have made a table layout with a new related table joined by a new (date) "week ending" field (which joins to the [calc] week ending in first table). Other new fields use the GetSummary function to get week totals, and if you don't mind sorting every time you enter the layout, John, it does what you want it to do..... you do have enter in existing week-endings into your new table, but if you have data for each week you could auto-enter by calculation pretty quickly. Or maybe someone else has a good idea for that. I have to stop procrastinating now myself!

Hi there, I do something like this for my invoicing--giving week rather than daily totals. But it only works as a report--summarizing the weeks hours and $$. I did this by creating a summary part that sorts by the field "week ending" which is a calc field that looks like this (my week starts on Sunday): If(DayName(Date) = "Sunday"; Date + 6; If(DayName(Date) = "Monday"; Date + 5; If(DayName(Date) = "Tuesday"; Date + 4; If(DayName(Date) = "Wednesday"; Date + 3; If(DayName(Date) = "Thursday"; Date + 2; If(DayName(Date) = "Friday"; Date + 1; Date)))))) I have 2 summary fields "week hours total" and "week rates total" which total number fields; the same summary fields are used in a grand trailing summary for grand totals..... It is difficult to come up with ways to summarize data in a layout rather than in a report--if you play around with the "GetSummary" function you may get results. Sorry I don't have time to work on it now....if I have any new ideas (or memories!)will repost. My file is admittedly a bit of a hack (since it's mine not a client's ) but if it might help I can send it along. Hope this helps.

Pete Are you still working on this? Galen

I'm perhaps a tiny bit confused by your description, but it sounds to me as though you want two columns in the layout, but four columns of fields--does that make sense? In one layout column, you set up three fields, have a small imaginary-column space between them, and then do the same in the an "imaginary" column next to it. In the second layout column, you do the same. The height would of course be the same all the way across. That way FM will let all six fields into two "imaginary columns" to get all fields from the record. FM sees two columns, but you see four. Hope that helps, Galen

Ah--that sounds good. did you filter out with right words and a new calc field, or some other way? I _really_ dislike Access but I do like that you can choose which field to enter from a drop-down list. Let me know if you can, thanks, Galen

Hi I had a similar problem just trying to bring up a list of values through a value list (not a related field). I ended up using a portal, but that happened to work nicely for my particular solution. Off the top of my head, only other thing I can think of is to use a concatenation to combine that field with another which will make it unique. You'd have to figure out how to return it to the original value you want--with how you display your value list, through another calculation, etc. It's not necessarily pretty, but will it get thejob done? Maybe someone else has already discovered a more elegant solution. -G

Sorry, just reread your post. Can you attach an example I can look at for you? Don't need much or any data (I could populate fields myself or you could set up one example for me). Going out but back in a few hours. G

Oh, yes! They must be in the same text block for it to work. Otherwise you can use sliding with field boxes, but that gets more tricky: if any other text blocks with text in them are anywhere else (horizontally, that line or any line above) on the layout, the sliding fields won't work. Also, the box above and the box itself must both be formatted as sliding up. Does that help?? Galen

Hello there merge fields [<<fieldname>>] do slide up as long as field is absolutely empty (no spaces, nothing--thing to watch for here, is if you have a concatenated field and it leaves a space between, say, a first and last name. If such is case, you must calculate for no spaces if name fields are empty--let me know if you need syntax help). I have had great success with exactly your situation. Busy right this second, but willing to give you calculation if you need it. Otherwise is simple: <<mergefieldname>> (line one) <<mergefieldname>> (line two) <<mergefieldname>> (line three) -Galen

I'm having the same problem with scripted constrain found set, and it doesn't make sense to me that that is FM Pro 7's new intentional behavior. Scripts are intentional! One uses a given step for a reason, and to have inaccurate results is frustrating. So, that said, do you have an error trapping suggestion? Thanks if you can!