1 of 1 people found this helpful
The question is i am having trouble copying and pasting the photos inside the container back and forth.
Why would you want to copy anything around, much less back and forth?
The idea of an Attachment** child table would be to have one central place to store media files – as many as desired for any one parent – and relate them to a parent (or several).
The credo of a relational database system is: store in one place, reference in many others.
The next question is: why do you have 30 different layouts? Are they all based all different tables, or just variations of the same layout? There is (at an educated guess) lots of potential for unification, which would allow you have fewer layouts and simply use a portal (which is the simplest way to add related records).
btw, even in the rare cases where you need to shuffle data around, you should avoid using the clipboard, as it a) requires the involved fields to be on the layout, and b) overwrites your user's (or your own) clipboard, which can lead to nasty surprises.
The idiomatic method in FM is to use the combination of Set Variable [ $someVar ; SourceTable::sourceField ] and Set Field [ TargetTable::targetField ; $someVar ]
Set Variable [ $media ; VO_forms::att1 ]
Go to Layout [ Attachments ( Attachments ) ]
Set Field [ Attachments::p1 : $media ]
Of course, now you'd have an Attachments record with contents, but not belonging anywhere … and would have stored that content twice.
1 of 1 people found this helpful
Don't use Copy and Paste. These are clumsy instruments that use the computer's clipboard and can easily go wrong for that reason. Instead use SetVariable and SetField, something like the following:
where you have Copy use—Set Variable [ $containerContent ; Value: VO_forms::att1 ]
where you have Paste use—Set Field [ Attachment;;p1 ; $containerContent ]
First of all I would like to thank you all for giving a providing a helping hand to my problem, which is extremely kind of you guys.
The script you provided for the moving containers helped me out of my mysteries so much and now have a better idea regarding the handling of containers.
Well regarding the question why i need so many layouts, its because the situation is that the company has 30+ different types of forms (all have different purposes) , and each individual form may need attachments (photos or pdf) to it for references. So therefore initially I thought it would be a nice idea to have a separate layout to handle the attaching mechanism and use it for all the different types of forms. (so in future when i need to make changes to the layout of the Attachment i don't have to go through every single form and have them changed).
But now i think sticking to the method of doing the attachment in the form itself would be so much easier. However I am not sure you would agree with that?? And would that be the case in the professional world??
From what you describe now, it seems to me that if you have a number of forms stored as PDFs, you would be better to store all your forms in a separate table and simply reference them as needed on each layout, instead of moving them from field to field as you originally proposed.
If you have a pdf form on a layout and need to fill in information on it, you can easily place relevant fields over the top of the form, to place the detail in the correct places on the form.
Sorry for the my bad descriptions, the forms are not pdf files, i actually created them on separate layouts looking like this
and i have tones of them. And I have each individual type of form stored on separate tables at the moment, and using different layouts for inputting data into each particular form. But the attaching procedure would be the same thought all the different types of forms.
Still not clear. Can you post a screenshot in layout mode?
the screenshot above is a layout mode ( every box is an edit box/combo box for a field) . I created the whole page using edit boxes and combo boxes
Now please show us the field list (Manage Database) of that table.
Sorry, but I lose interest at this point. Twenty two text fields named simply t1 – t22 speaks volumes. Give you fields meaningful names! In doing so your own structure and purpose may become clearer to yourself.
thanks so much for your help anyway, I appreciated it very much.
I will carry on and have my database improved first.
I suspected something, but not that