Dialog box with a variable number of controls

[dboggs]

I am writing a Fortran Console application that uses a single dialog box. The box contains a variable number of checkbox controls; i.e. the program must add and remove checkboxes. Not having much experience with this--and not even sure it is possible--I am contemplating a brute force approach where my program directly edits the resource.rc file. An excerpt from this file (an example dialog that contains two checkbox controls) is

IDD_DIALOG1 DIALOG DISCARDABLE 0, 0, 362, 230
STYLE DS_MODALFRAME ! WS_POPUP ! WS_CAPTION ! WS_SYSMENU
CAPTION "Keyword list"
FONT 8, "Ms Sans Serif"
BEGIN
    CONTROL         "Check1",IDC_CHECK1,"Button",BS_AUTOCHECKBOX |
                    WS_TABSTOP,15,30,68,13
    CONTROL         "Check2",IDC_CHECK2,"Button",BS_AUTOCHECKBOX |
                    WS_TABSTOP,15,42,64,12
END

So, it appears that all my program has to do is manipulate the text in this Begin-End block, adding and removing lines. Right?

What worries me is that there is also an associated Resource.fd include file, and a Resource.h header file, which also contain similar information. Does my program also need to modify these? This would become much more burdensome. And, there is a statement in the "Digital Visual Fortran Programmer's Guide" (the only reference I have with info on this topic) warning that this may not work.

Or maybe there is a better way?

[dboggs]

UPDATE:

By trial and error using a manual text editor I find that indeed I can add a new checkbox tool, with two conditions:

1. The added text is case-sensitive--don't try lowercase where the example shows caps.

2. All three files--Resource.rc, Resource.fd, Resource.h--have to be edited for consistencey.

A bit awkward, but certainly doable.

[andrew_4619]

It seems to me that all the things you are doing are pre-build events which means you must be making a number of console programs which are very similar with different numbers of controls. Maybe I misunderstand.

USE ifwin, only: ShowWindow, GetDlgItem, SW_SHOW, SW_HIDE, bool, handle
....
integer(handle) :: hDlg
integer(bool) :: bret
....

! make visible/active
! hdlg is the handle of the dialog
! ID is the INDEX of the control

bret = ShowWindow (GetDlgItem(hDlg, ID) , SW_SHOW )

!make invisible/inactive
bret = ShowWindow (GetDlgItem(hDlg, ID) , SW_HIDE )

! You can add all the controls and make them active/visible or not 
! dynamically at run time if that is a better solution.

[dboggs]

There is only one console program, and it handles only one dialog box. The box is basically a list of active keywords--kind of like a dictionary, but smaller. Each word is to be displayed as a checkbox. With use, people will add to (and possibly remove) the keywords. The program needs the ability to modify the dialog box each time this happens. So, all the controls will be added dynamically (with a dynamically determined text property) at run time. That's the whole problem!

I may have confused you in #2 by describing actions with a text editor. I was merely mimicking what the program would do.

[IanH]

Are you considering a program that dynamically modifies the resources attached to its own executable image (.exe file)?  The resources of an executable are practically fixed at the time the executable is linked.

