• Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by LaRetta

  1. Such a calculation would be stored and thus would not be slow. Then field [A] is a multiline that you need to report on its individual values separately? I suggest you consider using another table.
  2. Hi Monarch, would you explain the purpose of this? Is it so a User can select a time which must be stored in the table? Is it for the developer to provide the User with feedback of some sort? Knowing what you wish to do with this information will help us determine what to provide. :-)
  3. I explained what you need to do to accomplish your request. If you begin working through it and trying my suggestion, you can then post a question if you get stuck. Here is an example file by Comment which shows a basic join relationship between Invoices and Contacts illustrating the structure needed and as I have explained in my prior post: and download the InvoicesDemo.fp7 file. As for selecting the customer, you can use a value list or a portal for filtering down your customer selection. Once you get the structure in place and understand my prior post, you can decide whether to select customers via a portal instead of using a value list. Usually, we use a portal if the value list will hold more than a few dozen entries. But you will TRULY want to understand how this join relationship is working AND understand how to create value lists so spending some time in the trenches absorbing these principles will be highly beneficial at this point.
  4. Hi Randy, If you happen to place that field on a different layout and DO allow entry to the field or if there is an import then the field is not protected. Layout protections are used only to enhance data-entry and Security should be in force as needed. I mention it more for other readers since I highly suspect you've taken that into account. You've touched a fine point in layout/scripting behavior. Good observation. Yes, one of the differences between a single step ( button press ) versus script step is that a button is User-driven so User layout rules are applied whereas a script overrules User layout constraints. Nice to see you again! :-)
  5. Assuming there will only be one customer on a single work order, what you describe is known as a one-to-many (one Customer AKA 'parent' to many Work Orders AKA 'child'). You only need the fields (other than the ContactID) if you need to preserve their value for history/audit purposes. For example, if you enter the shipping address but later the Customer changes their address, you want the old Work Order to display the Customer's address at the time of the shipment. So, with Invoices, Work Orders, Contracts and such, it many-times makes sense to duplicate the data into your 'child' (Work Orders) table. You place the parent's unique key (CustomerID) in the child's table. Then, from perspective of Work Order, you select the CustomerID in the Work Orders::CustomerID field using an attached value list which is based upon data, left pane is CustomerID, right pane is customer name, all values, and below, display values from second field. Use a popup control. If you use a drop-down control then it will only display the ID after User leaves the field and you will be required to place the Customers::name field next to the ID for display. The relationship will be: Customers::customerID = Work Orders::CustomerID If you need to retain the data, create duplicate fields in Work Order and use either auto-enter or Lookup to have the values in Work Order fill in when you create a new Work Order. If you do not need to insert the data static, you can always simply display the 'parent' values on your child layout. After creating the relationship, simply place the fields from Customers directly onto your Work Orders layout, select a Customer ID from the value list popup and watch your values fill in or appear on your layout from Customers. There are various training videos and sample files around showing how to create a simple 1:n (one-to-many) relationship using IDs. Do not be tempted to use names for these KEY relationships. You want to use a meaningless ID because otherwise, if you change a name and it is used for a relationship, you can break your relationships and broken relationships are never a good thing. ;-)
  6. You can also use Export Field Contents and skip specifying the field. There are a few more ways as well, such as exporting 0 records using same path file name. All similar principle so it's which you like best. I like Export Field Contents; picked up from Comment, I suspect.
  7. I wonder if it wouldn't be easier to create a summary field (maybe called sDeliveryRemaining' which is 'Total of DeliveryRemaining. Then script could check this value as: If [ not sDeliveryRemaining ] ... then do 'the thing' you wish. Sorry for the glitch.
  8. Hi Wayne, to explain a bit more ... not only does copy destroy a User's clipboard contents (usually needlessly, as Comment explains) but paste requires that the field being set exists on the current layout. Down the road, you may remove that field and cause your script to fail, forgetting that it is dependent upon that field. No such issues exist using Set Field[]. And welcome to FMForums! :-)
  9. Hey there, Datalink! In future, you can always post again on your thread, even just typing 'bump' ... which will bump it up into everyone's view again. It is easy, because we all (including you) are busy, for things to just slide by. By keeping everything in a single thread, it helps us in by reading what others have suggested and your other discussions about the issue. :-)
  10. No need to be sorry at all, Chris. :-) These types of discussions ( should ) take place in almost every solution. Usually the discussion involves names, such as when seeing if a Contact already exists before allowing creation of new contact.
  11. So would I! I started to go into details about an advanced search and presenting User with possible matches for selection but I decided to see if Chris wanted to go that route after realizing substantial number of non-matches. But that seemed a separate issue from colorizing a button which would simply show whether the IncidentReport record has found its match without intervention. As usual, you are ( rightfully so ) ahead of me.
  12. Hi Michael, I assumed ( wrong of me, I know ) that the button would simply indicate that a search must take place to try and find the PrePlan match for the Incident Report address. So if the button is red, clicking it would perform an advanced find in PrePlan for the right address.
  13. Odds are, you will have many unmatched records. Data-entry is rarely ever a match particularly on street addresses, as Comment points out.
  14. For valid relationships ( those that match ) then what I said above should work fine which is ... make the button on your IncidentReport layout red then create conditional format on the button with: not IsEmpty ( PrePlan::Address ) ... and specify green for the fill color based upon the understanding that the field PrePlan::Address is the key field in the relationship or is never empty. :-)
  15. I thought that would have been clear in this case since Chris knew a space might break it, but you are right that it might not be clear for everyone viewing this thread so it was certainly worth mentioning, and I should have done it! Thank you, Michael.
  16. Ah yes, that makes sense since we all ( at times ) face issues where we cannot control the data we receive. I corrected my above statement, since such a rigid statement is not accurate: From: You should be using a unique ID for the address to join your relationship. To: Under normal circumstances, you would use an address's uniqueID to join your relationship.
  17. Also, Replace Field Contents can not be undone so always back up your file before running it through records.
  18. If the relationship is valid, IOW, if you can place PrePlan address on your IncidentReport layout and it displays an address, then the conditional format should work fine. It sounds like you have it backwards. What color is the button normally? Green or red? What is the exact formula you've entered in the conditional format and what color is specified? The key on both sides of a relationship should match same data-type and since it is address, both should be text. Yes, a space will break the relationship. BTW, this would have nothing to do with a find that you perform from the button. If there are no related PrePlan records, your find would fail. This involves only display of color on a button, regardless of the action the script performs. What you might wish to do is run a Replace Field Contents on the address field (after showing all records), with formula of: TrimAll ( PrePlan::Address ; 0 ; 0 ) And repeat on IncidentReport table. Then see what kind of matching you get. I suggest an Auto-Enter ( Replace) be established to remove spaces but ... you really shouldn't be matching on the exact address anyway because its value can change and that will break the relationship. You should be using a unique ID for the address to join your relationship. Under normal circumstances, you would use an address's uniqueID to join your relationship.
  19. Hi Chris, As Lee indicates, you test to see if the value exists. The value you are looking for, from the perspective of IncidentReport, will be looking through the relationship to PrePlan so your conditional formatting would be something like this: IsEmpty ( PrePlan::Address ) By the way, this is prime case where one can apply branch prediction. Will the majority of IncidentReport records lack a related PrePlan address? If so, color your button initially red since that will affect most of the records then apply not IsEmpty ( PrePlan::Address ) to turn it green. Or reverse the logic. Either way, one color of the button should exist and the other be conditionally applied. There is no need to apply both conditions.
  20. Happy New Year to you as well, Rick. 2017 is going to be a ROCKIN' year just as 2016 was!!
  21. I have a file created in version 11.0v4 (Mac) which has several import scripts in it, importing from one table to another. It indicates on the Import script-steps: Import Records ( "$pathToMe" ; Add ; Windows (ANSI) ] If I convert the file to version 12 and open it in version 12, every one of the import script steps display same thing. However, if I instead open the fp7 version 11 file in version 13, 14 or 15, all of the import script steps instead display: Import Records [ "$pathToMe" ; Add ; Korean (EUC-KR) ] Nothing has changed in the file between when it was fmpa11.0v4 and the next version. I converted the files immediately, closing the version after each conversion. The only reference I can find about it is here in Knowledge Base ( searching FM Help for 'Korean' returns nothing): (EUC-KR)/session/L3RpbWUvMTQ4MjIxMzU4MS9zaWQvdHNrUTlBNm4%3D Has anyone else noticed this and does anyone know why? It doesn't make a difference in my imports but it bothers me that I do not understand WHY it has changed. And why to Korean? I've also searched TechNet and find nothing about it.
  22. Hi, thank you for responding! I don't have a problem ... I was only trying to understand why the change from Windows to Korean when the same fp7 file is opened in different FM versions and what change, under the hood, happened in version 13 to cause that change. I can't be the only person that wonders about these kinds of things. :-)
  23. Hi Rob, I suggest that you also check out this custom function which preserves the case (whether capitalized or not) of the search phrase. In all, it is a better custom function. Sorry I didn't find this CF before I wrote mine above. HiliteSingle ( text ; searchString ; color ) Note that you should use the CF Comment has listed further down in the link instead of the original one. And you'll need to change from highlight to bold but I'm sure you can handle that! :-)
  24. You can use a custom function. Here is one which will work: /* boldSelectedText ( text ; search ) purpose: bolds the search characters within a text string */ Let ( [ bolded = TextStyleAdd ( search ; Bold ) ; len = Length ( search ) ; pos = Position ( text ; search ; 1 ; 1 ) ] ; If ( Length ( text ) ; If ( pos ; Left ( text ; pos -1 ) & bolded & boldSelectedText ( Right ( text ; Length ( text ) - pos - len +1 ) ; search ) ; text ) ) ) I've attached a file which shows how it works. I am sure there are better custom functions. You would need to capture the search criteria. You can have the User enter the search string into a global field or enter find mode and then capture that value for your calculation. You could also use a script. Instead of creating a calculation in your data table, I would use a PLACEHOLDER field. I've provided a few examples. PLACEHOLDER fields are great to eliminate calculations used only for display. Keep in mind that PLACEHOLDERS 1) must remain empty and 2) will not display in preview or print. BoldSearched.fmp12