Fixed OSD /C has no effect

Dec 29, 2009
30
0
Atlanta, GA
#1
When using OSD /N [/TIME=x] to put text on the desktop asynchronously, the /C flag fails to clear the display. This new behavior appears to have happened as a result of one of the recent fixes to OSD.

Here's a script that demonstrates:
Code:
@echo on
OSD  /N `Test 00`
delay 2

:: this line has no effect--
OSD /C

:: this line throws an error--
OSD /C

delay 2
OSD  /N `Test 01`
delay 2
OSD /C
delay 2
OSD  /N `Test 02`
delay 2

:: you should find the effect of the following interesting as well...
OSD  /N `         x`
delay 2
OSD /C
delay 2
OSD  /N `________`
delay 2
OSD /C

Note that there is some internal state change caused by OSD /C. If you try another one with no intervening OSD output, it throws an error. (I would expect it would just be a silent no-op, since clearing a display that is empty or nonexistent should be visually the same as doing nothing.)

Using different /ID=# or other args doesn't seem to affect this.

Version Info:
TCC 15.01.50 Windows XP [Version 5.1.2600]
TCC Build 50 Windows XP Build 2600 Service Pack 3
 

rconn

Administrator
Staff member
May 14, 2008
10,778
97
#3
And enclosing the text in single back-quotes doesn't preserve leading whitespace (as the help says it will).
That was removed a while back because (1) it's completely useless, and (2) users wanted OSD to display escaped characters (the parser will not translate escaped characters if back quotes are not being removed before passing the line to the command).
 
#4
That was removed a while back because (1) it's completely useless, and (2) users wanted OSD to display escaped characters (the parser will not translate escaped characters if back quotes are not being removed before passing the line to the command).
I'm not sure what you're saying in (2). Of these,
Code:
OSD  /N ^k          x^k
OSD  /N ^^k          x^^k
OSD  /N ^^^k          x^^^k
the first shows
Code:
          x
the second shows
Code:
^k          x^k
and the third shows
Code:
^`          x^`
So, apparently, you can still show leading whitespace and you can't show the backquote correctly.
 
Dec 29, 2009
30
0
Atlanta, GA
#6
Rex: that makes two of us! :confused:

(Sorry, Vince! Just not following you... unless maybe your point is that it's not showing escaped characters the way you'd expect?)

If the choice is between showing escaped characters or showing leading whitespace by backquoting, then I can see it would be preferable to be able to show the escaped characters. So no code changes, just a simple update to the help file, and very low on the priority list I'd think.

However...

My issue is that /C is not working. Admittedly that is also somewhat low priority... it's not actually breaking anything, it just means I sometimes get ugly overlaps for a second or two (if I tune the timings). But it is broken.

Finally: there's the issue of getting an error if you issue "extra" OSD /C commands. That's pretty low priority as well. You can wrap `OSD /C >&> nul:` with an alias and use that. Still, it would be nice if the error never happened, or if you could suppress it with /E or /Q or something.
 
#7
I have no idea what point you're trying to make here ...
You said "users wanted OSD to display escaped characters". So I'd expect ^k or `^k` to result in my seeing (only) a back-quote. Both of those result in errors (4 of them). How do I display a backquote? More generally, what are the rules? I can't make sense of it.
Code:
v:\> OSD  /N ^k
TCC: No closing quote
TCC: No closing quote
TCC: No closing quote
TCC: No closing quote
Usage : OSD [/C[=n] /FONT=n /ID=n /N /POS=n,n /RGB=r,g,b /TIME=n /TOP /LEFT /BOTTOM /RIGHT /HCENTER /VCENTER /V] text
 
v:\> OSD  /N `^k`
TCC: No closing quote
TCC: No closing quote
TCC: No closing quote
TCC: No closing quote
Usage : OSD [/C[=n] /FONT=n /ID=n /N /POS=n,n /RGB=r,g,b /TIME=n /TOP /LEFT /BOTTOM /RIGHT /HCENTER /VCENTER /V] text
 
