I have posted this question in this forum as I think I had it in the wrong forum at first and it seeems my problem is with relationships.

I am creating a series of text templates. A list with the names of these templates should show in a portal and when one is highlighted (selected) it will place the template into a global text field. I also want the user to be able to create their own text templates to be added to this list and to be able to edit the existing templates.

Here's what I think I need so far:

Table 1 - Templates

Field: Template_ID Indexed, Autoenter, serial

Field: Template_Name Text

Field: Template_Text The text of the template

Table 2 - Main

Field: Cust_ID Indexed, autoenter, serial

Field: g_Text_Box global text box to display template

Field: g_Template_ID

I think I should create a portal to show the template names and then a button to setfield Templates;Template_Text; Main;g_Text_Box and Templates_Template_ID;Main;g_Template_ID

but I'm not sure how to relate the tables and what other fields I need in the Main Table.

I have posted this question in this forum as I think I had it in the wrong forum at first and it seeems my problem is with relationships.

I am creating a series of text templates. A list with the names of these templates should show in a portal and when one is highlighted (selected) it will place the template into a global text field. I also want the user to be able to create their own text templates to be added to this list and to be able to edit the existing templates.

Here's what I think I need so far:

Table 1 - Templates

Field: Template_ID Indexed, Autoenter, serial

Field: Template_Name Text

Field: Template_Text The text of the template

Table 2 - Main

Field: Cust_ID Indexed, autoenter, serial

Field: g_Text_Box global text box to display template

Field: g_Template_ID

I think I should create a portal to show the template names and then a button to setfield Templates;Template_Text; Main;g_Text_Box and Templates_Template_ID;Main;g_Template_ID

but I'm not sure how to relate the tables and what other fields I need in the Main Table.

I have posted this question in this forum as I think I had it in the wrong forum at first and it seeems my problem is with relationships.

I am creating a series of text templates. A list with the names of these templates should show in a portal and when one is highlighted (selected) it will place the template into a global text field. I also want the user to be able to create their own text templates to be added to this list and to be able to edit the existing templates.

Here's what I think I need so far:

Table 1 - Templates

Field: Template_ID Indexed, Autoenter, serial

Field: Template_Name Text

Field: Template_Text The text of the template

Table 2 - Main

Field: Cust_ID Indexed, autoenter, serial

Field: g_Text_Box global text box to display template

Field: g_Template_ID

I think I should create a portal to show the template names and then a button to setfield Templates;Template_Text; Main;g_Text_Box and Templates_Template_ID;Main;g_Template_ID

but I'm not sure how to relate the tables and what other fields I need in the Main Table.

Ok, I have most of the puzzle solved but one small piece eludes me. I've attached a file to show you where I'm at. Any help is appreciated.

Ok, I have most of the puzzle solved but one small piece eludes me. I've attached a file to show you where I'm at. Any help is appreciated.

Ok, I have most of the puzzle solved but one small piece eludes me. I've attached a file to show you where I'm at. Any help is appreciated.

bteatesttemplates.zip

It's a little hard to tell exactly what you want to do. I did more or less as I would do it. You have an ID for a Template, so that is what I'm using for the match. It doesn't really matter, but an ID is better in case you're storing a log history by ID. Names can change, but the ID remains the same.

The actual text, after the choice, can be just the related field, based on the ID choice in a global in the original Template table (you labelled it as _gID, but it was not global, hard to say whether you want it global, the same for all records or not, one mail, or a bulk mail).

This means you looking at the original text in the Template table, and all editing will change it permanently.

It is also possible to use a global field in the Main table to hold the text. I did a second Main layout like that. You can "look up" the original text from the Template table. This means it's now independent, so editing will make no difference to the original. Of course it also means that, if you do, the changes will not be stored anywhere, unless you build a history mechanism to store the whole thing.

In this case I left it still a global field, so it is the same for all records, and would work for bulk mailing. It is also Unstored, which cuts down on size.

There are several different ways to set up a "letter," depending on such things as:

Is it for bulk mail?

Is it going to be edited right then?

Do you want to store the changes?

(The whole text; there is no need to store the whole text of unedited bulk mailing; storing large amount of duplicate data for no real reason. You can just store the ID. But if it is an edited individual mail, you would probably want to store the whole thing.)

Until you know all the factors you can't say what the exactly method should be. They all look more or less the same to the user, as they should. But you kind of need to know what they want, and which is which.

It's a little hard to tell exactly what you want to do. I did more or less as I would do it. You have an ID for a Template, so that is what I'm using for the match. It doesn't really matter, but an ID is better in case you're storing a log history by ID. Names can change, but the ID remains the same.

The actual text, after the choice, can be just the related field, based on the ID choice in a global in the original Template table (you labelled it as _gID, but it was not global, hard to say whether you want it global, the same for all records or not, one mail, or a bulk mail).

This means you looking at the original text in the Template table, and all editing will change it permanently.

It is also possible to use a global field in the Main table to hold the text. I did a second Main layout like that. You can "look up" the original text from the Template table. This means it's now independent, so editing will make no difference to the original. Of course it also means that, if you do, the changes will not be stored anywhere, unless you build a history mechanism to store the whole thing.

In this case I left it still a global field, so it is the same for all records, and would work for bulk mailing. It is also Unstored, which cuts down on size.

There are several different ways to set up a "letter," depending on such things as:

Is it for bulk mail?

Is it going to be edited right then?

