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.

I agree .. real type ahead would be nice. Currently I use a script trigger (such as zippscript or the one on developer tools) on a global field. I set the field so that tab will exit the field (but I remove any tab order from the layout) When I am in a field I can type in the first couple of letters and hit tab. the script will trigger and do the "look ahead" and return to the field. Its a bit tricky $newIncidentUserName & Case( $StopAutoScript <>1 // global when set to 1, script cannot fire and $UserName<>$LastUserName //previous contents and $UserName <>""; zippScript_PerformScript( Get(FileName); "_ZippScript_DoThis";"";0) ) script: _ZippScript_DoThis --------------------------- Freeze Window if [count(UsersTable::ID)=1 // relationship based on $userName] # only 1 user, set type ahead $username field with the found relationship Set Field[myTO:$StopAutoScript; 1 // set to 1 to prevent this script from firing again] Set Field[myTO::$LastUserName; UsersTable::FullName] Set Field[myTO::$userName; UsersTable::FullName] Set Field[myTO::$StopAutoScript; 0] Commit Records/Requests[skip Data Entry Validation; No Dialog] elseif [count(UsersTable::ID)>1] # More than 1 possibilities set my username to current value and set selection Set Field[myTO::$LastUserName; $UserName] Commit Records/Requests[skip Data Entry Validation; No Dialog] Set Selection [myTO::$userName; startPosition: Length(myTO::$userName)+1; End Position: Length(myTO::$userName)+1] else #no possibilities Beep Set Field[myTO::$LastUserName; $UserName] Commit Records/Requests[skip Data Entry Validation; No Dialog] Set Selection [myTO::$userName; startPosition: Length(myTO::$userName)+1; End Position: Length(myTO::$userName)+1] End if Note: $ before field denotes Global field

custom function paramByName(name) = Let(ParamValue = Evaluate( " Let([" & Let(Plist = Trim(Substitute(Get(ScriptParameter); // Deal with empty parameters [":";"="];["

I am not sure what you are asking here, but I don't see any problem -- the user is relogging in on his/her machine. I would assume one machine, one user. The other machines are logged in independently of this. The key thing is that I have the global relation back to the front end so that the backend can get the current user of the frontend through a calculation) Other users currently logged in should not be affected. (In my situation, there seems to be no affect -- I have 4-5 users logged into my backend at the same time (as "regularuser"), and there is no problem we me relogging in as "developerPrivileges" into the backend) The offshoot of this though is probably the fact that server logs will show "privileges" logged in, not "users".

The key thing to know here is that the account and passwords of all opened databases don't have to match. -- That is, if you have a backend DB opened under one account/password/privilege set, and the front end open under another, any backend table occurence in the frontend database will use the privileges that the backend database is currently openned under -- NOT the privileges that the frontend is opened under. If you relogin to the backend database with different privileges, you will have those different privileges in the front-end layout that draws from the backend database. The implication of this is that the user accounts only need to be on the front end database. For example The backend databases have accounts based on privilege sets... forexample: accounts NAMED DataEntryWithDelete, DataEntryNoDelete, etc, each with its own concordant privilege set (no need to have multiple accounts for any given set). In otherwords: every PRIVILEGE SET of the front end database is a USER in the back end databases. Each backend database has a script: "Re-login [account password]" that takes the accountName and the account password on Startup the frontend database runs a login script that will call the "Re-login [account password]" in each backend database based on the user's privilege set in the front database and the appropriate password for the backend end usage set. This way the user can set his/her password at will -- without any script that try to proprogate that password throughout the system. Also a change of user privilege sets in the front end will mean concordant changes to user privileges throughout the system. By the way, you should set up in each database, a startup user and password that has extremely restricted privileges (ie view new data, view only splash screen layout: run only the relogin script) set the backend database to automatically open with this restricted user. For example: In the frontend JoeSmith is member of "CannotDelete" privilege set In the backend: There is no JoeSmith user "CannotDelete" is a user who is a member of "PS_CannotDelete" whose record delete privilege is set to off When JoeSmith logs into the front database, the login script gets his privilege set ("CannotDelete") and calls the back-end's "Relogin" script with parameter "CannotDelete supersecretpassword". You can have the same supersecretpassword for each of the backend user/privilege sets (not as secure) or 2) use an if else ladder in the login script supplying the appropriate password parameter for each privilege set -- ok for few privilege sets or 3) set up a table in the frontend database that associates the privilege sets with the backend password (just make sure only the full access/admin users can see this) What if you want to set backend privileges based on account names? If you want to set a privilege in the backend contingent upon the account name (eg edit only own records) of the logged in user (int the frontend) then build a relationship in the backend to the front end to get the user logged into the front end. in front end: make calculated field "CurrentAccount" = get(accountName) (do not store) in a table, say "Globals" create a global relationship from backend to frontend "Globals" table In the back end create a user: "CanEditOwn" who is a member of "PS_CanEditOwn" which has the record level control set to edit only own records. ie edit only when field recordcreator = Globals::CurrentAccount If you were to have an accounts table you could actually associate different privileges in different backend databases by user For example: JoeSmith has privileges of "CannotDelete" in Personnel database JoeSmith has privileges of "CannotView" in Salaries database SallyBrown has privileges of "CannotDelete" in Personnel Database SallyBrown has privileges of "CanView" in Salaries database; SallyBrown has privileges of "Full" in budgets database; When JoeSmith logs in, the script finds his records from the account table and logs into Personnel as "CannotDelete", then logs into Salaries as "CannotView" and does not log in to the budget database. When SallyBrown logs in, the script finds her records from the account table and logs into Personnel as "CannotDelete", then logs into Salaries as "CanView" and logs into Budgets as "Full" Scott LoginExample.zip

If I understand correctly what is being asked here, there is a much easier (with no plugins) way of doing it: FMP7 has a new calculation: Get ( CalculationRepetitionNumber ) ( rather than get(activeRepetitionNumber) -- useful in script)) What this will do is return the number of the repetition in a calculation. You could use it in a calculation on a repeating field as such: case(Get ( CalculationRepetitionNumber ) = extend(field 2),"X") Edit: Note that this will work if the calculation is an actual calcuation (not an autoEnter Calcuation) If you want the user to be able to edit the values in repetitions then what you need is three fields: RawData: text field with 10 repeating values RepNumber: Number field ModifiedData: Calculation field of type text with 10 repetitions. Calculation: if(Get ( CalculationRepetitionNumber ) = extend(RepNumber); "Whatever"; GetRepetition(RawData;Get ( CalculationRepetitionNumber ))) If you want to give the appearance that the modified data an editable field (ie non-calculated field), you coul place the ModifiedData field on top of RawData with a opaque fill. Turn off "Allow field Entry" on the ModifiedData field. Now when you click on the repetition it go to the field belowit (field RawData)

I have been working on a modification to Ray's solution that uses a global field to specify the fields to be audited. This way fields can be easily specified without full access to a database -- or event specified different fields to audit according to different accounts -- It works quite well for less than 30-40 audit fields -- there is about a 1 second lag on a PB 500 for 80 audited fields (YMMV). This also logs IP address(es), Layout Table Name, RecordID, and ScriptName (if any). Fire me questions/ suggestions! Details: This technique uses a 4 custom functions (requires Developer): LogFeed; MergeOnKey, NotList, and TrimReturns Note -- I haven't cleaned up my work file. Otherwise I would attach it. -- maybe on the the weekend Function Name: LogFeed Parameters: fieldsToLog Calculation = //Note the

"Step" is sometimes known as "Step Over" -- it will not enter any subscripts (but it will execute the subscript) (ie steps over the subscript) "Step into" will move the debugger into any subscripts "Step out" will execute the rest of a subscript and then return the debugger to the next line of the script that called the subscript "Stop Execution" will stop the script altogether (without executing any more steps) Activating the debugger As far as I know there is no way except the checking the debugger option in the scripts menu of FMDev Though it would be nice to have a check box in the script editor dialog (FMI are you listening) And it would be nice to actually open the script for editing from the debugger rather than just the script editor. (FMI -- really? are your listening???)

I have found a couple differences between V6 and V7 for field name sorting. While I agree with the need for field name conventions (even with comments in v7) because when you import, or select field in dialogs, you don't have access to comments (can you hear me FMI???), I have never found Core Solutions intuitive... Generally, I use underscore preceding a stored Data field eg _name _email etc. The nice things about this in V7 is that these will sort to the top (not so in V6 though) # preceding calculations that are based on math eg: #countPortalRecords, #totalScore etc) @ preceding calcuations that are used for interface display For example @formattedName @statusIcon $ preceding Globals Eg: $result $currentUser % preceding calculation that are used to pipe data from relationships (not as important in V7 but still important) ! preceeding keys !fk_ preceding foreign keys !pk_ preceding primary keys k_CONSTANT for constants (calcuations = constant value) eg: k_NONE k_STATUSOPEN For table occurances: Even though relationships are by directional-- generally speaking I find that they are created (by in large) with single directional purposes in mind, and that purpose indicates a chain of the relationship So I use TableName#NatureOfRelationalPath for example: Laptop#byUser Laptop#byIncidentByUser I was using a full colon(: rather then # but found that there is a problem with this and merge fields. Unless use of relationship is directionaly functional in certain ways Eg: CreateUser CurrentLaptop

From your information, you are running developer 7. Take a look at your install cd for plug in examples -- there is an an example that has a runscript calculation. (called macexample.fmplugin or winexample.fmplugin I think) Anyhow, you can save yourself a few bucks if this is all you want to do. Mind you Activator goes way beyond what this plugin can do -- if you want to schedule scripts and run scripts on other computers runing fmp, activator is what you want.

The other thing I would love is the ability to give constants in the relational dialog -- this way I don't have to make a calculated field just to have a constant for a relationship. IE it would be nice to say a relationship where: Status = "Open" rather than: Status = k_OPEN where k_OPEN is a calculation = "OPEN" Maybe next version --- (the same version where they allow us to specify a field & repetition numjer to set (in set field script step) by calculation. (please oh please oh please)