OSD close

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
May 20, 2008
420
2
#1
I was experimenting with different OSD text displays and discovered I could not close all of them if there were multiples. Here is the sequence:

osd /n /top /left /time=60 Test 1
osd /n /top /hcenter /time=60 Test 2
osd /c

As the help mentions, the OSD /C only closes the last (current) one. At that point, isn't the previous one now current? But, repeating OSD /C shows the usage and does not close it. I like that we can show multiple OSD texts, but how can we close all of them without waiting for the timeout?

It would be nice if we could have osd /id=# to identify a specific osd and a matching /c# to close that one or a /ca to close all.

Tim
 
May 20, 2008
420
2
#3
It was something I found while creating a ping/vpn monitor batch file to run in the background. I was checking the appearance of difference fonts, but then couldn't close them all. The documentation doesn't cover the possibility and the command+params didn't handle it. I wanted to mention the unspecified behavior. Now that I know about, if it worked, I would consider it the desktop equivalent of a factory tower light (http://signaworks.com/signaworks.com/tower/?sts) that could have multiple, simulataneous alert status indicators. I just happen to be working on code for using the tower light right now and could see the use of OSD in a status monitor batch file provided it worked with multiples.
Tim
 
#4
Hello Tim,
I'm interested in your ping/vpn monitor. If possible, please accord me an example. Thanks.
 

rconn

Administrator
Staff member
May 14, 2008
10,100
85
#6
It was something I found while creating a ping/vpn monitor batch file to run in the background. I was checking the appearance of difference fonts, but then couldn't close them all. The documentation doesn't cover the possibility and the command+params didn't handle it. I wanted to mention the unspecified behavior.
TCC launches a new thread to handle each OSD request. It keeps track of the last one (so the /C can work), but trying to track n OSD instances would require a significant syntax (and code) change. If you really want it, put it on the Feedback forum and see if gets any support.
 
May 20, 2008
420
2
#7
Okay. I'll think about that. In the meantime, perhaps issuing an OSD command should automatically do an "OSD /c 2> nul" first so multiple threads are not created. That would eliminate the orphan issue.

Tim
 

Charles Dye

Super Moderator
Staff member
May 20, 2008
3,383
39
Albuquerque, NM
prospero.unm.edu
#8
TCC launches a new thread to handle each OSD request. It keeps track of the last one (so the /C can work), but trying to track n OSD instances would require a significant syntax (and code) change. If you really want it, put it on the Feedback forum and see if gets any support.
Perhaps, rather than keeping track of the last n invocations, TCC could simply report the handle (address? thread id?) of the last one via internal variable, in some format understandable by OSD /C. Then anyone who really want to can be responsible for storing earlier instances himself.
 
May 20, 2008
420
2
#11
Sorry for the delay in responding. A few weeks of excessive overtime got in the way. Running the ping batch file used a constant 1-1.5% of cpu. So, I rewrote it in C# so it averages near 0% cpu. I still like the idea of using OSD, but not for this particular application where it runs all of the time. Thanks for the link, Vince. I'll consider that the next time I need it.

Tim