Cascading menus

stevee at stevee at
Mon Apr 10 15:13:14 CEST 2000

In article <38F0DF82.EEAB208D at>,
  Kilian Lorenz <kilian.lorenz at> 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
> 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
> 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
           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.


Sent via
Before you buy.

More information about the Python-list mailing list