Don't believe that there's anyway to do that.
What is the purpose of this? (Perhaps someone can suggest an alternative.)
The purpose of the text field is for writing screenplay scripts. These scripts have VERY specific formatting and margins for scene descriptions and dialog blocks. Although scene descriptions can extend from the left to right page margins, dilaog blocks MUST start at 2.5 inches from the left edge of the page and not extend more than 3.5 inches in length (i.e. have a right margin different than the rest of the scene description). In essence, block quotes with standard text.
I have a script that places the cursor in the appropriate left margin starting position for this dilaog block quote. The line object placed on top of the text field is supposed to be used as a guide for the right margin of the block quote style dialog block so tha user will not type to far to the right.
If anyone knows how to insert block quotes (left and right margins) within a text field, that would do it.
This sounds like a task best done by a work processor rather than a database.
You might try this:
Use MS word or another Word processor to create the document.
Insert a reference to this document in a container field in place of your current text field.
To view and/or edit the document, your user can double click this container field to open it in the Word Processor application that created it.
Thank you for your thoughts.
Yes, you are absolutely correct that a word processor would be better for the writing. The problem is with editing the script. The FM database is created to manage scenes. Each scene is a record. Therefore is becomes much easier to manage, manipulate, move, add, delete, and rewrite 125-150 specific scenes from within a database instead of a 120 page Word document. Trust me, I know.
I've created a separate table which simply concantenates all the scenes into one large text field (I know - I'm working FM doing this) that in turn is exported to a word processor for final pagination and printing.
Hmmm, an interesting situation. I'd take a look at MS Word's ability to organize subdocuments into a single publication via a master document. There might be some possibilities there.
If you want to set up an all filemaker solution, I'd consider breaking up your script into records stored in two tables: Scene description, and Dialog. If you're using FMP 10, you can create an editable summary report type layout where the Scene description field is located in a subsummary part and the related dialog records are listed below in the body. Adding a new dialog record would simply be a New Record operation. Adding a new Scene record would require adding a button to the subsummary part that is scripted to create the appropriate record in the Scene Description table and then a matching blank dialog record in the Dialog table so that the new scene description sub head will popup in the appropriate location in your script. This is not the simplest trick, but it can be done.
Since your dialog text is being entered in a different field from your scene description, you can size the field to be no wider than the maximum width you can allow for your dialog text.
Hello, last week you helped me in the forum regarding How do I "lock" an object in the stacking order? I didn't think I could, but figured it was worth a shot on the forum.
You asked me the purpose of it. I told you it was for a screenwriting database. Half of the text of a screenplay has indented (on both margins) dialog blocks - similar to block quotes. We discussed using a word processor for it, but the FM database is used to parse the large document into manageable scenes.
Well, after three days, and alot of coffee, I've created two scripts allowing blockquote capability. The first inserts indents and carriage returns on the fly while typing the orginal blockquote. During screenplay editing, a user can manually edit the block quote, select it and trigger a second script to reset the proper margins.
It wasn't easy. It takes two scripts, three global text fields for the manipulation, and about six or seven local and global variables. But it works - about 99% of the time (still one minor bug in it). Being the first version of this and the fact I'm no FM expert, (advanced-yes, expert-no) I'm happy. I'm sure someone with more expertise than me could trim down this procedure to run better.