As app4619 suggests, you can create child controls of a dialog on-the-fly (after all, that is what the operating system does for you with the data that it loads from your executable's resources).  After creating the window for the dialog (perhaps a "blank" template loaded from the resources) you can use the CreateWindow api to add new child windows.

(That said, a variable list of individual check controls may not be the best from the point of view of user interface design.  If you are selecting options in a list, then something like a multiple selection list box is a more natural fit to the existing set of Windows controls.  Much easier for you to code up too...)

[Paul_Curtis]

Here's another strategic suggestion, which will get you what you want.  Use the resource editor to create your dialog box with the maximum number of controls possibly needed.  Then,when the dialog loads, send the controls messages to toggle their visibility, based on your dynamic circumstances.  Controls which are invisible will of course never send back any user messages.

And, while you're at it, each control (following the post above about "dictionaries") can consist of a checkbox with null text, accompanied by an adjacent static text block of appropriate dimension, so you can both enable each checkbox and its accompanying text, and also load the text strings dynamically.  This is much easier/safer/more reliable than mucking with the internals of the dialog descriptors.

[andrew_4619]

Paul's comments in #6  as basically what I am saying in # 3 but Ian's last comment may be the way to go.

In a list box you can add or delete items in the list programmatically at run time  and the user can click pick/unpick (and highlight) a current selection of items . The software can also get/set a multi-selection. If this list gets long the vertical scroll can be set up appear... There is no practical limit to the number of items in the list. I use this all the time as so many things can be achieved in a simple bit of code.

You will need to use one or two API functions on top of Quickwin but it is not difficult and examples can be posted.

[dboggs]

Thanks for everyone's responses. All suggestions are useful and may save me a lot of time!

I now realize I cannot alter the number of checkbox controls at runtime--I should have known.

A multi-select list box may do the job and would certainly be the easiest to program. I had initially rejected it because SOME of the items in the list will have already been selected during a prior run, and I wanted the current user to see that. With multiple checkboxes the current user would see a checkbox next to every list item, some of them would be checked, and the user easily uncheck those and check new ones as desired. Maybe I could accomplish this in a list box by providing an asterisk (for example) on every item that had already been selected. But manipulating this list so that the control handles selection as well as de-selection now gets a little involved.

The other suggested approach, to pre-build the dialog with "just enough" check controls, would also work. I don't know how to make check controls invisible, but I can make them gray with blank text and that would ALMOST accomplish the same thing.

I will continue to investigate. It's very good to know that I am not careening down a stupid path out of ignorance!

[andrew_4619]

dboggs wrote:

. Maybe I could accomplish this in a list box by providing an asterisk (for example) on every item that had already been selected. But manipulating this list so that the control handles selection as well as de-selection now gets a little involved.

The list items that are selected are highlighted. Clicking list items toggles the highlighting on or off. If you can set the status in your program.

dboggs wrote:

 I don't know how to make check controls invisible, but I can make them gray with blank text and that would ALMOST accomplish the same thing.

The snippets I posted earlier makes any control visible or invisible

[dboggs]

"The list items that are selected are highlighted. Clicking list items toggles the highlighting on or off. If you can set the status in your program."

Yes of course I know that! What you missed is that I need a way of showing that an item was PREVIOUSLY checked; i.e. a property of the item that was stored from a previous run. That's why I consider appending an asterisk character to the text of such items.

[jimdempseyatthecove]

The List box should have a control function to select (highlight) item(s) in the list. Search msdn.Microsoft.com for the list box member functions.

e.g https://social.msdn.microsoft.com/Forums/vstudio/en-US/c93bd6b8-7b38-46e5-b640-bfba96f309da/programatically-select-items-in-listbox

IOW, prefill the list, then call the function to highlight the items of interest (prior selected items).

Jim Dempsey

[dboggs]

Jim: thanks for the tip re listbox control; looks like this will definitely help. Still investigating.

app4619: Thanks for the code snippets to hide a control. But, you are illustrating API calls and I am using IVF calls. Even if the API calls work in a Fortran console application, I will need to get hDlg and I don't know how to do that. There must be a way, can you help?

In IVF one references the dialog window by its name, in this case IDD_DIALOG1. How to convert that to a Windows handle? The relevant parts of my code are

USE IFLOGM
TYPE (DIALOG) dlg
lreturn = DLGINIT (IDD_DIALOG1, dlg) ! Initialize the dialog
ireturn = DLGMODAL (dlg) ! Show the dialog window
! Does derived type dlg have any additional useful info?
PRINT *, dlg%HWND ! shows 0; not useful

[jimdempseyatthecove]

Google is your friend. Try searching "fortran windows dialog box listbox". You will find some informative hints.

Please post a snip of your solution so others following your thread can take advantage of your efforts.

Jim Dempsey

[andrew_4619]

That is a modal dialog when you print PRINT *, dlg%HWND the dialog has already closed. so the handle is zero

In the callback for IDD_DIALOG1,  dlg%HWND should be a valid handle for the dialog. GetDlgItem gets the handle of the control taking parameters of the handle of the dialog and the ID of the control (the normal resource ID).

bret = ShowWindow (GetDlgItem(dlg%HWND, ID_OF_THE_CONTROL_TO_HIDE) , SW_HIDE )

[jimdempseyatthecove]

dboggs wants to go a bit deeper to preselect items in a list box who's number of list entries is determined at run time.

At times it may be easier to learn how to write a C helper function when what you need is not available as a Fortran interface (or too obscure).

or if you prefer you can use C# or VB or (your choice here).

Before he goes to that length, google search will likely yield a good hit to stay in Fortran.

Jim Dempsey

[andrew_4619]

@jim  At first I thought pre-selection was required but I read that as more than pre-selection as a 'record' on the screen of what was pre-selected is needed, This is lost as soon as some user selection changes are made.

@dboggs, making is preselction of a list is quite easy if that is all that is needed. Maybe is is possible (I would need to check)  if some other style could be set for pre-selected items (e.g. a bold font).

    use iflogm, only: dialog
    use ifwin, only: SendDlgItemMessage,LB_SETSEL, fwparam, flparam, lresult, true, false
    use dku, only: IDC_LIST_ORTH
    implicit none
    integer, intent(in)      :: item, istate
    type(dialog), intent(in) :: dlg
    integer(lresult)         :: lres
    if(istate==1) then 
        lres = SendDlgItemMessage(Dlg%hwnd, IDC_LIST_ORTH, LB_SETSEL, int(TRUE,fwparam), int(item-1,flparam) ) 
    else 
        lres = SendDlgItemMessage(Dlg%hwnd, IDC_LIST_ORTH, LB_SETSEL, int(FALSE,fwparam), int(item-1,flparam) ) 
    endif

The above sets the selection state for List item number "item"  (note numbering starts at zero not one) for a list box whose ID is IDC_LIST_ORTH. Not this needs to be in the callback and you will need to set the data for the initial selection status whe callbacktype == dlg_init

[dboggs]

Despite the difficulty handling the "preselection" issue, a multicolumn listbox is what I am now pursuing. But here's the next obstacle: how does one set the width of the columns?

It appears that by default, with my font, the column width is 81 twips (or whatever the units are in the .rc file). Thus if I make the listbox width say 120 units, it will display the full width of the first column and about half of the second column. Not good. If I want the box to show five complete columns, I can specify its width to be 5*81 = 405 units. But this seems a silly way to manage it.

What if I want to change the column width from 81 units to something else? By testing I find that this width is just enough to show a list item approximately 20 characters wide. If some of the items are wider, how can I widen the columns to accommodate? Or, if all the items are much shorter, how can I narrow the columns to fit more columns in the box?

I have searched the internet to no avail. I have looked in a couple of other languages, with mixed results. In one, the integrated resource editor recognizes "no. of columns" as a listbox property, so it will take whatever the listbox width is and make the columns narrow enough to fit the specified no. into the box. In another language, the columnwidth is recognized as a listbox property so you can set it directly. But neither of the resource editors I have available recognize either of these properties.

If anyone knows how to do it, could you post the relevant portion of the .rc file? (Note that I am not looking to control this programmatically at runtime; at design time would be good enough).

[andrew_4619]

Hmmm I no nothing about multi-column list boxes and having spend a few minutes on  google still know pretty much nothing, I can't even find an example. Why do you need multiple columns, is it a data table?  You can have several single column list boxes side by side and syncronise scrolling I think if that helps, 

The problem I have found is you can do some simple tweaks to IFLOGM dialogs using the API but after a while it becomes messy and you find it easier to mange the dialog using only the API which after an initial bit of pain isn't really any more difficult and is much more flexible. IFLOGM has a limited set of features and hasn't been enhanced (other than some bug fixes) for years......

[IanH]

Are you just using the stock windows list box control?  If so... "The list box automatically calculates the width of the columns, or an application can set the width by using the LB_SETCOLUMNWIDTH message."

I don't find multiple column "simple" list boxes (versus a list view that shows one item per line, but with multiple fields for that one item) intuitive.  The vertical arrangement (with scroll bars if necessary) is far more typical.

[andrew_4619]

So is a multiple column box one that just wraps round the same list in newspaper column format? That would explain why there is no specific documentations. As Ian says LB_SETCOLUMNWIDTH (applies to each col) and as you noted setting the number of column in the Resource properties is all you should need in this case.

[LRaim]

For your problem the creation at run time of a window with the number/type  of controls you need would be the best solution.

Regards