trev hatchett

i use filemaker every day, have just bought leopard, only to discover filemaker says... quote: We are very excited about the release of Leopard... blah blah blah FileMaker Pro 9 Advanced generally run on Leopard although there are two known issues: the Instant Web Publishing feature does not work each language version of FileMaker Pro 9 and FileMaker Pro 9 Advanced works only when the Mac OS System Preference "International Formats Region" is set to a specific region FileMaker Server 9 and FileMaker Server 9 Advanced currently do not deploy properly on Leopard. We are working on Leopard compatibility updates for FileMaker Server 9 and FileMaker Server 9 Advanced but do not have an estimated availability date at this time... We have not tested earlier (pre-FileMaker 9) versions of FileMaker software on Mac OS X Leopard and do not intend to release updates for earlier versions. wtf

Hi there It sounds to me as if you're still using copy and paste, which will take you away from the portal to the field into which you are pasting, as you guessed. This is another good reason for using the Set Field [ ; ] step. You should then be able to go the the next record in the portal without any problem. However, to make the Set Field [ ; ] step work in your loop, you probably need two things. First, you should consider making the field you are setting a global. In FMP 7, a global can be accessed without swapping layout or using relationships. That can be very handy. Second, you need to set up your calculation so that it accumulates information from each record in your portal. Assuming that you have a field "g_Temporary_Accumulator" which has global storage, change your calculation within your loop to be like this: ----------------------------------------------- Set Field [ g_Temporary_Accumulator ; g_Temporary_Accumulator & "¶" & Spots::SpotNumber & " " & Spots::Title & " " & Spots::Length & " " & Spots::Code ] ----------------------------------------------- Don't forget to set "g_Temporary_Accumulator" to empty before you start your loop, otherwise it could contain all the garbage from a previous run of your script. And after your loop has finished processing, you can put the contents of your "g_Temporary_Accumulator" field into your "Project::ScheduALL Notes" field like this ----------------------------------------------- Set Field [ Project::ScheduALL Notes ; g_Temporary_Accumulator ] Set Field [ g_Temporary_Accumulator ; "" ] ----------------------------------------------- and clear your gloabal as well, just to be on the safe side. See if that works for you. Trev[color:red][color:red]

sorry, i am having difficulty in attaching and uploading the files this is a second attempt trev found_set_in_second_file.zip

OK What you want to do is not trivial because you have to script two files. In fact, a script in one file calls another script in the other file. But don't worry both scripts are very simple. So you won't get lost, I have created two stripped-down files in FMP 5.5 called "Table_1" and "Table_2", each with a single field called "Month". There is also a relationship that joins the two files "Month" to "Month'. As it happens, both files are almost identical. So to distinguish them, the records in one file are coloured red, and those in the other are coloured blue. There are two layouts in each file. One layout shows a list of records in the current found set in that file. The other layout shows a single record, and includes a portal to display all of the records [ from the other file ] which are related to the current record on display. I have put two scripts in each file. The first script, called "Show me matching records in other file", uses the relationship used in the portal to find only the records you want, hiding all the others. To do this, you need to click the option "Show only related records" for the script step. This script then goes on to call another script, called "Show selected records in list", in the other file to display the records that have been found there, which is just what you want to do. This second script is simply used to go to the "List" layout used to view these found records. And in doing so, it also brings the window of the second file to the front. This is a very straightforward demonstration. And for that reason, there is no error checking, and the relationship does not take the Year into account. It is designed to show you only how a relationship works, and how it can be used to select the records that you want in a dynamic way. You can also see how to call a script in one file from a script in another file. It's quite simple, but powerful stuff. Hope this helps. T

OK! Sorry, kazza, I missed that. You don't actually need a portal. Without a portal, you have to create a script using the script step "Go To Related Record", making sure you check the "Show only related records" option to limit your found set. Your aim is to show only those records that match the month you want show. You actually use the same relationship that you would use for a portal in the "Go To Related Record" script step. The catch is that you also need make sure you start from the layout which shows the records from where the relationship starts. This will be the first step in your script. Then you need to go to the layout which shows the records from the table that satisfy your relationship, because that is where you can see the records you are looking for. The second step of your script not only finds the records you want, but it also takes you to the layout where you can see those records. You can even open a new window to display that layout. Your script would be something like this: Go to Layout [ "Table_1" ; ( Table_1 ) ] Go to Related Record [ Show only related records ; From table: "Table_2" ; Using Layout: "Table_2_List" ( Table_2 ) ; New window ] Play with these ideas and I'm sure you'll solve your difficulties. Good luck trev

