OSD close

[TimButterfield]

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

 

[rconn]

WAD -- OSD isn't really intended for multiple windows. If you do want multiple OSD windows (why do you?) you can only close them with the timeouts.

 

[TimButterfield]

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

 

[Frank]

Hello Tim,
I'm interested in your ping/vpn monitor. If possible, please accord me an example. Thanks.

 

[TimButterfield]

I'm interested in your ping/vpn monitor. If possible, please accord me an example.

Hi, Frank.

I posted it here: http://jpsoft.com/forums/threads/pingvpnmonitor.4603/

Tim

 

[rconn]

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.

 

[TimButterfield]

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]

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.

 

[vefatica]

Tim, I wrote a more elaborate OSD plugin. I haven't looked at it or used it in a while. If you want to try it, it's at ftp://lucky.syr.edu/4plugins/osd.dll.

 

[Frank]

Nice script.
Perhaps this is interesting for someone: pinginfoview

 

[TimButterfield]

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