After discovering a solution, I changed the balance of the (Struct static values) to be (var), compared to (let). jim_k

Well, my application is now having a juvenile fit ... :] The tableViews are misbehaving by creating incremental uncommon selections, compared to none, while using a struct to reset previous transferred values to the tableView, as stated in a previous post. For the moment, I still believe I did not complete the install process properly, when Xcode illustrated a comment after the update to complete an additional setting. Regretfully now, I cannot use my previous application incarnation to identify common numbers in the tableView between columns. My applications (new and old) continuously exhibit the following message : (copy_read_only: vm_copy failed: status 1.) upon startup too, sometimes more than once, sometimes not at all. An unfortunate moment with the current update, but hopefully I (now we) shall discover a resolution, or whether a resolution could exist. I am reluctant to remove Xcode and reinstall Xcode, where the internet presents too many solutions, complete with too many caveats. Hopefully a solution appears in the near future ... :] Best regards, jim_k

An update to this issue ... The application required the Struct values to be reset to Zero (0) before requesting new search values, which the application calls with a function. The application remembered the previous numbers to find during the first pass in the tableView, causing the first few tableView numbers to be erroneous, which became identified as [EQUAL] to the common number. The tableView performed well after the application reset the Struct values to Zero (0) prior to an incremental search. The application started to misbehave again after the last Xcode update, because Xcode is brighter than I am, where the tableView would show the tableView's [COMMON VALUES] properly upon the initial tableView display, that is until the application scrolled the tableView to see the incremental [COMMON VALUES]. The tableView remembered the last font and colour change to the [COMMON VALUE] textCell.textField, causing every subsequent tableView textCell.textField to change colour, and size too. The issue became clear the application required attention to the tableView values [NOT EQUAL] to the [COMMON NUMBERS] to remain unchanged. The application tests whether each cellView.textField is [GREATER THAN] or [LESS THAN] the [COMMON NUMBER]. Therefore, I made sure, I set the [UNCOMMON] textView cells to the original font colour, and size to prevent the unwanted change within each conditional test with the following code: `/// Keep the cellView.textField [AS THE ORIGINAL (IB) VALUES] when each [GREATER THAN] or [LESS THAN] conditional is met: cellView.textField?.textColor = NSColor.white /// Keep the cell font size at [11]. let fontSize = 11 cellView.textField?.font = NSFont.systemFont(ofSize: CGFloat(fontSize)) // Compared to the changed cellView.textField: // Change the [TEXT FIELD COLOUR TO YELLOW] when the [cellView.textField IS EQUAL TO THE COMMON NUMBER] condition is met: cellView.textField?.textColor = NSColor.systemYellow // Change the (TEXTFIELD FONT SIZE) with CGFloat. let fontSize = 12 cellView.textField?.font = NSFont.boldSystemFont(ofSize: CGFloat(fontSize))` The tableView behaves as expected now. Respectfully, jim_k

Vika ... :] Thank you ... I shall add this solution to my Xcode notes. As a side note, I solved the incremental [uncommon selections] occurring in the tableView. The application continuously changed the tableView cells font size and colour, while scrolling the tableView after the primary condition [=] was met. The application remembered the initial font change. I solved the issue by resetting the tableView font information to the original size and colour with two secondary conditions, such as [<] or [>] when the primary condition [=] was not met. Again, thank you for your response. Best regards, jim_k

Hello Nate ... :] Thank you for the updated information , where I shall review your process. My previous issue was too sporadic [worked , did not work] to consider incorporating the tab view functions with success. I incorporated a different programming route , where I created the [Tab Views] programmatically , without the hassle of a crashing application. That said , I shall see what your solution brings. Thank you for providing a response ... :] Best regards, jim_k

Unfortunately, and for the moment, I believe my Mac Mini M1 (16GB) does not have enough RAM to operate properly, when compiling this file ...