GUI: changing the number of the edit boxes in the dialog

[dan789]

Could somebody please advise a simple way to create a user friendly interface for entering a varying-number of parameters:

A user first specifies what the number of parameters is equal to, and then he should edit (or live as is) a number of pre-filled edit boxes. By edit box I mean here not necessarily the standard edit box but some sell containing a digit or string that may be changed by the user. And, the number of this edit boxes in the dialog should depend on the user-entered number in the same dialog.

[Paul_Curtis]

Assume you know in advance some maximum number of possible data items, each requiring an editbox. Design possibilities include:

1. Create the dialog with all possible editboxes for data items, plus an editbox for total number of data items, perhaps with a spin control with (min, max) limits. Once the user has provided a datum count, those datum editboxes which will not be used can be either disabled (greyed), or made invisible.

2.Show an array of all possible editboxes, greyed, each with a companion "use this parameter" checkbox. When a checkbox is checked, it's companion editbox is then enabled for data entry; you use the notify function of the checkbox to dynamically monitor it's status.

These designs require that you run your own proc function for the dialog, to receive the notify messages, reset the controls and so forth, and are probably beyond the means of Quickwin or similar abstracted environments.

[dan789]

Yes, I was thinking about just making some editboxes inactive. It would be the simplest solution. But imagine, a user has to pass to a program a vector with the dimensionality n. In the case n=1, 2, 5, etc, its OK. But what if it is, say, 20?

In fact, I have to provide an input for a nxn matrix: when the user sets the dimensionality (n), the pre-edited matrix appears it is possible to live it as it is, or change some sells.

[Intel_C_Intel]

What Paul-Curtis says is quiet doable in quickwin; I do this in my stat package, which is highly parameter driven.

[Paul_Curtis]

The additional info from the OP, that input can consist of a large vector or possibly a matrix of values, suggests that perhaps he should consider 1) acquiring the input dimensionality from a simple dialog, and then 2) shelling out to Excel, with a pre-formatted spreadsheet hilighting (and pre-loading) the cell array of input values, where all the GUI work for this sort of inputis already done. The array can then be read back from the spreadsheet when input specification is complete. Reading to/from Excel is fairly straightforward, and there are lots of examples in the CVF materials on how to do this. Depending on the overall nature of the app, perhaps the tail should wag the dog here, and the fortran calculational component should be invoked from a hosting Excel procedure, with results delivered back to Excel.

I personally tend to deprecate quickwin, which I do not use, because all of the GUI questions in this forumwhich arise from quickwin contexts always seem to be driven by the limited direct access withinquickwin to the underlying Win32 fundamentals, and the answers always involvecalling the correct Win32 functions directly to get the job done. If you start with a GUI wrapper function todeliberatelysubmerge the details, but then have to build explicit procs to deal with messages which are not dealt with as wrapper arguments because they are beyond the level of abstraction of the wrapper, then using the wrapper would seem to be more trouble than it's worth.

[dan789]

Thank you, Paul-Curtis, Excel is a good idea. But I dont want to use Excel as a wrapping application. My program should work like this: 1) user-friendly input (may include large vectors and matrices lets use Excel here), 2) Calculations (time-consuming, therefore I use Fortran here), 3) Output with the possibility to export to a good scientific graphing software (not like Excel:). So, at this point I am a bit confused about several issues:

1) Where to read about CVF-Excel interaction?

2)Is it possible to call from my Fortran program some objects registered by another commercial software at the users computer (I mean Excel), without calling the Excel application itself?

3) May be Excel is still not the best solution. For example, if I use Delphi to create GUI, there is an object called greed there, which is somewhat OK for my purposes to input a matrix. So I am wondering If an object like this is available in Visual Fortran (I may consider a commercial one if it exists).

Message Edited by Dan789 on 04-26-2005 01:40 AM

[onkelhotte]

You can use f90sql from http://www.canaimasoft.comto interact with Excel thorugh the ODBC interface via SQL. But the free lite version can not create Excel files, and you have to use entries in the ODBC itself to open files.

[dan789]

Thank you, OnkelHotte, good link. Ifyou are using this app, could you tell me,does it allow to open a nxn square of excel cells in a Fortran-made window?

Message Edited by Dan789 on 04-26-2005 04:54 AM