[Tutor] returning from 2 functions at once

[Alan Gauld]

On 10/10/2021 20:14, Ed Connell wrote:

> You hit the nail square on the head.  It is the event-driven mode that has
> me flustered.  I have consulted many examples and they ALL have one thing
> in common.  No matter the triggering event (change in selection,
> double-clicking, or responding to a button-click) they ALL print the choice
> from within the call-back function.  I have made choice
> a global variable, but this seems mickey-mouse to me. 

Not at all. if you are not using an OOP architecture then global
variables are the only way to communicate the choice between functionds
i an event driven architecture. If you don;t like having a lot of
globals you could create a single dict and store the values there, but
that's really just disguising the global not removing it.

This is why OOP techniques are so popular for GUI programs. You can
store the choice as an attribute of an object representing that
window/screen/form. Then any time the Window with the list is
visible the choice is available.

> Probably there is an easy way to communicate the choice to the rest of the
> program, but it escapes me.

A global variable or an attribute of the Window object.
Those are the most common options.

> What I want is to be able to pass, from a program section, a candidate list
> (counties to visit, files to open, teams to watch) to the function and have
> it tell (return) my choice.

But that I don't understand. I think you need to describe it
in much more detail using example values. Describe what you mean
by passing "from a program section", where the list of counties
comes from. Which function are you passing it to? Hoe do you
make "your choice"? And when?

Maybe avoid terms like "you" or "I" or even the "function"
and instead describe the interaction in terms of user roles
and the application. eg.

1. The app displays <what? describe the UI>

2. The user <does what??? which buttons, fields, lists do
   they interact with What values do they choose of input?>

3. The program responds by <what? How does the display or data change?>

And so on. This kind of dialog between users and the system is
called a use case and  is commonly used to define the requirements
of a system in unambiguous terms.


> If this is not something you want to mess with, please tell me the
> help-list to annoy

This level of tkinter is entirely appropriate for the tutor list.
We are very far away from advanced features here. These are the
fundamentals of GUI programming, in fact not even tkinter specific
but applicable to most GUI toolkits.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos