comment

Members
  • Content count

    27,429
  • Joined

  • Last visited

  • Days Won

    504

Everything posted by comment

  1. In all the given examples, you can populate AddressNumber as = LeftWords ( AddressOld ; 1 ) and AddressStreet as = RightWords ( AddressOld ; WordCount ( AddressOld ) - 1 )
  2. Could you post a representative example of the "old" contents? If the format is not consistent, post several examples representing the most common arrangements. Hopefully, you do not have a field whose name contains a forward slash?
  3. To tell the truth, I don't know nor particularly care. This forum's engine has many features that are more suited to a social site than the professional one it is. I would suggest you complete your profile to show your version and OS, though.
  4. Drag and drop is sort of possible (see http://fmforums.com/forum/topic/67781-script-triggers-and-drag-drop-incompatible/), but far from being simple. For a method using buttons, see http://fmforums.com/topic/60325-manually-reorder-portal-records/#comment-285451 Note that before deciding on any specific method, you need to consider whether reordering performed by one user should take effect for all users alike (which would also require that the records being reordered by one user will not be locked by another).
  5. Where do you get this information? My understanding is that you can run it on both: http://help.filemaker.com/app/answers/detail/a_id/4701/kw/system requirements
  6. The nitpicker in me cannot resist telling you do have a choice: downgrade your OS. The scientist in me cannot resist telling you that your test is inconclusive. Why haven't you used the trial version on the same system? What if the real cause is a faulty memory module?
  7. You don't need a field for this. Just insert the Record Number Symbol into the first portal row - see: http://www.filemaker.com/help/15/fmp/en/index.html#page/FMP_Help/inserting-variables-on-layout.html
  8. I wouldn't import anything from your current file. The purpose of this exercise is to see if it's your file that causes the problem, or the system. If you use any parts of the suspected file, you can't be sure.
  9. That is a possibility - but before you jump to conclusions, I would suggest you see if you can reproduce the problem in a brand new file. One that has never crashed before.
  10. You may want to lookup the Fast Summaries method.
  11. IMHO, the procedure to find out which room occupies which pages will be more complex than producing a separate report for each room - see: http://fmforums.com/topic/30553-index-page-or-table-of-contents/#comment-137919
  12. How exactly is this field defined (in the Service table)?
  13. I don't understand your question. Do you already have a table where each record holds the name of one of the image files in some folder? If so, all you need to do is add a calculation field (with result type set to Container) and let it calculate the path to the corresponding image file. This is assuming your goal is just to display the image). In any case, the logic you have outlined cannot work, because Filemaker cannot loop among the items of a folder (at least not v.11, not without a plugin).
  14. So why don't you do just that? Go to Portal Row [ Last ] Go to Portal Row [ Select; Previous ] Duplicate Record/Request Set Field [ Service::Service Date; Get ( CurrentDate ) ] This is assuming that: there are no other portals on the layout; the relationship is defined to allow creation of records in the Service table; the record you want to duplicate is shown in the last non-empty portal row. Note that if the Service Date field is defined to auto-enter the current date, you won't need the last step. --- Two unrelated notes: 1. As a general rule, you should avoid using copy/paste in your scripts, if only because it destroys the user's clipboard. 2. Your script reveals that you have numbered fields (Machine 1, Machine 2, Machine 3, etc.) fields in both tables. That's a symptom of poor structure. You should use multiple records in a related table.
  15. I guess. These is really a side issue, unrelated to your main question here. Whatever solution is found to that, it can be made to work with YES/NO values, too - just a bit less elegantly. The value list has nothing to do with the calculation. It only helps with data entry and formats the field for display; the calculation works off the actual data in the field, and is unaffected by how the field is formatted on the layout. I am not sure it matters how many you have. And as I just said, making them numbers will not solve the show/hide problem.
  16. Not really. How many records do you have? An what happens if you insert a short pause (say 1 second) into the loop?
  17. I am afraid I remain confused. Browsing is one thing, printing and PDF-producing is another. You cannot switch layouts during printing.
  18. Another option is to place the objects inside a portal, and make sure that a related record exists or not, based on the selection. It's not quite clear what exactly your need is: do you want to show/hide the fields when printing, or during data entry, or ... ? Your mention of exporting is especially confusing, as that has nothing to do with what's shown on the layout. Anyway, script triggers play no role here - unless you are browsing records in Form view, and want the layout to change according to the loaded record's status. --- BTW, I would recommend you use 1/0 (or 1/empty) for Boolean fields, instead of YES/NO - see: http://fmforums.com/topic/47570-set-a-field-based-on-portal-content/#comment-222189
  19. In the Export Record [] script step, click `Specify export order` and select "Unicode (UTF-8)" from the `Output file character set` popup menu.
  20. A Filemaker path will begin with the drive's name - see: http://www.filemaker.com/help/15/fmp/en/#page/FMP_Help%2Fcreating-file-paths.html%23 If the target folder is located within your Documents folder, then you can define the $path variable as = Get( DocumentsPath ) & "WORK/oea/EXPORTS/" & housewinner::serial_number & ".php" and let Filemaker worry about the rest. -- P.S. Do note the edit I have made to my previous post. It makes no difference to your current script, but if you ever decide to start by performing a find instead of exporting all records in the table, it will.
  21. If you want a separate file for each record, you will have to loop among the found records - and you will have to isolate each record in turn so that it's the only record in the found set when it's exported. So your script will look something like: Go to Layout [ “YourTable” ] # FIND THE RECORDS TO EXPORT Show All Records Go to Record/Request/Page [ First ] Loop # ISOLATE CURRENT RECORD New Window [ ] Show All Records Omit Record Show Omitted Only # EXPORT CURRENT RECORD Set Variable [ $path; Value:"/YourHardDisk/path/to/the/Export/" & YourTable::serial_number & ".php" ] Export Records [ File Name: “$path”; Field Order: YourTable::export ] [ No dialog ] Close Window [ Current Window ] Go to Record/Request/Page [ Next; Exit after last ] End Loop For simplicity, we are assuming that no one will be creating new records in this table while the script is running.
  22. We need a better description of what the exported file should look like. If you're only exporting one field, and you want each row to have a constant prefix and suffix, you could define a calculation field along the lines of: "prefix text " & ExportedField & " suffix text" and export this field instead of the ExportedField field. There are more elegant solutions than that, but it will do.
  23. I have managed to reproduce the error by defining one of the fields to validate as Not Empty, Validate Always. The user privileges have nothing to do with this: I get the same error when logged in as admin. Apparently, the create new record event attempts to commit the newly created record and fails due to validation. This is hardly surprising, considering that the entire AppleScript dictionary for Filemaker was created before version 7 introduced the concept of committing records - and no major changes were made since then. I did manage to work around the problem by using the create new record with data event; however, this requires the fields you want to populate to be positioned above any other fields on the layout. I must say, I was quite surprised by this; I would expect it to populate the fields that are first in the tab order, or the fields that are furthest back on the Z axis. But apparently it just goes from top to bottom. If you're not able to modify your layout to suit, perhaps you could circumvent the entire issue by using go to (duplicate last record) and then set cell "CustomerName" of current record to "John Smith" etc. I am not sure what you mean by "the additional field that will automatically calculate the field based on the earlier set field". I am also puzzled by this: if you can create a script in the target file, then why do you need AppleScript to automate the process? You started by saying that "the import function of customer info has been blocked" - but you still haven't explained how exactly. If you have the privilege to create new records, then you also have the privilege to import them. Perhaps you just don't have access to the menu command, due to custom menus being installed.
  24. One could turn your argument around: suppose you are editing the script, and you want to make a change to the Set Field[] step; you would have to leave the script workspace and look for the calculation field in order to make the change there. I believe that if an action is scripted, it's good practice to place all the necessary logic within the script. And if you divide your scripts into logical parts and take care to comment each part, you should not have to look very hard in order to find what you're looking for.
  25. I don't think so - but all performance questions are best answered by performing an actual test. Sometimes the results can be surprising. Performance aside, if you're going to use a script to populate a stored field with the aggregate value, then you don't need the unstored calculation field - and there is no good reason for the script to depend on its existence. Note that there may be additional factors to consider here, for example record locking.