Initialising static class variables with external data - is there a better way?

I have static class variables in my own class that contain pointers to UTFT objects, used for graphics and touchscreen control. These are used by methods in my own classes and it makes sense to have them there once only available for use by all methods rather than an instance per object.

After a bit of research, I have the static variables working ok. However, most of the examples I can find use statics to keep track of internal class parameters (eg, the number of objects created, the highest number for something, etc) which means thay can be statically initialised at compile time. My value is not known until run time and needs to be externally initialised.

All my classes are derived from a base class that contains common parameters and functions. As such there is no need to use the base class that owns the static data, but i have 'kludged" an initialisation that allows me to pass in the UTFT object pointers at run time (see the definition below, in the constructor)

class MD_GUI
{
public:
    // Attributes
    int8_t  id; // return value when the button is pressed
    bool    enable; // is enabled (true by default)
    uint16_t    value;  // current value

    void begin(UTFT *S, UTouch *T) { _S=S; _T=T; };

protected:
    static UTFT *_S;    // the display
    static UTouch   *_T;    // the touch screen
};

In the setup() function I then declare a short lived local instance of the object, just to initialise the statics:

void setup() 
{
    MD_GUI  GUI;

    GUI.begin(&myGLCD, &myTouch);
}

This works, because the static variables persist after the object instance is killed off, but it does not seem an 'elegant' solution to the problem.

Is there another way to do this that is more in line with a standard practice I can learn?

This doesn't make sense though:

    void begin(UTFT *S, UTouch *T) { _S=S; _T=T; };

If you have static variables, may as well have a static method to initialize them. Using an instance implies that there is something about this instance (compared to another instance) that is important.

Using an instance implies that there is something about this instance that is important

That's probably why I was thinking this was not the right way.

Anyway, now changed to

static void begin(UTFT *S, UTouch *T) { _S=S; _T=T; };

and calling this from setup()

void setup() 
{
  MD_GUI::begin(&myGLCD, &myTouch);
}

Much happier, thanks Nick.

void setup() 
{
  MD_GUI::begin(&myGLCD, &myTouch);
}

The implication here, still, is that you will have multiple instances of the MD_GUI class that share the same display and touch screen.

I can't imagine that that is the case.

Yes, unless you are creating more than one instance, why bother?

The implication here, still, is that you will have multiple instances of the MD_GUI class that share the same display and touch screen.

That is exactly the case. The MD_GUI base class is only instantiated as a by product of creating other graphics elements (buttons, checkboxes, etc). All share the same physical user interface (screen/touch screen) that is managed through the UTFT library.

Is there a better way to do what I need to do? Clearly if I can generalise so that if I ever needed to have a multiple displays (eg serial displays), everything still works without refactoring the code, it it worth doing that now.

You might want more than one class type. One for the screen itself (which you could have multiple instances of if you had multiple LCDs) and a different one for GUI elements. The screen one could "own" the elements perhaps, or at the very least, a particular element could have a reference to the screen that it belongs to.

a particular element could have a reference to the screen that it belongs to.

This is how it started. For each element I passed in the pointers to the 2 UTFT objects. I must say it got a bit cumbersome and I was repeating these pointers all over the place, taking up precious bytes.

I guess that if something like MD_GUI.create() was possible, then the it would mean that different objects could be initialised to belong to alternatiove screens. In that situation, how would a reference to the individual objects be handled without creating lots methods? If an object is created as per above, does it automatically just belong in the namspace of the base GUI object?