It should be pretty straight forward
Even you must see by now that that simply isn't true. But: I will go down fighting, if I must ... as long as I do my fighting on my own time, I suppose.
maybe rename your .ini file out of the way and...Maybe reboot to..?
While I have reverted back to my everyday, production INI file each time (the one that's been working just fine for at least a year), I have not hidden it completely -- except for when I need to recover from a truly major foul-up here lately.
And, I did my time in the Tier 1 Help Desk trenches as well, and then served in Tiers 2 and 3 before they finally ran out of Tiers to put me on (and I had run out of tears, too), so I recognize the value of "turning it off and back on again." In fact, I do this religiously each and every day. "Dirty tables" cause as many problems as "faulty wires" do: My system never runs 24 contiguous hours, but it's only just another hoop so why not jump through it, eh? I'll do both and report back but be advised that the priority for me to acquire this bogey has dropped to zero.
In fact, in just another day or two the need to fire up TCC with a mysterious something
running in a second tab will have dissipated.
Oh, and @Charles Dye
: I owe you an apology, of course. First, I was a bit snippy when I made my wisecrack -- even though I tried to admit it at the time. It was uncalled for, and I regret it. Second, upon reflection, the truth in your remark is ineluctable: All of this code is compiled and linked against Windows
libraries -- where else would it ever run? -- and thus even the console code can legitimately be said to be "Windows programs" ... Metro, Desktop, Commandline, ..., what have you. Let me run and refill that coffee cup of yours. It is coffee