Do you want to store the changes?

(The whole text; there is no need to store the whole text of unedited bulk mailing; storing large amount of duplicate data for no real reason. You can just store the ID. But if it is an edited individual mail, you would probably want to store the whole thing.)

Until you know all the factors you can't say what the exactly method should be. They all look more or less the same to the user, as they should. But you kind of need to know what they want, and which is which.

It's a little hard to tell exactly what you want to do. I did more or less as I would do it. You have an ID for a Template, so that is what I'm using for the match. It doesn't really matter, but an ID is better in case you're storing a log history by ID. Names can change, but the ID remains the same.

The actual text, after the choice, can be just the related field, based on the ID choice in a global in the original Template table (you labelled it as _gID, but it was not global, hard to say whether you want it global, the same for all records or not, one mail, or a bulk mail).

This means you looking at the original text in the Template table, and all editing will change it permanently.

It is also possible to use a global field in the Main table to hold the text. I did a second Main layout like that. You can "look up" the original text from the Template table. This means it's now independent, so editing will make no difference to the original. Of course it also means that, if you do, the changes will not be stored anywhere, unless you build a history mechanism to store the whole thing.

In this case I left it still a global field, so it is the same for all records, and would work for bulk mailing. It is also Unstored, which cuts down on size.

There are several different ways to set up a "letter," depending on such things as:

Is it for bulk mail?

Is it going to be edited right then?

Do you want to store the changes?

(The whole text; there is no need to store the whole text of unedited bulk mailing; storing large amount of duplicate data for no real reason. You can just store the ID. But if it is an edited individual mail, you would probably want to store the whole thing.)

Until you know all the factors you can't say what the exactly method should be. They all look more or less the same to the user, as they should. But you kind of need to know what they want, and which is which.

testtemplates2.zip

Once again you have helped me understand the workings of FMP7. I thank you. I will be using separate "edit" and "add" template buttons so the global is the better way to go.

Thanks again...until next time!

Once again you have helped me understand the workings of FMP7. I thank you. I will be using separate "edit" and "add" template buttons so the global is the better way to go.

Thanks again...until next time!

Once again you have helped me understand the workings of FMP7. I thank you. I will be using separate "edit" and "add" template buttons so the global is the better way to go.

Thanks again...until next time!

Hi Frink1234, and welcome to the Forum.

I have posted this question in this forum as I think I had it in the wrong forum at first and it seeems my problem is with relationships.

Yes, it can be confusing where to post a question. As you have discovered, there are questions that seem to fit in multiple areas. We only ask that you try to Match the Sprit of your question to the FileMaker Feature of Function that you think is involved. Not to worry if you miss it though, no one will get mad at you, and you should still receive help. Never [color:"red"]Double Post, because for that we do get angry. Just think of this list as One List (which it is), with many areas of interest to help try and keep things organized.

Also, keep in mind that a question can, and often does, change direction during the course of its life. In fact, it often ends being solve with a totally different Function or Feature then the poster original thought. However, this doesn't require the question to be moved because of it. If you feel like you missed the right area, and feel it might attract a better answer in a different area, just notify the Moderator of the area you have posted it in by Private Message for assistance.

HTH

Lee

Hi Frink1234, and welcome to the Forum.

I have posted this question in this forum as I think I had it in the wrong forum at first and it seeems my problem is with relationships.

Yes, it can be confusing where to post a question. As you have discovered, there are questions that seem to fit in multiple areas. We only ask that you try to Match the Sprit of your question to the FileMaker Feature of Function that you think is involved. Not to worry if you miss it though, no one will get mad at you, and you should still receive help. Never [color:"red"]Double Post, because for that we do get angry. Just think of this list as One List (which it is), with many areas of interest to help try and keep things organized.

Also, keep in mind that a question can, and often does, change direction during the course of its life. In fact, it often ends being solve with a totally different Function or Feature then the poster original thought. However, this doesn't require the question to be moved because of it. If you feel like you missed the right area, and feel it might attract a better answer in a different area, just notify the Moderator of the area you have posted it in by Private Message for assistance.

HTH

Lee

Hi Frink1234, and welcome to the Forum.

I have posted this question in this forum as I think I had it in the wrong forum at first and it seeems my problem is with relationships.

Yes, it can be confusing where to post a question. As you have discovered, there are questions that seem to fit in multiple areas. We only ask that you try to Match the Sprit of your question to the FileMaker Feature of Function that you think is involved. Not to worry if you miss it though, no one will get mad at you, and you should still receive help. Never [color:"red"]Double Post, because for that we do get angry. Just think of this list as One List (which it is), with many areas of interest to help try and keep things organized.

Also, keep in mind that a question can, and often does, change direction during the course of its life. In fact, it often ends being solve with a totally different Function or Feature then the poster original thought. However, this doesn't require the question to be moved because of it. If you feel like you missed the right area, and feel it might attract a better answer in a different area, just notify the Moderator of the area you have posted it in by Private Message for assistance.

HTH

Lee

Thanks Lee. You're so right how a question (and answer) tends to meander all over the place. I'll make sure to PM for assistance if I run into this type of situation again.

- Frink

Thanks Lee. You're so right how a question (and answer) tends to meander all over the place. I'll make sure to PM for assistance if I run into this type of situation again.

- Frink

Thanks Lee. You're so right how a question (and answer) tends to meander all over the place. I'll make sure to PM for assistance if I run into this type of situation again.

- Frink