Cascading menus
stevee at redac.co.uk
stevee at redac.co.uk
Mon Apr 10 09:13:14 EDT 2000
In article <38F0DF82.EEAB208D at dkfz-heidelberg.de>,
Kilian Lorenz <kilian.lorenz at dkfz-heidelberg.de> wrote:
>
>
> Perhaps you can solve your problem by using the postcommand option.
>
> When the menu is posted this function/method is called and
> probably you can change your sub menu there. I don't expect that
anyone
> estimates code to be run anytime a menu item is selected a very clever
> idea since with an indecisive user this could happen quite frequently
> and I can't think of a good reason why there should be done something
> else in the second call than in the first call (except perhaps making
a
> statistic about menu usage).
>
> But I don't speak for the whole Python/Tkinter/Tk-community and
> who knows ... nobody expects the Spanish Inquisition either ...
>
> Regards, Kilian
>
Using the postcommand hook is another option I am investigating.
However it is looking like a lot of work to get that to function
correctly. For example I might have existing code called by the parent
menu that looks like this:
function foo
set some variables
check a feature is authorized
display sub menu
do some more stuff
To automatically translate this to Python I need to extract the code
before the sub menu display into another function that can be called
by the postcommand hook. Unfortunately there are a lot of cases that
are more complex than this, with several levels of functions before
the sub menu display:
function foo
set some variables
call function bar
do some more stuff
function bar
check a feature is authorized
display sub menu
And so on.
In addition in some cases the code actually decides between several
different sub menus at run time:
function foo
set some variables
check a feature is authorized
if feature 1 then
display sub menu for feature 1
else
display sub menu for feature 2
do some more stuff
This would require me to completely redefine the sub menu on the fly!
However you are fundamentally right this is not a clever idea. Thus
the aim is that as we redesign the interface the auto generated code
will be dropped to we end up doing things correctly. Unfortunately the
effort estimate to do the complete UI redesign in one go is so high
that it will not happen, which is why we are trying to change the
current interface to use Python without radically changing the
interface itself. This then allows to gradually move the UI to where
we want it.
But thanks for your reply.
Steve
Sent via Deja.com http://www.deja.com/
Before you buy.
More information about the Python-list
mailing list