Jump to content

Rob P

Members
  • Content Count

    56
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Rob P

  • Rank
    member
  1. You might be right but I'm a portal fanatic and prefer to keep my users a layer away from the data.
  2. Does anyone have a solution for resolving date and time conflicts? Here's what I mean. In a portal I'm displaying a series of collected timestamped events for an employee (Time tracking). This is the administrative view that allows an admin to edit, add or delete entries made by the employees. Being the feature it is, the admin could accidentally enter or edit an entry that overlaps the time value of another entry. Now I don't want to prevent that but I do want to display the result (conditional format) and draw attention to the conflict. Each record has a start and stop timestamp a
  3. For starters you are complicating your life. Use a custom function to explode you text. Here's my version of it. /* Name: TypeAhead Params: text Function: */ /*Builds a multi-line key that can be used in relationships using recursion*/ Let ( x = Length ( text ); If ( x > 0; Left ( text ; x ) & "¶" & TypeAhead ( Left ( text ; x - 1 ) ) ) ) /* Notes: Rob Poelking */ and this one /* Name: TypeAheadWords Params: text Function: */ /*Builds a multi-line key that can be used in relationships*/ Subst
  4. What happens if you try to import from a local copy of Masters?
  5. Rob P

    Layout and found

    Record " & Get ( RecordNumber ) & " of " & Get ( FoundCount ) & ": ( " & Get ( TotalRecordCount ) & " Total )" & "
  6. That's pretty much what I'm seeing. It's sticky and you're not quite sure when it will change. So, the conclusion is, if you're looking for lively updates, go with the less sticky unstored calc. But if this is something that is supposed to be relatively static, global stored calc is fine.
  7. Well, see, that's just it. That IS the work around, that you have an unstored calc, but that becomes an unnecessary data field in every record when it should in fact act as a global. FM treats globals on a different level than data fields in that respect. So what I'm trying to get at is, what is the point of global storage on a calc field? How can I, as the developer, leverage that potential?
  8. Hey Soren, I can usually make out what you are saying but this time I got lost in your response. Why use a global calc? Well, to be honest, at the moment I don't have a good example because I have had to work around them for so long that I just never use them any more. Hence the question, how do YOU use global calcs. I wanted to see how the developer community has utilized the feature. I figured it was just something I was missing. I'm not quite sure what d1132 meant. I use globals to drive relationships all the time. Come to think of it. I've got an example for you. Let's
  9. I was very excited when FM introduced global storage on calclations, oh, way back I think in FM7. However, I have yet to make it work. How have you used global storage on a calculation successfully? It seems that any time I've tried to use it, whatever value it has at startup is stuck there for the entire session and never changes regardless of the dependencies it may have. I found this particularly frustrating. What is the point of having a globally stored calc, if it never changed based on the dependencies. That puts you back to an UNstored calculation on every record to achieve
  10. That's only true if NONE of the values could evaluate. I'm sure his Items:itemID does evaluate to something. His initial conclusion is correct. You have to extend any part of the calculation that is not a repeat.
  11. That still did not work UNTIL I quoted the value. Thanks a million. You may not see it's purpose now but perhaps somewhere you'll want to declare a variable on the fly. Let ( [ expression = "Let ( $$" & $myvar & " = " & Quote ( $myval ) & "; 0 )" ] ; Evaluate ( expression )) And yes your assumptions are correct.
  12. I want to know if anyone has done this and how. Here's the situation, you want to create a global var on the fly. You don't know the name or value until you instantiate it. I was trying to create a script that would allow me to create a named var on the fly rather than explicitly naming it. My first attempt Let ( [ expression = "Let ( "$$" & myvar = myvalue" ] ; Evaluate ( expression ) ) results in an error because you cannot concatenate the name value in the LET statement. Second attempt Let ( [ var = "$$" & "myvar" ; val = myvalue ] ; Evaluate ( var = val )
  13. Take care of the family! I'll have to proceed with a 2 portal solution but it's not as elegant or user friendly so if you have a solution I'd gladly integrate it.
  14. Your solution effectively answer the "OR" but it does not answer the conditional. There are 3 possible lists I want. Lets say in your list everyone is Mike, Pat or Bessie. Some of these records have a last name. 1) I want to see all Bessie's that don't have a last name. 2) I want to see all last names that are Ford. It is understood that all Fords also have a first name of Bessie but I don't want to see any Bessies that don't have a last name. 3) I want to combine list 1 & 2 - All Bessie's that don't have a last name AND ALL Bessie Ford's. The problem is that 1 &
  15. Thank you Søren, I'll look at that and see if I can implement it. Looks like the solution though.
×
×
  • Create New...

Important Information

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