Like I said, that's the first thing that came to mind. There may be something else that someone knows about that would work better.

The first thing that comes to mind has quite a bit of overhead:
Set 'Signal All Changes' on the field and create logic to do the character counting yourself, adding / removing line breaks as appropriate. This also means you'll have to process backspaces, adjust for cursor inserts / deletes / corrections, etc.
Not what you're looking for, I'm sure, but it's an option.

Yes, it is. I use it as needed.
Try taking the spaces out from between your options in your second example.
Also, if you want hotkeys, precede the hotkey character in the option with an ampersand.

I had a small problem loading data out of a variable into discrete variables with READ DATA. Based on the current documentation, I should be able to:

READ DATA FROM var$,sep=Sep$,err=Bad_Data to iol=My_IOL$

Whenever I type that in, though, I get a syntax error. I was finally able to get it to enter and run properly with:

READ DATA FROM var$,sep=Sep$ to iol=My_IOL$,err=Bad_Data

Could someone update the documentation to present this properly, please?

Thank you!!

Yes, I understand that. But what I'm looking at is the snip you included. Immediately before the RGB, there's the code for the COLOR, and before that, there's a comma. Where's that coming from...?

I've attached my process. I also noticed in your sample that there's a "0," at the beginning of your statement. It acts like there's a quote immediately after the list_box ID, putting the rest of the line in as the contents. Also, confirming that your field separator has been reset to $01$ in the definition (from the standard SEP).

What type of list_box are you using? I tried with a Report View and it works fine with a variety of colors, using both RGB: and #xxxxxx formats.

In the online manual, the entry for the BUTTON directive includes the option for a FNT= specification, with details in the 'FONT' mnemonic. For things to work, it seems you also have to include OPT="A" and use the '4D' mnemonic. E.g.:

print '4D',
B_ID=100
button B_ID,@(10,5,10,3)="Click Here",opt="A",fnt=",,R"
While you can specify the justification when creating the button, it seems you can't change it, though you can retrieve and change other font attributes:

F$=B_ID'Font$
B_ID'Font$="Courier New,-18,B"
Overall, to left-justify the text, all you need to include when manually creating a button is to include the OPT="A". Not sure what you can do with old NOMADS...

In NOMADS, on the Font/Clr tab, you can select whether the text is Left/Center/Right justified.

It's been a LONG time since I worked in text-only (typically use WindX). Is it necessary that it be a child window?

Actually, I (and NOMADS) use Fonted Text for the prompts for the different fields. Works fine there.

The main reason it doesn't seem to work is that it isn't really an addressable control. It's text that is on the text plane, and the *wingrp routine deals with SHOW/HIDE separately.

I find that using a multi_line is much more effective, as I can drop whatever text I want into it and it's done.

The When-Selected logic changes a bit when you move from double-click to multiple-selection. The _EOM$ values to check become $09$ for Tab and $0D$ for Enter. You may also consider including $00$ if someone simply clicks on another control on the panel (be sure to set 'Signal on Exit').

At that point, the LB$ value contains all of the selected entries, separated by the last character of LB$ (probably $00$). For efficiency, you may want to include the entry/row number in the line.

For example, if your list_box looks like:

001	| Item A	| Description A
002	| Item Q	| Description Q
003	| Item J	| Description J

and lines 001 and 003 are selected, when leaving the list_box, LB$ would contain:

"001"+sep+"Item A"+sep+"Description A"+$00$+"003"+sep+"Item J"+sep+"Description J"+$00$

(Note: the "sep" may be redefined when defining the list_box by setting the 'Column Separator' on the format definition panel, and can be retrieved by Sep$=LB.Ctl'Sep$)

The row separator can be identified from:

EOL$=mid(LB$,-1)

The number of rows would then be:

N_Rows=pos(EOL$=LB$,1,0)

If you want the row separators to be "!" instead of the EOL, then:

LB$=sub(LB$,EOL$,"!")

And your selection routine becomes more like:

Line_Selected:
if pos(_EOM$=$00090D$)=0 then return
EOL$=mid(LB$,-1) ! get row separator character
N_Rows=pos(EOL$=LB$,1,0) ! determine # of rows selected (if needed)
LB$=sub(LB$,EOL$,"!") ! optional to replace the row separator
... ! any other row-based logic to apply
Arg_3$=LB$ ! to return to calling program
return
I've gone through other gyrations in the past to make the lists look and work spiffy. While I generally use Report Views instead of Formatted lists, the process is the same.

Good luck!

Normally, I would simply set it up with the 'Multiple Selections' attribute set. That way, the user can use the standard Windows selections (click, ctrl-click, shift-click) to highlight as many as they want. Then when they tab out of the list, it triggers the selection logic and you can retrieve all of the entries at once.

At the beginning of your selection logic routine, check _EOM$ for $02$ to check for a double-click, and/or $0D$ for an ENTER key. This will filter out the single-click selections. Eg:
if pos(_EOM$=$020D$)=0 then return ! Only accept double-clicks and ENTERs