Jump to content

Roeland De Windt

Members
  • Content count

    20
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Roeland De Windt

  • Rank
    member

Profile Information

  • Title
    IT manager
  • Industry
    Advertising
  • Gender
    Male
  • Location
    Belgium
  • Interests
    Back from FMP v6
  1. Here's the script doing that. It takes 3 scriptparameters; "first" (on the only visible "Help" button), "next" and "last" (used in balloons). A bit rudimentary, but it works. Even after changing layout, the $$help variable is always reset to 1 when first called with the visible "Help" button. The balloons have been named "Help #" sequentially. A bit rudimentary, but it works. If [ Get ( ScriptParameter ) = "First" ] Set Variable [ $$Help; Value:1 ] End If If [ Get ( ScriptParameter ) = "Next" ] Set Variable [ $$Help; Value:$$Help + 1 ] End If If [ Get ( ScriptParameter ) = "Prev" ] Set Variable [ $$Help; Value:$$Help - 1 ] End If Go to Object [ Object Name: "Help " & $$Help ] My personal solution above allows for the hiding. Help only becomes visible (and only then) if the end user clicks the "Help" button, not automatically the first time the solution is started. Clicking outside of any balloon hides it again. My biggest problem was finding a generic "next and previous" script to use in each ballon to hop to the prev/next. However, I do like your auto-help idea the first time a user opens the solution (it was in my initial question after all).
  2. For a solution I would like on-screen help. I was thinking about using sequential popovers, taking a user in logical steps through elements and functions on a layout. Much like one would often see when using an iPhone/Android/web application for the first time. I have gotten as far as putting some (invisible) popover buttons on a layout. I have given their popover balloon a layoutobjectname, so I can use Go To Object to call and show them. I call the first one directly with a (visible) "Help" button. The problem I run into is that I would like to be able to navigate from one balloon to the next (or previous) one in a logical, sequential order. Sure, I can put a button in each balloon with another Go To Object step, but I would need to manually and uniquely adapt each button script to call for the 'next' balloon. Imagine the nightmare if I decide to insert a balloon between step 1 and 2 in a 10-step onscreen help sequence. A more elegant solution would be to layoutobjectname all balloons sequentailly, i.e. Balloon 1, Balloon 2 etc, and have a generic previous button (except in the first) and next button (except in the last) balloon, calling the prev/next balloon. The problem is that I fail to get the activelayoutobjectname of the current popover balloon, so I can't do maths the calculate the previous or next one. The only alternative I see is using a global variable where I keep track of which ballon I'm in, and calculate the previous/next one from that. Any ideas? Or links to working solutions?
  3. Roeland De Windt

    Delete Related Records, what if multiple parents exist?

    @comment But... ...don't know what to say honestly. This is my relationship diagram (ANSWERS cyan on the left, REMARKS green next stack middle), is it wrong then? It works perfectly for showing groups of answers (defined by QuestionPool_ID) for an employee (Emp_ID_Evaluated) with a general remark alongside it. @dwdata Thanks for that! Scripting to the rescue.
  4. Forgive me if this has been aswered before, but couldn't find anything that answered my question. Table ANSWERS Table REMARKS In the relation definition between them, I have the ANSWERS on the left, and REMARKS on the right side, with Allow Creation and Delete Parent checked on the right side. Now the situation is that there can be multiple ANSwers with one and the same REMark. In effect, For each of the ANSwers, the same Remark will be shown. This is desired behaviour. If I delete 1 (out of ex. 3 ANSwers), the sole REMark is deleted as well. I was hoping to be able to define in the relation that the parent record be deleted when "all records are deleted" in stead of "a record is deleted" in the other table. I want the REMark only to be deleted if the last ANSwer linking to that child REMark is deleted. Doable without scripting?
  5. Roeland De Windt

    Hide records based on current login and layout

    Final solution, after comment's last post (clarifying the non-security issue in ANSWERS table depending on role)... Manager Role, View privset: not IsEmpty ( FilterValues ( zc.Emp_Manager_UPN ; Z_GlobalValues::CurrentAccountName ) ) or not IsEmpty ( FilterValues ( zc.Emp_Evaluators_UPNs ; Z_GlobalValues::CurrentAccountName ) ) Manager Role, Edit privset: not IsEmpty ( FilterValues ( zc.Emp_Evaluators_UPNs ; Z_GlobalValues::CurrentAccountName ) ) Evaluator Role, both View and Edit privset: not IsEmpty ( FilterValues ( zc.Emp_Evaluators_UPNs ; Z_GlobalValues::CurrentAccountName ) ) And then I have 2 separate OnLayoutEnter scripts, both finding records in the same ANSWERS table, but depending on current layout Manager layout: finds CurrentAccountName in Manager field Evaluator layout: finds CurrentAccountName in Evaluator field As for security, indeed, a Manager may manually find records in the Evaluation layout (because he is listed as manager) that he needn't answer, but he won't be able to edit as per privset. The above OnLayoutEnter finds should cover that situation. Seems to do the trick. Simple solutions are often the best!
  6. Roeland De Windt

    Hide records based on current login and layout

    Manfred should not be able to change answer fields in any record but those where he is listed as evaluator. I have already limited this Edit access for the manager privset: If ( PatternCount ( Get ( LayoutName ) ; "Manager" ) ; // should be rewritten as 'not isemtpy filtervalues' like in View privset 0 ; PatternCount ( Evaluators ; Z_GlobalValues::CurrentAccountName ) // should be rewritten as 'not isemtpy filtervalues' like in View privset ) This works. No edit access on manager layout (0) for anyone (view yes, only if listed as manager), and on the evaluator layout only edit access when listed in field Evaluators. Now one step further would be to hide the records altogether when on Evaluator layout. Sorry Lee, Steve's original link is still bad. Yours works. I'll refrain from editing my posts after answers come in, good point.
  7. Roeland De Windt

    Hide records based on current login and layout

    Yes there is a point to deny imho... MANfred has role MANager, EVEline has role EVAluator (role = privilegeset). Record 1: Manager field = Manfred, Evaluator field = Manfred, Answer field = x1, EmployeeName field = y1 Record 2: Manager field = Manfred, Evaluator field = Eveline, Answer field = x2, EmployeeName field = y2 Record 3: Manager field = Manfred, Evaluator field = SomeOneElse, Answer field = x3, EmployeeName field = y3 Eveline will have access to Evaluators layout only, and see only records with her name in Evaluator field (Record 2 in this case) so that's no problem. Manfred will have access to both layouts. In the Manager layout he should see all 3 records, ok. In the Evaluator layout Manfred should only see Record 1, as he only needs to evaluate (to ACT on) that one. It's not only a matter of convenience: Manfred should not see Records 2+3 in Evaluation view. You could argue that I should assign an Edit limitation in for field Answer field x (and I have, only editable by Evaluator roles), but I thought it wise to hide the records altogether (as Manfred has no business there anyway).
  8. Roeland De Windt

    Hide records based on current login and layout

    Link works for me...
  9. Roeland De Windt

    Hide records based on current login and layout

    Thanks Steven, I see "LayoutNames, ... since they can be spoofed" under the Inappropriate column, and not endorsed as Best practice. But should or should it not work technically? Shouldn't FMP throw an error if I try to use them? Or do they work from a technical pov, but is my syntax wrong? Any workaroud to accomplish the same thing?
  10. One table ANSWERS, 2 fields EVALUATOR and MANAGER (and a lot of others with more data), 2 layouts Evaluator and Manager, based on the same table. I want to hide records based on the layout AND the current logged in user's appearance in either of the 2 fields. (Managers should only see records when they are in the Manager field, and Evaluators when in the Evaluator field). The Manager layout is not accessible by Evaluators. The Evaluators layout is accessible by both roles (as some Managers are also Evaluators). Now I have a "Limited..." View restriction for Privilege set "Evaluators" that is this: not IsEmpty ( FilterValues ( Evaluators_Names ; Z_GlobalValues::CurrentAccountName ) ) Which works fine for Evaluators; if they do a Find *, they see only 'their' records. Now, I have a "Limited..." View restriction in a Privilege set "Managers". A bit more complicated this time, because it depends on the Layout being viewed: - Managers should see all records where they are listed in the Manager field on the Manager layout, but should only see records where they are in the Evaluator field on the Evaluator layout. Remember that they can be in both. ( not IsEmpty ( FilterValues ( Get ( LayoutName ) ; "Manager" ) ) and not IsEmpty ( FilterValues ( Manager_Name ; Z_GlobalValues::CurrentAccountName ) ) // one and only one ) or ( not IsEmpty ( FilterValues ( Get ( LayoutName ) ; "Evaluator" ) ) and not IsEmpty ( FilterValues ( Evaluators_Names ; Z_GlobalValues::CurrentAccountName ) ) // can be multiple evaluators ) When a manager logs in (and a script Find *), he sees NO records in the Evaluator layout (although I'm certain he is in some Evaluator fields), nor in the Manager layout (same thing with Manager field). If I leave out the LayoutName lines, all records show in both Layouts, (the middle OR statement works) but this is not what I want (while 'managing', a Manager should not see the records where he is Evaluator only). 2 possibilities: My logical testing is wrong (I doubt it, I've tried to verify this logical testing with a calculation field based on the same criteria, and there everything checks out fine.) The logical structure is ok, but it doesn't work as expected for a limiting view Privilege sets. (Something to do with syntax, or impossible to use LayoutNames testing?) Please help if you can...
  11. Duh! Changed my conditional to: ValueCount ( FilterValues ( QUE::Emps ; QUE_ANS::_Emp_IDfk ) ) Seems to work! No pre- or post-pending needed. A lot cleaner. Thanks again, comments
  12. I elaborated a bit on this technique, more specifically the showing/hiding of things in portal rows based on conditionals. I wanted to show or hide a "delete portal row" button in a QUE_ANS portal on a QUE layout using this conditional statement PatternCount ( QUE::Emps ; QUE_ANS::_Emp_IDfk ) > 0 QUE::Emps is a multi-line field holding Employee IDs. QUE_ANS is a portal on the QUE layout, based on QUE::__Question_IDpk = ANS::_Question_IDfk. QUE_ANS::_Emp_IDfk is a single-line field holding an Employee ID. My challenge is to SHOW the "delete portal row" button on a row in the QUE_ANS portal in case the QUE::Emps does NOT contain the QUE_ANS::_Emp_IDfk value. I soon found out that PatternCount has its flaws: the conditional statement above will evaluate as TRUE if QUE::Emps holds for example "99" and QUE_ANS::Emp_IDfk is "199", even if those values are not equal. There seems to be no xCount function for an EXACT match of numbers (or words). The functions "ValueCount" or "WordCount" are no use, as they take 1 parameter only, they count things, they don't search. The function "Exact" compares ALL of QUE::EMPS with QUE_ANS::Emp_IDfk, not a single line, so no use either. Google to the rescue. I changed my conditional to: PatternCount ( "¶" & QUE::Emps & "¶" ; "¶" & QUE_ANS::_Emp_IDfk & "¶" ) > 0 Pre- and post-pending both base and search string in the PatternCount function with a paragraph character seems to do the trick (as the search string must now be a whole line). Can anyone confirm? Or any better techniques without the use of Custom Functions (no FMP Advanced here)?
  13. Roeland De Windt

    Lookup related values from variable, not field

    In short: can I use relations with variables instead of fields. Guess not. Got it working with a global. A non-issue I just would like to see confirmed.
  14. Roeland De Windt

    Lookup related values from variable, not field

    Good questions, comment. Bare with me as I explain in more detail. TableA contains evaluation questions, 1 per record. Every record has a multi-line employeeID field holding IDs of employees in TableB, who will be evaluated. How this multi-line field is populated is beyond the scope of my question, but the bottom line is that I didn't go for a many-to-many relationship setup. To assign questions to employees, I've created a third TableC, where later on, an evaluator of the employee will need to put his answer. Now to create a record in TableC, I need to get the TableA::QuestionID, and then loop through all values in the employee multi-line field to get each one. For every combo, a new record is created in TableC. Now, in the process, for every employeeID-questionID combo, I need to look up an evaluatorID to put in the newly created record in TableC. I don't seem to be able to do this without putting the employeeID in a global from which the "evaluator" value is calculated. PS, should have said "pull the calculated value", not "related", as it involves a LOT of If statements and different relations from them. It's not a simple case of always using the same relation). Now... you mention a technique to pull all related values using List ( Relation::Field ), but this won't work because of the mentioned If statements and different relations.
  15. Situation: a TableA with record(s) containing a multiline field (which happens to be a multi-line key) which I am looping through in a script. I need to lookup a related value from another TableB on each loop. Currently I have to set a (global) field in TableA to the n-th value of the multiline field at each loop and pull the related value from a relation based on that (global) field (TableA_TableB). Question: is there a way to script this using only variables? ie: Set $SomeRelatedValue = LookupValue ( TableA_TableB::LookupField , $SomeGivenValue ) or: Set Field [ TableA::SomeRelatedValue ; LookupValue ( TableA_TableB::LookupField, $SomeGivenValue ) ] The LookupValue function is the one I am looking for and don't seem to be able to find. Solved it by using a global, as I said earlier, but I would like to use only variables. Anyone has a hint on how to do lookup from variables instead of (global) fields?
×

Important Information

By using this site, you agree to our Terms of Use.