• Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by LaRetta

  1. One more ... conditional formatting cannot make text transparent but instead one must set the font size to extremely large (can fail in some display situations and let part of the text show) or one can color it the same as the background. If you later change the background color and forget to modify the calculation, it will show.
  2. Hi Steve, I would suspect Hide is faster. Both redraw upon screen refresh but here are some thoughts on it: Hide is a boolean on/off whereas conditional formatting must interpret and redraw portions (each attribute) of an object so I suspect Hide would be more efficient. Hide applies to all objects within a group so one can hide an entire portal, tab control or grouped objects so is easier when dealing with multiple objects. Conditional formatting does not work on lines around buttons. Hide can (more easily?) apply also when in find mode. I am sure there are other considerations. In all, Hide is preferable in most cases whereas conditional formatting is geared towards changing a displayed attribute. Hopefully others will offer their impressions as well.
  3. I wouldn't mark the records if you can help it. You will end up with only those records so why mark them anyway? Do you have another reason to wanting them marked?
  4. I see no need to tag the records. What you want is a found set of only the records you want to import into, correct? The first set of numbers is the record number which is used to isolate the records and the second is the serial which happens to be same as record number but doesn't matter at all.
  5. I had just finished an example. See if this gets you closer to what you want. It appears this is similar to Comment's suggestion. Select#numRecords.fmp12
  6. Gilbert13, Comment asked a question and you never answered him. If you don't answer our questions, we will be unable to help you properly. :-) As a matter of fact, you never responded to Lee either. You are telling us what you want but not WHY. What is the reason you want this? Now you have two questions.
  7. This is cool, Michael, thanks for sharing it!
  8. 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.
  9. 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. :-)
  10. 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.
  11. 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! :-)
  12. 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. ;-)
  13. 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.
  14. 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.
  15. 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! :-)
  16. 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. :-)
  17. 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.
  18. 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.
  19. 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.
  20. Odds are, you will have many unmatched records. Data-entry is rarely ever a match particularly on street addresses, as Comment points out.
  21. 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. :-)
  22. 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.
  23. 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.
  24. Also, Replace Field Contents can not be undone so always back up your file before running it through records.