That leads me to the question I’ve had for some time in my linear way of thinking and programming.
I mentioned before I’m doing a lot of the chores within a single window with a 5 dimension array holding the data which includes:
Time period start (Slider)/Heating start time(Slider)/Time period active (Checkbox): 0-2
Economy/Normal mode 0-1 (set in the menu but saved in array prefs)
Day of week (Button): 0-6
Heating zone area(Button) : 0-4
Periods in day/Away temps 0-4
HeatingPrefsArray(2,1,6,4,4)
All this info is saved in the heating prefs array which we are now passing to the window as a ref to a holder class of all my arrays.
Is there an advantage to creating multiple instances of the window to enter these parameters. I can not understand why I would want to but! Maybe a different window for each day of the week or?
this is one of those “it depends” kind of questions
would it make a sensible UI for you to have multiple windows ?
what would those multiple windows have in them ?
I’d start by considering those kinds of things before doing anything.
sketching out how a UI would work on paper is sometimes very useful ESP since if you dont like the way things are going all you do is recycle the paper and start pver
Although I may not need constructors and a destructor I wanted to become familiar with their operation. I was able to use the constructor but from the same instantiated window I was not able to get the destructor to fire when the it closed. In Real Basic, they used a tidily in front of the destructor name. Any magic I need to know about to have it fire?
Calling “close” or manually clicking the close button should make the destructor fire
BUT that also assumes that other parts of the program have not held a reference to the window
Would have, could have I guess. The last statement before the window closes is: Self.close
Can something still have a ref to it after the self.close? Might a permanent preference in App. of the array class that was sent to the window in question do that?
unlikely the global array would be the cuplri
usually it would be a property of type Window, or in this case Normal_Heating_Preference_Window, that exists and is NOT part of that window
And that reference to the window could retain the window and make it so the destructor does not run since that reference is still valid