#9
Do you actually want to display a back quote, or is this a purely theoretical exercise?
I could simple say "Yes" but I'd be lying. But it's more than theoretical; and I hope it's to some good end. Dealing with a literal backquote (or even pairs of them) has long been challenging. Generally, you could escape a '^k" enough times to get what you wanted but even that seems to fail with OSD.
 

rconn

Administrator
Staff member
May 14, 2008
10,778
97
#10
Finally: there's the issue of getting an error if you issue "extra" OSD /C commands. That's pretty low priority as well. You can wrap `OSD /C >&> nul:` with an alias and use that. Still, it would be nice if the error never happened, or if you could suppress it with /E or /Q or something.
There are three groups of users regarding bad commands:

1) The first (and by far the largest) group wants to know when a command didn't work.

2) The second group wants TCC to hide errors, and pretend commands always work. (Not sure how this group ever discovers when they have serious problems ...)


3) The third (tiny but by far the noisiest) group wants the DWIM parser to always know when they should be told about errors and when they shouldn't.

Group #1 currently has primacy -- so if you want to hide command errors use the redirection to nul. I personally consider an invalid /C to be a critical error, so something like a /NE wouldn't apply here.
 
#11
There are three groups of users regarding bad commands:

1) The first (and by far the largest) group wants to know when a command didn't work.
And I suppose they really like it when an error message gives a hint as to what they did wrong. "OSD /C" is correct syntax. So OSD's syntax message is not very edifying. Why not an appropriate error message?
 

rconn

Administrator
Staff member
May 14, 2008
10,778
97
#12
And I suppose they really like it when an error message gives a hint as to what they did wrong. "OSD /C" is correct syntax. So OSD's syntax message is not very edifying. Why not an appropriate error message?

Every custom error message has to be translated in 6 languages, which takes a lot of coordination and a lot of time. So that tends to be reserved for cases where the user won't already know what the problem is. And extra OSD /C's definitely don't qualify -- the OP knew the problem; he just didn't want to hear about it.
 
Dec 29, 2009
30
0
Atlanta, GA
#14
Rex, I'm in group "1b" -- I want to know when errors occur, but want to be able to suppress them in the odd cases where I know the error is spurious or harmless. So I like the "/e" flag, and sometimes rarely I'll redirect stderr if I know the error is expected and harmless.

I believe I understand your point of view, so I'm not trying to convince you over to mine... but I thought I'd share my thought processes so you won't think of me as a "group 3" kind of guy!

Where my POV differs is that I don't think it's useful to view "OSD /C" as an invalid command based purely on whether there's something to clear or not. The syntax is clearly correct. The issue is the system state at the time of its usage.

"CLS /C" doesn't give me an error when the window has already been cleared. For example, imagine running the following batch file:
Code:
cls /c
delay 5
cls /c
delay 5
pause
The first one clears the window, but it's in a batch file so there's no prompt displayed, nor any other text. The remaining CLS commands are just attempting to clear the same area on my screen, but it's already been cleared. If I consider "CLS" and "OSD" to simply have different areas of the screen under their control, then from that perspective, I'd expect OSD to behave the same way.

Of course, that's purely a feature-based point of view [FPOV], not a developer-based point of view [DPOV].

Now, I suspect that when the on screen display is cleared, what's really happened is that there was a transparent window that's now been destroyed or at least been removed from any ability to interact. So if you argued from a DPOV basis that it is an error to try to run "OSD /C" to clear a display that's unavailable, I would at least understand that, even if I didn't agree.

I'm still not sure I understand why it's a critical error. The on screen display is an ephemeral thing; it's not like I failed to truncate a file or write to it.

-- johnb / forbin

PS:

Yeah, the group 3 crowd thinks it would be really nice if we had a DWIM parser, but then somebody would invent the "read my mind" processor, which would reduce all of the TCC batch language to one command: DWIT (Do What I'm Thinking) --- and then we'd be stuck with either Skynet or the Matrix the first time one of those DWIT TWITs thought the wrong thing...