Jump to content

rrr

Members
  • Posts

    21
  • Joined

  • Last visited

rrr's Achievements

Apprentice

Apprentice (3/14)

  • Conversation Starter
  • First Post
  • Collaborator
  • Week One Done
  • One Month Later

Recent Badges

0

Reputation

  1. Thanks so much, MickMc. This is exactly what I was looking for. I was beginning to consider approaching this problem with AppleScript, and your contribution does exactly what I need. Very helpful.
  2. Thanks, although I believe Iceberg is used to create an installer package, and this is not really what I am trying to do. Rather, I am simply trying to wrap the solution file (.usr) and Extensions folder into the runtime's application bundle, so that the whole shebang can be treated by the user as a single, double-clickable entity.
  3. Yeah, ideally, I would be able to embed the .usr file(s) and the Extensions folder right inside of the existing runtime app bundle, but I don't know how to get the runtime app bundle to look for those resources inside of itself, instead of its parent directory. It may not be possible to go that route, but surely there is a decent way to bundle all of those resources together into a single double-clickable entity. Rusty
  4. Anyone have any tips or methods in regards to packing an FMP runtime solution into a single Mac OS X app bundle (for the purposes of easy launching, distribution, etc?) ie: packing the .usr solution file, the runtime application the Extensions folder, and even the FMP Acknowledgements pdf, I guess, into a single double-clickable bundle? Is this possible? Unadvisable? Any insight? Thanks, rrr
  5. I am seeing the exact same issue on a client's file which contains over 20000 records. All of the records appear to be in the file, but all fields are blank. Performing a find operation does seem to produce a found set with the expected number of records, but again, all resulting records in the found set have all blank fields. Anyone have any further information on this, or recovery suggestions? Thanks, rrr
  6. Well, that's extremely lame, in my opinion. At the very least, "absolute" files references should be able to abstract the Volume name in the same way a rooted Unix path does: file:/Users/Shared/myFile.txt That way, we could shoot for directories we knew would exist on every volume but not necessarily care that the volume names might differ from user to user. Or Filemaker could go a long way to help us by improving the Send Mail script step so that the attachment file path can be dynamically generated from a field or calculation. As it stands, I will probably have to forget about using the Send Mail script step altogether and do everything with AppleScript. This is highly unfortunate though, because now I have to worry about coding for different e-mail clients, and somehow trapping for the users' chosen e-mail client. Boo. rrr
  7. Let's back up a minute, then, and revisit one of my original questions: If I use a relative file path reference, (ie: file:myFile.pdf), then what is the "root" of that relative path? The local volume's root? The server directory in which the hosted db files reside in the server? Something else? I know that in a non-hosted solution, the root is the same directory in which the .fm7 db file resides, but how about in a hosted situation? rrr
  8. I am working on a hosted/multiuser FMP7 solution whose clients will be Mac OS X only. I would like to use the Send Mail script step for creation of e-mail messages with attachments. For the purposes of this question, let's currently assume that the file I wish to attach will be on the user's Desktop, and I will know the exact filename of the file to be attached, and that the filename will always be the same in all cases in which the script runs. Since the Send Mail script step requires a hardcoded file reference when using "Attach File", can anyone give me any insight into how best to specify this file reference? Remember that (1) my solution will be a hosted one, so the actual db files will be residing on a server, (2) the file to be attached will be on the local client's Desktop, (3) the solution is a multi-user one so I cannot depend on the volume name to be the same on every client. If I use a relative file path reference, (ie: file:myFile.pdf), then what is the "root" of that relative path? The local volume's root? The server directory in which the hosted db files reside in the server? Something else? Any insight anyone could provide to get me on the right track on this one would be great. Of course, my followup questions will be about cases in which the filename of the file to be attached needs to be dynamic, but that is for a subsequent post... rrr
  9. I am not the Original Poster of this thread. If you look back to the earliest post and the mention of "Filemaker Developer", you will see that the post is from another author. I will do some testing on another machine to determine if I am running up against quirky version issues or if something else is at play, and report back. Thanks rrr
  10. Yes, thanks. I do understand that the 'of table "Test"' needs to preceed the text. That was a misprint in my posting. However, as I described in my following post, I am still unable to reference a "table" at all. If you have any comments on my post #150540, I'd be very interested. (Maybe it's a dumb oversight on my part that I'm overlooking, but I can't think what that would possibly be.) rrr
  11. Yeah, try as I might, I just can't refer to tables with AppleScript. The following script works as expected: tell application "FileMaker Pro" tell document "test" -- 'database' also works fine here in place of 'document' set the_result to the name of every layout end tell end tell But this script won't compile: tell application "FileMaker Pro" tell document "test" -- 'database' also fails here in place of 'document' set the_result to the name of every table end tell end tell Error message is: Expected class name but found application constant or consideration. Help! rrr
  12. Again, thanks, Fenton. I agree. A globals table for globals that are used for value passing is a great idea. In testing your example script, I am back to my problem eariler in this thread. I simply can't get it to compile with the "table" qualifier in it. Here is the code I adapted from your example: tell application "FileMaker Pro" tell database "test" set cell "gText" of record 1 to "example data from applescript" of table "test" end tell end tell When I try to paste this into FMP ScriptMaker's Perform AppleScript step, or try to compile this code in ScriptEditor, I get the following message: Expected end of line but found
  13. Fenton: Thanks. This provides some good insight into understanding nuances of AppleScripting in FMP7 vs FMP6. Let me ask you this... The majority (99%) of integration I do in FMP-based AppleScript (passing data in and out of FMP "cells"), is done on global fields in FMP, so the concept of "current record" is not especially important to me, as long as I am able to get/put data into a specific global field in the correct table occurence. Based on that knowledge, what do you think would be the cleanest, most elegant (and generic and portable) way to write references to these global "cells" in AppleScript? Specifying a layout name on which these fields reside would be OK, I guess, but it would be ideal if I didn't have to worry about whether or not the file's window was frontmost, or about having to update layout names in AppleScripts when porting AppleScript code to similar files with different layout names. Opinion? rrr
  14. I find that this approach (specifying table name in script) does not work, but specifiying a layout containing the field does work. It would probably be cleaner code to specify a table rather than layout, so I would be interested into insight why h2o.be's approach doesn't seem to work for me. Does it work for others? To be clear, I find that: set theone to cell "ONE" of record ID theID of table "table name" ...won't even compile, but... set theone to cell "ONE" of record ID theID of layout "layout name" ...compiles and works fine. rrr
  15. I am looking for a general technique here to apply in various ways in various situations, so please just consider these hypothetical examples at face value for discussion purposes... Consider a number calc field called "Total" that evaluates to "4". In designing a layout, I can use number formatting to make this field display as "4.00". However, if I copy and paste the contents of this field, only "4" (not "4.00") winds up on the clipboard, or if try to move the contents of "Total" to a text field using a script like: [set Field: TextField -> GetAsText(Total) & " hours"] ...the resulting data in TextField is "4 hours", not "4.00 hours". This makes sense as to why FMP behaves like this, but I am wondering if there is an easy way to preserve custom number (and date) formatting when moving the contents of number (and date) fields into text fields. rrr
×
×
  • Create New...

Important Information

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