hello skrying is is too simple to have just one table with both apple information and orange information, and just let your users see apple information on one layout and orange information on another ?? trev

hi hociman! First of all, I suggest that you use a single calculation which could be something like this: Set Field [ Project::ScheduALL Notes ; Spots::SpotNumber & " " & Spots::Title & " " & Spots::Length & " " & Spots::Code ] to set your "Project::ScheduALL Notes" field from the various fields in your "Spots" table in one hit. You should find that this is much easier for you to understand and maintain. Better still, it doesn't involve COPY and PASTE, which is not entirely secure, especially if some of the fields are not on the current layout. It also prevents screen flashing which makes for a better user experience. Your next problem is going through all of your "Spots" records. A typical method is using Go To Related Record in your script, making sure you check the "Show only related records" option to limit your found set. Then use Go Record/Request/Page [First] to initialise your loop, and loop by using Go Record/Request/Page [Next] and check the Exit after last option to ensure the loop finishes cleanly. Hope this solves some of your difficulties. Trev

hi kazza assuming that your relationship is sound and well-defined, it sounds very much as if you have a field in your portal which is actually unrelated to the portal, even though it may have a name which appears to be correct. the first thing you need to do is just check that the field name is something like "myPortal::myDateField" where "myPortal" is the name of the relationship that defines the portal. this type of mixed-up portal is something that i run into many times. if this is actually at the root of your existing problem and you can solve it by redefining the field correctly, you may quickly come up against another problem. dates can be tricky. for instance, you may find that even though you have used a month in the keys of your relationship, you could easily view all records for "March", say, in the current year, the previous year, the year before that, and so on. to solve this problem, you would need to match both month AND year if you want to be more precise in your relationship. this is not too difficult in FMP 7 and 8, where you can have multiple keys, so that you can match the current year and current month in a single relationship. hope this helps trev

i suggest you use a SINGLE GLOBAL [ or pass a script parameter ] to hold the information from ALL of the fields of your original record. using a global means you don't need additional relationships. and a single variable means you don't have to go back and forth between the two records. this is a common filemaker technique. all you need to do is create a calculation to put each field into the global filed with a return character "¶" between each field. [ don't forget to add one final return character at the end of the final string as well ]. this technique provides a long 'list' of information with one entry for each field, like paragraphs in regular text. you can access any item on this list in any order with the function MiddleValues ( text ; startingValue ; numberOfValues ) which is new in FMP 7. for instance, the syntax for accessing the third item in the list is MiddleValues ( gMyGlobal ; 3 ; 1 ). hope this puts you on the right track trev

maybe i'm missing something, but when you insert a picture [ from disk ] into a container field, i always believed that you have the option to store only a reference to the file. [ this is at the bottom left of the Insert > Picture... dialog ] in other words, the file remains on disk, and the database contains only a path to that image, and only resolves that into the image on a layout whenever it is required to do so. so your database shouldn't get too big, but it may appear to be slow because it is dragging bits off your drive, which could be getting more and more fragmented. i have just checked this out. i put a 28 Mb image - by reference - in a single container field in a new database which now has a file size of 12 Kb. filemaker, however, takes its time to render this large file on a layout. as to converting a photograph [bimap] into a vector [set of instructions], this is possible with applications such as adobe illustrator, but in my experience the result neither looks like a photograph nor a decent illustration. i wouldn't recommend it. the amount of data in a single photograph has given rise to a vast array of image manipulation applications and a plethora of file formats. how do you describe an image in words ? [ or numbers for that matter ? ]. each format has its benefits and disadvantages, so i would stick to simple widely used cross-platform standards such as JPEG. when i do something like this, i often have two sources of images, identical except for size, in separate folders. one set of images is small for viewing on screen quickly and is the set of images which is referenced by filemaker. the other set is composed of the original full-size images which i use for publishing at high resolution. however, i found it tricky is to get the path to the image from the database. finally, by experimentation, i discovered that i can do it if i make a text field equal, by calculation, to a container field. amazingly it works! and it returns a list of three items, the image size, the image name and the image path. i can then use the image path in a calculation [ changing the final folder name ] to access the high resolution image. cool