1 of 1 people found this helpful
Make sure the script is on a button within the portal row and make sure your "Go to Field" script step has the target field set for the portal's table container field and not the layout's container field. If you do that then you should be able to insert the picture on each individual portal row easily.
On filemaker go you may just want to leave the container field in it's initial state with no scripts attached. The default action for tapping on a container field in go is to ask if you want to choose from library, take photo, etc. Just tap on the container field, say take a photo and you should be good.
Is that what you're referring to or am I missing the mark?
Chris, thanks for your response. When I get back to the office this afternoon I will try to make those changes and see how that works. They will want to take several photo's in a row, so do I need them to click save and then add new record from the FMGO menu?
If you click new record from the fliemaker go menu it will create a new main record and not a new record in your portal.
If they want to take multiple photos in a row I think the way I would approach it would be to either:
a. Allow creation of records in the portal table automatically across the relationship in the relationship graph. That way they would always just scroll to the last portal row and tap the container field to simultaneously create the new related record and take the picture.
b. Create a script and attach it to a button above the portal that says:
- set variable ($ID; <id of the main record you're currently on>)
- goto layout (layout for the table that your portal is pointing to)
- new record
- set field (Pictures::<whatever foreign key field you use to link the picture records to the main record>; $ID)
- goto layout (original)
- goto object (<whatever object name you've given your portal>)
- goto portal row (last) <- this is assuming that you don't have sorting turned on for your portal
- goto field (Pictures::<the container field>; Select/perform)
A script like this, depending on how you have your file built, should allow the creation of the new sub record and the activation of the container picture action. I haven't tested this out so I can't say 100% that its full proof, but it's a good starting point. I tend to lean towards the scripting process instead of allowing creation of new records across the relationship because you can add in other things in the script to make it more of a comfortable process.
Let me know how it goes!
That worked! I had to create a layout where they selected the job so we could set the JobID. Then went to another layout to insert the Picture where the picture container field is located. They click a button (Take Picture)that adds a new record, goes to the Picture field and then they just have to tap on the picture field and it works great. When they see the picture in the Picture Container field on their IPhone, they can exit or take another picture. It is very quick and fairly easy for the user. Once the JobID is set, they can stay on that layout and take multiple pictures, always, adding a new record and setting focus on the picture field. Thanks so much for your help! Joanne
Awesome! I'm glad it worked out well.
I'll be building a similar structure soon for a community outreach bike shop I volunteer with. It's good to know what direction I'll be going in
Chris, another question? do you know how to lock the screen on the IPhone? When I am on one layout, the user has a drop down list to choose a job, one they select the job, they go to another layout with that jobid. But, the screen does not stay stationary as I want it to? Have you encountered this before?
1 of 1 people found this helpful
It's funny that you ask that. I just submitted a blog post for approval by our marketing director on that topic exactly. There are some special things you'd need to do to make it verbose, but in the most simple sense:
To achieve layout scroll lock, you have to make sure the objects on the layout are smaller than the maximum size constraints for the viewing style (landscape vs portrait). The size constraints are listed in filemaker's go tech brief here: https://fmdev.filemaker.com/docs/DOC-1145 on page 22.
So for example on the iphone:
- if you make sure that your layout objects don't extend passed 480 pixels width you'll have left to right layout lock in landscape view.
- If you make sure that your layout objects don't extend passed 385 pixels height (with the toolbar showing) or 429 pixel height (without the toolbar showing) you'll have up and down scroll locking in portrait view.
The problem with these measurements is that if you achieve lock in one viewing style, you'll loose it when you change to the other because the objects outside of the intersection of the two constrains will be passed the max size (an object at 300w by 300h will allow scroll lock in portrait view but will be passed the maximum height for landscape (which is 255))
To get scroll lock for both landscape and portrait viewing styles, you have to make sure that all of your layout are within the intersection of the landscape and portrait maximum size constraints. This 'common block' is
768 width by 673 height for ipad
320 sidth by 255 height for iphone
If all of your objects are within this size you will have scroll lock enabled for all sides. You can layer objects and the resize anchors to hide more objects behind the common block that pull out when you move your ios device. I cover that in detail in the blog post.
If you're using an object to make your background there's one other little gotcha. The background object can be 255 height, but the body needs to be 254 height. To do this, you can click on the body part tab and then adjust the height in the inspector to 254.
Let me know if that's not clear
I'll share the url for my blog post once it's up.
Great! I will check this out as well and incorporate it into my solution and let you know how it goes. Thanks so much! It is nice to have someone to talk to about these challenges.
No problem. I'm glad to help.
Yeah, this forum is a great place to search for and ask questions and it's full of users that could easily develop circles around me. I'm glad I can help where I'm able.
There are other little snags that may pop up as you build go layouts. If you have a question about a different topic I'd say start a new thread. Not everyone searches through the threads marked answered so starting a new thread for a new topic will probably get a faster answer. Also, if you want to message me directly just send me a message through my forum profile. I've been diving into go related developing recently and outlining concepts. I'm sure there are some other snags you'll run into that I can help with.
Let me know when your blog post is up.