smorr

We have a interesting problems here where a button that switches between form and table view works fine on a local database but as soon as that database is moved to the network, it starts prompting the message "Do you wish to save changes with the layout". We don't want this but cannot figure out how to get rid of it -- it seems to happen on some databases but on other ones. Help please! Scott

Another way of doing it (in FMP 7 ) is to use a repetition field with a global $fieldsToSearch (text with 10 repetitions) stored as global #SearchData (text calculation with 10 repetitions) = getRepetition(getfield($fieldsToSearch),1) // get the first rep (ie unExtend) of the fields listed in repetitions of the $fieldsToSearchGlobal So when $fieldsToSearch is [Name|Age|Address|Phone] #searchData may be [bob|23|123 Cherry Lane|555-1234] for one record and [Ann|42|45 Hickory Drive|555-6789] for another record When you search on a repetition field, it will search across all repetitions The nice thing about this method is that you can change the fields to search on the fly. Scott

One way of doing this is to check after you go to the window name Select Window ["My Window"] if [get (windowName) <> "My Window"] New Window ["My Window"] end if

Have you tried stopping the script as soon as the database starts up (command-. on mac, esc on win) or creating a relationship to the db in question so that it will open in the Background and you can access it that way. Or execute a script in the db from another database via the external script call?

Basically, you want to have two relationships: one for NotSpecial visits and one for special visits. Lets say that your leftside of the relationship is Student, create a constant calc field: k_SPECIAL where the calc = "Special" (text) Now in the Relations diagram you should have the Students Table Occurance (TO). Make sure you have 2 more TOs, say, "VS#Special" and "VS#notSpecial" (my naming method is AbbrevforTO#NatureOfrelationship 1) relate Students to VS#Special on Students::k_Special=VS#Special::TypeOfVisit 2) relate Students to VS#notSpecial on Students::k_Special<>VS#Special::TypeOfVisit (using the notequal symbol) Now you can add portals to each on your layout Does this answer?

Well, thanks to variety of postings, he now has several solutions to choose from. If he was presenting a finite list, the case or choose statements work very well. If his list was merely the first 7 terms from an infinite list which conforms to the triangular number pattern, he now has a formula that will work very well.

The mathematical pattern here conforms to the pattern of triangular numbers A triangular number is the sum of all the numbers upto and including the number 1:1 2:1+2=3 3:1+2+3=6 4:1+2+3+4=10 5:1+2+3+4+5=15 but it is a variant of it where 1:1 -> tri(0) +1 or 0+1 2:2 -> tri(1) +1 or 1+1 = 2 3:4 -> tri(2) +1 or 1+2+1 = 4 4:7 -> tri(3) +1 or 1+2+3+1 = 7 5:11 -> tri(4) +1 or 1+2+3+4+1 = 11 6:16 -> tri(5) +1 or 1+2+3+4+5+1 = 16 7:22 -> tri(6) +1 or 1+2+3+4+5+6+1 = 22 So basically the pattern here is Fieldb = tri(FieldA -1) +1 since triangular can be calcuated with a simple formula (thanks Gauss!) where tri(n) = n(n+1)/2 We are left with the mathematical formula: (adjusting for the fact we are looking at fieldA-1 FieldB = FieldA*(FieldA-1)/2 +1 eg when fieldA = 7, fieldB = 7(6)/2 +1 = 22

There would be several ways of doing this via scripts. Perhaps the simplest would be a script that looks at the accountname and goes to the appropriate layout if [get(accountName)="Peter"] go to layout ["Layout A"] elseif [get(accountName)="Paul"] go to layout ["Layout B"] elseif [get(accountName)="Mary" or get(accountName)="Sally" ] go to layout ["Layout C"] else #general layout go to layout ["General"] end if Otherways of doing can be using privilege sets -- multiple users can fall under the privilege sets. if [get(privilegeSet)="Developer"] go to layout ["Layout A"] elseif [get(privilegeSet)="Administrator"] go to layout ["Layout B"] elseif [get(privilegeSet)="Editor" or get(privilegeSet)="User" ] go to layout ["Layout C"] else #general layout go to layout ["General"] end if

I have the exact same situation in a solution I have developed. What I did was 1 table with a commentTypeField. For portals, I created on the leftside table "constant" fields that match the comment types allowed. (calcuated fields with text result equalling the commenttype) eg k_COMMENT_TYPE_SERVICE = "SERVICE" k_COMMENT_TYPE_GENERAL = "GENERAL" k_COMMENT_TYPE_SALES = "SALES" Then any portal relationship just includes the comment type constant relationship as a extra key eg: TABLE A <-------------------> TABLE B k_COMMENT_TYPE_SERVICE = _Comment_Type and k_STATUS_OPEN = _Status and #curServiceRecord_ID = _ParentRecord_ID if you want to show comments of more than one type in a portal, there are two ways of doing it. first way is to create a multiline constant with the comments you wish to show. eg: k_COMMENT_TYPES_SALES_SERVICE = "SALES

Ok -- I've looked at this and thought about this and looked at it again... and I am sure something is escaping me here... How is this different from just using a calculation using a relationship? Let ( [ T = MyRelation::gTable; S = MyRelation::gSource; M = gMessage; R = GetField("T &"::"& S")]; if(GetField®<>""; GetField®; M) )

Yes, it means that portals will update... This is particularily useful for portals that are based on complex calculations that are in part based on other relationships that are not visible on the layout. For example, when the leftside of the relationship for a portal is a calculated field that makes use of that valueListItems calculation (which of course makes use of a relationship). If you modify data in a script that would change the valuelistItems, in v7.02 the valuelistitems would be updated but not the cached calculation using it. hence, the portal based on this calculation would not be updated (even it the calcuation was unstored) In V7.03 by adding this option, all relationships and calculations would be uncached and updated. Hence the portal based on this calcuation would reflect the change made by the script.

I find it looks busy because it looks like a checkerboard. The 30 + white fields on the dark background have each of the fields screaming for visual attendtion and your eye doesn't scan the layout well. Set your background lighter - and Use the contrast of light on Dark only for very important details -- try to keep the eye from jumping It seems you have about 3 conceptual blocks of data but it is spread all over the layout. Top right appear to be flag regarding the workflow/process Bottom right appears to be more detail items regarding the same thing. but you have a listing of references and letters in between. Would the "assigned to" be considered to be yet another part of the approval process? Could you block off the applicant name/address information as 1 area. The documentation (documents/ references) as a second area And all the checkpoints in the approval process (including assigned to ) as the third as others have said -- double check field sizes and alignments (use the object size palette in pixel mode -- it is your new best friend) Get the fugly blocky buttons out of the command bar at top -- go for rounded rect or no real button -- just an implicit area for clicking. Take a look at my pdf of adjustments design.pdf

See my recent post in the Spotlights forum In a Gui/Data separation model, you set the user passwords for the front end database, and set passwords based on privileges for the backend database(s). The frontend database will relogin to the backends as need be with appropriate privileges to the user. They way, passwords are easier to manage and user can change password at will. Post on password management

Turn off wrapping in the calculation editor (allow horizontal scrolling) Allow real tabbing (not type in 5 spaces to emulate a tab) Allow auto indent (ie don't go back to left margin after return if I am tabbed in three levels) and of course, color coding (even pick up colors of TOs from Relationship diagram) Please. Pretty Please.

In relationships, Here is what I want: Be able to Group relationships structures and perhaps name them (rather than making a dummy TO with the name (which will appear in any relationship menu) and even (gasp) collapse them by name. Have the relationship structures in a list with the option to show one at a time. Change the ways colors work in the diagram -- you can choose dark red and it displays as pink. You can choose light red and it displays as light pink. Choose purple and it displays a purply pink... choose orange... and well you have the idea. its not that I have anything against pink... its just I like to use colors that will are clearly distinctive. (My vote is to get rid of the faux windows XP tables occurances and get something that will display more clearly.) Add The ability to specify constants in the relationships without creating a calculation for the so purpose of the relationship Add notation to the ends of the relationship. If a record can be created in a TO via a relationship put a little * or C or whatever on the appropriate side of the relationship indicator. Same with Sorts and Same with Cascaded deletes. In datastructures: Extended Tables I would give my left arm for a "extended table" based on another table. I don't know if I am communicating my idea correctly but I would love to say that TableB is a extension of TableA. With would be based on a primary ID and B would "inherit" all fields from A. but allow for Table B to add to or even override fields in table A -- When a Record is added to Table A, it is available to Table B. When a Record is deleted from A, it is deleted from B Eg. Table A: UserID LoginName FirstName LastName LastFirstName = LastName &", "& FirstName Table B: extends Table A // accessing table B will allow UserID, LoginName, etc etc but also the following UserNotified fieldsSpecificToSolution LastFirstName = TextStyleAdd(Lastname,bold) &", " & FirstName This would allow a basic structure that can be unsullided by various needs or uses and then this structure can be extended in multiple ways.