> >> As a side thought, I'd like to suggest that the dialogs displayed to the
> >> user by root, for example to change graphing options on a TPad, etc. display
> >> the current values. A nice, ergonomic touch.
> >
> >Which graphing options would you like to see ?
> I think it would be "nice" to display the current values, ie. the values
> presently in force at the time any dialog is displayed; for example, from
> the right click menu on a canvas Range displays a dialog with four edit
> boxes for x1, y1, x2, y2.
It is not easy to provide the generic way for that. What you see is a dialog created
by automatic from the class header file on fly. ROOT can create such dialog for
any method of any class compiled.
The TConextMenu object is created as soon as you click "right mouse" button over
the object in TCanvas or TBrowser.
TContextMenu creates a dialog (In fact my mail sent yesterday just shows
how it is done). TContextMenu is destroyed as soon as the user clicks "Ok" button.
This is to say at present there is no room to keep the dialog parameters to present
them next time.
> Those boxes are displayed empty (as it's true for
> most fields on most dialogs (some display default values))... I'm suggesting
> that the current values (in this example, the current range values for the
> canvas) are displayed to the user for editing.
You should define what is the "current value" you are speaking about.
They are not data-members of the class method you are about to call
via that dialog. From another hand you may call the same method but
for another object. For example "SetName" dialog can be called for any
classes derived from TNamed. There are 100 of them. Do you expect
to see the same character line calling SetName for the histogram and
for TFile.
Of course for each particular case this problem can be solved and
for many classes ROOT does provide the custom dialogs with the "current"
values. (See all set graphic attributes for lines, markers, pad for examples).
> Even in this simple case
> there is the benefit
Yes of course, The only question how to do this "by automatic"
To manage things "by hand" ROOT had offered the GUI classes on
UNIX platforms.
> >
> >> Also which class could/should I use to display such a dialog window with
> >> a few (five is my present need) edit boxes and some static labels in my
> >> program?
> >
> >If I remember you are working on NT where the new GUI is not available.
> >To give an answer, I would need more explanation on what you want to do.
> Something akin to the dialog in the TCanvas Range right click menu.
I think the example I sent yesterday just shows an idea how you can achieve this
with the current classes. May be the Current TContextMenu class can be expended to give
user way to create TConextMenu with no TCanvas and TBrowser assistance. This may
provide the service you are speaking about and will not require the user to design / create
his/her own dialog for some trivial cases.
I may provide any assistance for the volunteer willing to enhance that class. It should not
be too difficult will take some time though.
With my best regards,
Valery
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:16 MET