Can anyone tell me how to fine-adjust the line spacing in a multi-line static text object?

I want to put (dynamically) a multi-line static text beside an edit table to label the edit table rows.

However, the line spacing in the edit table is greater than in the static text due to the grid (whether set visible or not). The lines therefore do not match between the static text and edit table rows.

Is there any way of fine-adjusting the line spacing in a static text object? Font size is too coarse. Leading is part of the font and therefore cannot be set by Set_Property FONT.

Otherwise, I could use a column in the edit table for the labels - but it gets cleared whenever the screen is cleared (even if not associated with a field) - or is there a way to protect a single edit table col from being cleared?

Or else, I could put a separate adjacent edit table just for labels - if that could be protected from being cleared.

I presently do this by creating a static text object per edit table row in the correct position. This works but seems a sub-optimal technique

Any ideas gratefully received.

Richard,

If the content is really static you might use a bitmap.

- Oystein -

Richard,

Btw - what is it you think is sub-optimal with your present method?

Is it that you get more controls than necessary? Perhaps you're approaching the 114 limit or depleting resources? Well, that's a valid reason.

Or is it more manual work than necessary? This can be overcome by creating and/or placing the statics programmatically. The latter (nudging controls into place programmatically) is what I do in some forms of mine. In these forms I have edit tables paired with arrays of radio groups. Each edit table line is flanked to the right with its own horizontal radio group. I have named the radio groups systematically RADIO_1, RADIO_2, etc, with RADIO_i corresponding to line i of the edit table. But perhaps this is what you do already with your statics.

- Oystein -

Richard,

Couldn't shake your problem. Have been through too many similar ones myself. Sometimes it's like trying to build round objects from Lego bricks.

Well, my final suggestion is to use an RTF edit box (unless you need 8-bit characters in your text, that is). I believe with RTF you can do the adjustments you need.

Make a borderless, scrollbarless, suitably coloured edit box, so it looks like a static. Tick the RTF property. Set its contents programmatically with a suitable RTF encoded text.

Use Word to create the RTF encoded text. Edit and format the texts with the layout you need and save as RTF. Read the file from your program and set programmatically.

- Oystein -

Oystein

Many thanks for all that thought evolution!

I think I'll stick with my present method. I just thought there had to be a way of getting n lines of text positioned in a single object by adjusting the line spacing rather than generating n carefully positioned text objects!

You may just be interested in the context which I've developed in Arev quite a few years ago & more recently migrated/developed to OI.

I have a generic type of a field (or set of amv fields) - e.g. various roles related to a data record as keys in an address book file - in my case, conceptually, a property (piece of "real estate") has a landlord, tenant, guarantor, parish priest, etc. - all handled as keys in an address book file. I.e. a multivalue field in the property record containing address book keys. Lovely, the first is the landlord, etc. - but all my users are different (and change their minds!).

Hence I have a master code record (actually a popup definition for various good reasons). The data record has matching amv fields : one is a code field plus one or more data fields.

When the screen loads it fires user-defined CREATE events to all edit tables. The special edit tables have a CREATE event which creates the text labels beside the edit table, sizes the edit table and stores the master code list as an object property.

When the record has been read, a READ event is fired to compare its code field with the master code list. If necessary the table rows are adjusted to match and the revised code list stored in the data record.

Thus I or my users can set up these generic fields of many types and their spec can be tailored on the fly via editing the (popup) control record.

Reporting is fun! An OCONV simply looks up the mv position in each record and extracts the appropriate mv from the required data field(s). The choice of data item (i.e. code value) can also be done on-the-fly during report specification (using the popup!).

Hope I've made this clear. If not, ask!

Many thanks again for sharing your thoughts!

Richard

Richard,

Neat scheme. I can clearly see the advantages. I don't believe it will fit all data, though.

I don't want to be a pain, but the RTF suggestion might be worth a try. The variable part of the RTF data would be something like the following, and quite easy to generate:

{\fs16 landlord \par tenant \par guarantor \par parish priest \par }

(\fs16=8 points).

(Now I don't know why I go on about RTF edit boxes because I hate them with a vengeance.)

- Oystein -

View this thread on the forum...