| widget_table [message #15223] |
Mon, 26 April 1999 00:00  |
R.Bauer
Messages: 1424
Registered: November 1998
|
Senior Member |
|
|
Is it possible to switch off the column or row labels.
Not at all both.
R.Bauer
|
|
|
|
| Re: widget_table [message #19026 is a reply to message #15223] |
Wed, 23 February 2000 00:00  |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Brian Reardon (reardonb@my-deja.com) writes:
> The following code (compliments to David Fanning) is intended to
> generate two tables.
Now, hold on there, Brian. I didn't write this code.
Nor did I ever (to my recollection) recommend that you
write it. If word got out that I was recommending the
Table Widget my reputation and credibility would be shot. :-(
> The first is a column lable for the second which
> is to be edited by the user. The problem is that when I run this code
> on my Mac with IDL 5.3 there is what appears to be an extra column and
> row on the right and bottom of each table. Adding /scroll does not
> cover this space up. In fact, it makes it worse. What causes this extra
> space and how can I get rid of it.
I don't know what causes it. I don't think you can
get rid of it. I've heard of it before, but I dislike
the Table Widget so much I don't even want the correspondence
about it polluting my directory structure, so I don't even
have a record of what has been said about it.
> Also, a search on this newsgroup indicates that everyone hates
> widget_table.
Really!? How can that be? I'm sure it doesn't have anything
to do with the way the damn thing works. :-)
> How can I accomplish the same thing without using
> widget_table?
Well, I haven't really had need for a table widget before
(thank Goodness!), but if I needed a decent table widget
here is what I would do.
1. I'd write a Cell object, which would be a text widget
smart enough to know if it was editable or not, whether
it contained a number or string, whether it should always
be positive, etc. I'd probably steal a great deal of code
out of my FSC_InputField object to write this object.
2. Then I would write a Table object that was an array
or grid of these Cell objects. It would have the ability
to tell Cell objects what to do. For example: resize
yourselves, change all your values to 0, reorganize
yourself from a 6x2 grid to a 2x6 grid, tell me what your
current value is, etc. Whatever it was that would be
required for my particular application.
3. I'd offer it for sale for one month. Then, when I
realized how futile it was to get somebody to pay me
for it, I'd offer it for free on my web page and hope
someone would by the book I wrote to describe how
the free software works.
That's what I would do. :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
|
|
| Re: widget_table [message #19109 is a reply to message #15223] |
Thu, 24 February 2000 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Brian Reardon (reardonb@my-deja.com) writes:
> I find it hard to believe that no one as been in my situation. Perhaps I
> need to explain the problem a bit more. Let's say that I am writing an
> IDL program called X_Optimizer that
> optimizes a vector of parameters (Test_Params) that are sent to a user
> defined function called FX and FX returns a vector of data called
> Calc_Data that is then compared to a vector of experimental data call
> Exp_data. Based on how that comparison goes, X_optimizer adjusts
> Test_Params accordingly and then calls FX again. Now, let's say that
> each element of Test_Params is somehow selected from a user defined
> range of possible values. In otherwords, in X_Optimizer, there is a
> widget that allows the user to enter in how many variables are used by
> FX and what the upper and lower bounds on those variables are allowed to
> be. Thus, I need a widget that allows the user to input:
> 1) the number of variables that will be optimized,
>
> and then in (some sort of) table form:
>
> 2) a vector that holds the names of each variable (Temperature,
> pressure, IQ, etc)
> 3) a vector that holds the lower bounds of each variable (0., 0., 80.,
> etc)
> 4) a vector that holds the upper bounds of each variable (1000., 100.,
> 140., etc.)
> 5) a vector that holds a measure of the resolution that is needed for
> each variable(1.0,0.1,1.0, etc)
>
> What is the best way to go about doing this if widget_table is not to be
> used?
I really don't know about the "best way". There are all
kinds of ways to organize your graphical user interface.
I'm just saying that for me personally the table widget
option is usually far down the list of possibilities.
So far down, in fact, that I have never yet had to
implement one. But, as Pavel points out, it may be
just the thing for you. You shouldn't let my personal
taste in graphical user interface elements get in the
way of your design decisions. :-)
I will say, however, that when I am thinking
about bounding the value of a variable that one of the
first things that pops into my head is a slider widget,
since I think (depending upon the application, of course)
that this gives better feedback to the user and allows
more freedom to "play" with the data. It also cuts down
on a lot of the error checking I would have to do if
I allowed the user to "type" a value.
In your case, I would think, probably, of creating a
pop-up modal dialog that described the user's choices
and offered a number of different kinds of widgets to
express the user's wishes. It's hard for me to say,
exactly, what that would look like without knowing more
about the problem. But I'm pretty sure my implementation
of the solution would not have a table widget. :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
|
|
| Re: widget_table [message #19112 is a reply to message #15223] |
Thu, 24 February 2000 00:00 |
reardonb
Messages: 16
Registered: December 1999
|
Junior Member |
|
|
Dave,
I find it hard to believe that no one as been in my situation. Perhaps I
need to explain the problem a bit more. Let's say that I am writing an
IDL program called X_Optimizer that
optimizes a vector of parameters (Test_Params) that are sent to a user
defined function called FX and FX returns a vector of data called
Calc_Data that is then compared to a vector of experimental data call
Exp_data. Based on how that comparison goes, X_optimizer adjusts
Test_Params accordingly and then calls FX again. Now, let's say that
each element of Test_Params is somehow selected from a user defined
range of possible values. In otherwords, in X_Optimizer, there is a
widget that allows the user to enter in how many variables are used by
FX and what the upper and lower bounds on those variables are allowed to
be. Thus, I need a widget that allows the user to input:
1) the number of variables that will be optimized,
and then in (some sort of) table form:
2) a vector that holds the names of each variable (Temperature,
pressure, IQ, etc)
3) a vector that holds the lower bounds of each variable (0., 0., 80.,
etc)
4) a vector that holds the upper bounds of each variable (1000., 100.,
140., etc.)
5) a vector that holds a measure of the resolution that is needed for
each variable(1.0,0.1,1.0, etc)
What is the best way to go about doing this if widget_table is not to be
used?
-Brian
Sent via Deja.com http://www.deja.com/
Before you buy.
|
|
|
|
|
|
|
|
|
|
| Re: widget_table [message #54889 is a reply to message #15223] |
Thu, 19 July 2007 12:24 |
2d
Messages: 24
Registered: July 2007
|
Junior Member |
|
|
Thanks Dave and Jean for these comments.
I'd rather stick with the Widget_Table as i have quite a few
parameters to input, and sliders are no good for precise values.
Naively, as "table" is the WidgetID from above, in the PRO
imager_parameters_quit_event, routine i put:
WIDGET_CONTROL, table, GET_VALUE=table_value
to which IDL responded by saying "Variable is undefined: TABLE", so
i'm clearly doing something not right.
As I'm really a beginner with widgets could you indicate how i either
"Store tableID either in your quit button uvalue" or "save a pointer
to a structure".
As a beginner i do find the help in the IDL rather limited, it could
do with more but really simple examples how how to do the things with
widget that people want. Generally i find the examples to long and
complicated you get lost in all the different things that are going
on. Would you know any websites where i can find simple examples of
table widget codes.
thank you, 2d
|
|
|
|
| Re: widget_table [message #54935 is a reply to message #15223] |
Tue, 17 July 2007 14:21 |
Jean H.
Messages: 472
Registered: July 2006
|
Senior Member |
|
|
2d@onetel.com wrote:
> I want to create a widget_table with default values and then change
> the values from the widget and then transfer those values back to a
> calling programme. A possible way of doing this is shown below, where
> a calling routines calls the routine imager_parameters transfers
> default settings to the widget. The widget is editable so i can alter
> the values. However, i dont seem to be able to read these values back
> to the calling routine. Does anyone have a suggestion as to how i can
> do this.
>
> many thanks, 2d
>
> PRO imager_parameters_quit_event, ev
> COMPILE_OPT hidden
> WIDGET_CONTROL, ev.TOP, /DESTROY
> END
> PRO imager_parameters, fov, freq, sensitivity
> d0={fov:fov, freq:freq, sensitivity:sensitivity}
> data = [d0]
> labels = ['FOV[Deg]', 'Freq[GHz]', 'Sensitivity[K]']
> maxwidth = 30
> base = WIDGET_BASE(/COLUMN)
> table = WIDGET_TABLE(base, VALUE=data, /EDITABLE, /COLUMN_MAJOR, $
> ROW_LABELS=labels, COLUMN_LABELS=['Imager Value'], $
> COLUMN_WIDTHS=maxwidths, /RESIZEABLE_COLUMNS)
> b_quit = WIDGET_BUTTON(base, VALUE='Quit', $
> EVENT_PRO='imager_parameters_quit_event')
> WIDGET_CONTROL, base, /REALIZE
> XMANAGER, 'imager_parameters', base
> END
>
Hi,
You must use WIDGET_CONTROL, tableID, GET_VALUE=table_value ... it
could be in your quit method or elsewhere. Store tableID either in your
quit button uvalue (poor technique if you want to do something else), or
save a pointer to a structure (or to a pointer array), which would
contain, at least, the tableID.
Jean
|
|
|
|
|
|
| Re: widget_table [message #54982 is a reply to message #54889] |
Thu, 19 July 2007 16:12 |
Michael Galloy
Messages: 1114
Registered: April 2006
|
Senior Member |
|
|
On Jul 19, 1:24 pm, 2...@onetel.com wrote:
> Naively, as "table" is the WidgetID from above, in the PRO
> imager_parameters_quit_event, routine i put:
>
> WIDGET_CONTROL, table, GET_VALUE=table_value
>
> to which IDL responded by saying "Variable is undefined: TABLE", so
> i'm clearly doing something not right.
Did you add that WIDGET_CONTROL *after* you defined table?
> As I'm really a beginner with widgets could you indicate how i either
> "Store tableID either in your quit button uvalue" or "save a pointer
> to a structure".
Get David's book.
> As a beginner i do find the help in the IDL rather limited, it could
> do with more but really simple examples how how to do the things with
> widget that people want. Generally i find the examples to long and
> complicated you get lost in all the different things that are going
> on.
The two examples programs I see for table widgets are 59 and 129 lines
long. It's hard to write a widget program that actually does something
in much shorter. Here are the example programs in case you haven't
seen them:
http://idlastro.gsfc.nasa.gov/idl_html_help/Example_Single_D ata_Type_Data.html
http://idlastro.gsfc.nasa.gov/idl_html_help/Example_Structur e_Data.html
> Would you know any websites where i can find simple examples of
> table widget codes.
Not specifically table widgets, but I think you should try to
understand this problem more generally, then try to learn the
specifics of table widgets. The article David originally referred you
to would be a good start (better yet, his book).
Mike
--
www.michaelgalloy.com
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
