Win10, alternative screen buffer, cursor doesn't blink

[vefatica]

In Win10/64, stand-alone TCC, after "echo %@consoleb[0]", the cursor doesn't blink in the new buffer. If I go back to the original buffer, it blinks.

 

[rconn]

Talk to Microsoft - TCC doesn't have any control over that.

 

[vefatica]

Talk to Microsoft - TCC doesn't have any control over that.

I understand that "insiders" can give feedback. How do I (or you) do that?

 

[vefatica]

Talk to Microsoft - TCC doesn't have any control over that.

I dunno! If I do this in a plugin command

Sleep(5000); honk();
    HANDLE hNew = CreateConsoleScreenBuffer(GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, CONSOLE_TEXTMODE_BUFFER, NULL);
    SetConsoleActiveScreenBuffer(hNew);
    Sleep(5000);

I see a nice steadily blinking cursor until the end of the second Sleep. Then, when the prompt appears, the behavior is unpredictable. The cursor may not blink at all, or it may blink oddly, as if it's being controlled by two (independent) timers. I'm curious ... does issuing the prompt do anything at all that would/could affect the blinking of the cursor?

 

[rconn]

There's a Windows API "SetCaretBlinkTime" that adjusts the console cursor blink rate.

TCC never calls that API. And issuing the prompt does nothing that should affect the cursor blinking. On my system, an "echo %@consoleb[0]" does not affect the cursor blinking. (Win 10.0.18298.1000)

 

[vefatica]

Try "echo %@consoleb[0]" twice. In a stand-alone test EXE that uses SetConsoleActiveScreenBuffer I have to do it twice (i.e., go to a second alternative buffer) to see the misbehavior. But it was there, so apparently it has nothing to do with TCC.

When did you get 10.0.18298.1000? I'm on 18290.rs_prerelease.181121-1501 (10.0.18290.1000).

 

[rconn]

Try "echo %@consoleb[0]" twice. In a stand-alone test EXE that uses SetConsoleActiveScreenBuffer I have to do it twice (i.e., go to a second alternative buffer) to see the misbehavior. But it was there, so apparently it has nothing to do with TCC.

When did you get 10.0.18298.1000? I'm on 18290.rs_prerelease.181121-1501 (10.0.18290.1000).

I tried it 10 times in a row, never had a problem with the cursor.

I'm on the fast ring; got 182898 last night.

 

[vefatica]

I tried it 10 times in a row, never had a problem with the cursor.

I'm on the fast ring; got 182898 last night.

I think I am too. Was it pushed on you?

From what I could Google up, it seems they did a lot of work on the console cursor. Maybe they fixed it.

 

[vefatica]

182898 is on its way. Getting a new version of the OS clobbers some customizations of mine, notably
1. my PSUBSTs are removed
2. I lose write access to a subkey of HKLM\...\Services (gotten with the ancient SUBINACL.EXE)
3. I get back all the stuff in "This PC" that I've hidden (3DObjects et al.)

This will be my first chance to test a REG file and a BTM that will (hopefully) fix all that.

 

[rconn]

Yes, they pushed 18298 to me last night.

MS has been doing a lot of console cursor changes (different shapes, colors, etc.) in the latest Win 10 builds.

 

[vefatica]

Did you have builds between 18290 and 18298? I had monkeyed with a GP telemetry policy and that had an effect on my updates. I backed off on that and then could find the latest.

 

[vefatica]

Yup! 18298 fixed the problem mentioned in this threads first post.