Ah, so the order of the Outlet statement controls. I tried the order in the StoryBoard without effect. Good to know.

Ah, excellent OOPer. I replaced my code with yours a got something that resembles the TV test pattern. I was worried about my storyboard being buggered, but now I know that's OK. Thanks. The key changes to my code (which now works!) are: declaring let layer = CAShapeLayer() within the loop. I had let shapeLayer = CAShapeLayer(). before the function declaration analysisView.layer?.addSublayer(layer) which provides the missing tie-in to the Outlet Thank you so much!

actually this set is a little better in illustration: let ranges = [ 1...4 ,0...0 ,1...6 ,3...5 ,0...0 ,2...4 ,3...7 ]

In both cases (with and without 1...4) ordinateMinimum should = 0 and ordinateMaximum = 7 For the "little better set" ordinateMinimum should = 1 and ordinateMaximum = 7 It seems the min and max functions abort the sieve if the first pass doesn't yield a value.

Thanks for responding Claude31. I'll need to move my "func possibleCombos()" into my ViewController as it is currently remote. Yes, I'm beginning to see. Since the progressBar must be a member of the ViewController, the "when" and "progressBar.doubleValue" assignment must be made within the class also. I thought (hoping) maybe there was a way to have remote functions "use" or "pass" messages into or out-of the ViewController. It will take me a while to study and assimilate this. Thanks!

I didn't mean to abandon this thread, it's just that I've tested the code and discovered the nested for-loops execute over 1.5E14 times and would require over 650,000 days to compute. A progress indicator is moot. I'm looking into whether GPU efforts would even help. It's mostly an issue of getting the results to memory and then storage. Since the memory required is tens of GB if not hundreds of GB, I/O speeds dictate not computational speeds. So I'm also re-thinking compromises. In the mean time, Claud31 did answer my question in a few different ways, so I'll close the thread.

Fred Weasley: "Blimey, what a waste of parchment"

The action of a button { inside the curly brackets } seems to act like a Dispatch.async I assume ProgressView() is still a work-in-progress at Apple. Their current example code is clearly non-real-world, i.e., useless.

Thanks, but I was looking for faster computing of heavily nested For-Loop modeling. My research shows GPU's are not so useful.

Actually, since the size of the structures ARE known if they are populated, i.e, they are a class instance with optional variables, I could use that full size. It may be inefficient, disk wise, but is the best option so far.

Nope, my class has optional arrays of unknown count.

the runtime aborts when it hits a classTwo.init() @ self.e_Two = e_Two ?? [class...

NO. runtime actually aborts @ aCoder.encode(e_Two, forKey: CodingKeys.e_Two.rawValue) during a save-to-file function.

OK, that's all the unique code. If you cut and paste into a new project of your making, you can run it and get the same errors. Thanks.

FYI: "man sysctlbyname" does deliver a man page but "which sysctlbyname" gives: "sysctlbyname not found". Also, mdfind sysctlbyname is void.