Panel management & multi-threading: design principles?

[Ian.W]

"Yikes", you're thinking, "a long question!" Please read on; it covers a

general topic many should find relevant.

I'm re-doing the architecture of a large program, and want input on the best

way to manage panels & program sections, and whether multi-threading is a good

strategy for me.

Basically, my program has a data-entry section, and a historical data display

section. Each "section" can involve many different panels. No data acquisition,

nor any real-time issues.

The data-entry section is well-served by the use of popups: it locks the user

from doing other things until the task at hand is completed in the required logical

sequence.  However, the use of popups prevents browsing of the historical data while

deciding what info to enter. 

So, what I think I want is two (or more) "parallel" windows -- one for data-entry,

and one (or more) other(s) for data display. I'd like popups to limit the users activity

within each parallel section, but not lock out activity in the other section.

Sticking with only two parallel sections for now, I envision them residing as

two child panels within a parent panel, or just as two top-level panels.

My options seem to be:
a) Split it into two programs and have the data-viewing program launch a new

app to enter data (or vice versa). The challenge here is to not confuse the user,  

to keep the 2 apps coordinated (e.g. close both apps together, and manage user

id & rights between them) and to share the data efficiently.

b) Multi-thread the program. I think this solves the problem of a popup locking

any activity anywhere within the whole app. Seems daunting, and possibly

unnecessary since there is no "real-time" element to the program.

c) Don't use popups. Manually code in all the panel management, controlling

access to each panel as a new one is displayed based on the current state.

Seems like a lot of work to track & manage manually.

What is the best path to take?  Any proven principles or practices to guide me?

Thanks in advance for your input.

[jr_2005]

Since you don't have a real-time requirement to satisfy, I would go with option 'c'. I had a similar program where I used a simple state machine approach: a global variable held the current 'state' of the application and this was used to index into a table which held a map of which controls were enabled or disabled at any time. Thus guiding an operator down a limited choice of actions, depending on the application's current state. This is the code I used, called whenever the state changed (in response to the controls' callbacks):

//*****************************************************************************************
void DimControls (void) {   // Dim/Undim controls according to the global state we're in

    static int ctrls [] = {     // The 10 controls for this function
        PNL_PROGRESS, PNL_REC, PNL_STOP, PNL_PLAY, PNL_STEP, PNL_BACK, PNL_FF, PNL_FR,
                                                                        PNL_IF, PNL_IR};
    static char *patt [] = {    // For 6 states, 10 controls
        "1110011111",           // 0 - As powerup
        "1101111111",           // 1 - Running live
        "1001111111",           // 2 - Writing to memory
        "1001011111",           // 3 - Writing to file (active)
        "0100000011",           // 4 - Memory replay
        "0100000000",           // 5 - File replay
        "1001111111"};          // 6 - Writing to file (paused)
    int i;

    for (i = 0; i < SIZOF (ctrls); i++)     // Run through list, dimming on a 1 (0 enables)
        SetCtrlAttribute (panHan, ctrls [i], ATTR_DIMMED, patt [state] [i] - '0');
}
//*****************************************************************************************

It worked quite well, but i think you would need to design the program with this approach included from the ground up, rather than try to bolt it on afterwards.

JR

[Ian.W]

Thanks, JR. Your example of tracking and managing the states is neat.

You comment that since I have no real-time requirements, multithreading is not what you recommend.  To other forum members: do you agree that multithreading is really only for addressing real-time requirements? Or is it a good tool to use for panel management?

Thanks,

Ian