Re: kButtonX processing, Root 2.23/10, WinNT 4

From: Mariusz Stanczak (MStanczak@usa.net)
Date: Mon Jan 10 2000 - 23:50:54 MET


On Sat, 8 Jan 2000 14:51:34 -0500,  Valery Fine wrote:

>> >>    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.
   I realized that while examining the classes from your enlightening
example.  But I must have not been very clear.  Although the macro you
provided is very clever, it demonstrates how to display a dialog from an
existing Root class (which, arguably could be my class), but aside from my
general suggestion about displaying parameters in (all) dialogs displayed by
Root (issues of which you explained in depth) my initial (and current)
problem/need is *how could _I_ construct, and display in my program a dialog
that would supply parameters to the user for editing*.  As we will, most
likely, move from WinNT to Linux in the future of this project, I would like
to stay as much as possible within the Root framework and avoid writing such
dialogs with MFC classes, for example.  TContextMenu would seem made for
such need were not for its static (compile time) nature (or could you
suggest a way I could display in, and read back from values with
TContextMenu after it is already constructed and displayed by Root?).
> 
[...]
>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.
   In the program I'm working on now I do have a canvas with a graph of
value ranges (somewhat similar to a stacked bars... or more like a bar with
markers denoting ranges).  Each set of (stacked) bars is treated as one bar
and it's an instantiation of one and the same class (hence the fluidity of
"current" values you spoke of).  When a user clicks on a bar I would like to
display a dialog displaying the set of values for that particular bar and
then read back the possibly modified values back.

>
>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
>
>
Thank you for your insight,

/Mariusz



This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:16 MET