quietly use ado which insists in noisily displaying

[diana gold]

I'm hoping to get advice on how to silence an ado which I cannot edit.

log using mylog.log, replace
di "Started at $S_TIME."
foreach task of local tentasks {
qui do task.do
* each task.do manipulates datasets
* using a loop which calls ~200 times the command getdataset,
* which is a user-written ado from my company 
di "...`task' completed at $S_TIME."
 }
di "All tasks completed."

Even though I'm calling the dofiles of each task quietly, the getdataset command is somehow overwritting the quietly and displaying a long disclaimer for every dataset opened. My best guess is that this was done intentionally within the ado, for the same disclaimer is displayed even if I just type "quietly getdataset, options".

Thus, instead of having a log with just a few lines of timestamps, I end up with a flood of the same disclaimer printed 10*200 times. I would like to circumvent this but I cannot edit the getdataset ado. Any suggestions?

Thanks for any advice!

[Clyde Schechter]

I can't reproduce your problem as I understand it from your description.:

. clear*

. 
. capture program drop junk

. program define junk
  1.         noisily display "hello, world"
  2.         exit
  3. end

. 
. forvalues i = 1/5 {
  2.         quietly junk
  3. }

. 
. 
.

I think you need to show exact code, not pseudo-code.

[William Lisowski]

Welcome to Statalist.

To Clyde's advice let me add that

viewsource getdataset.ado

should open getdataset.ado in the Stata Viewer window, where you can see the actual command in the ado that is creating the message.

Added in edit: Your psuedo-code includes

foreach task of local tentasks {
qui do task.do

which I hope in your real code is

foreach task of local tentasks {
qui do `task'.do

[diana gold]

Thank you for the welcome, William! Though this is my first post, I've been using the forum for long - it's just that I normally find what I'm looking for already answered
To your point, yes, I do have the quote marks and the tasks do run.

Following Clyde's advice, I did viewsource getdataset.ado and here's what it looks like:

program define getdataset, rclass 
 _disclaimer
 * manythings
end

program define _disclaimer
  disp in w _col(2) "annoying disclaimer"
end

[Clyde Schechter]

Very interesting. I can reproduce your problem with this example. I also note that if I edit out the -in w- from the -disp- command in program _disclaimer, then it obeys the quietly directive.

. clear*

. 
. program define getdataset, rclass 
  1.  _disclaimer
  2.  * manythings
. end

. 
. program define _disclaimer
  1.   disp in w _col(2) "annoying disclaimer"
  2. end

. 
. forvalues i = 1/3 {
  2.         getdataset
  3. }
 annoying disclaimer
 annoying disclaimer
 annoying disclaimer

. 
. forvalues i = 1/3 {
  2.         quietly getdataset
  3. }
 annoying disclaimer
 annoying disclaimer
 annoying disclaimer

.

. 
. clear*



. 
. program define getdataset, rclass 
  1.  _disclaimer
  2.  * manythings
. end

. 
. program define _disclaimer
  1.   disp  _col(2) "annoying disclaimer"
  2. end

. 
. forvalues i = 1/3 {
  2.         getdataset
  3. }
 annoying disclaimer
 annoying disclaimer
 annoying disclaimer

. 
. forvalues i = 1/3 {
  2.         quietly getdataset
  3. }

.

I have no idea why that should be. It seems like a bug. The -in w- syntax is archaic and presently undocumented, and I don't even remember what it was for, except that it had the effect of displaying text in white, as opposed to the default color which, at the time, was, if I recall correctly, green.

I am always reluctant to advise people to edit the code in programs that they or I have not written ourselves. But given that -in w- is irrelevant in modern Stata syntax, I am pretty confident that if you edit out the -in w- in getdataset.ado you will resolve your problem and not introduce any untoward side effects.

[daniel klein]

display in w

is short for

display in white

which is equivalent to

display as input

which, according to [P] display

should never be used unless you are creating a special effect. as input (white on a black
background) is reserved for what the user types, and the output your program is producing is by
definition not being typed by the user. Stata uses as input when it displays what the user types.

I have no clear opinion on whether this is a bug or not. I tend to call this behavior a bug.

Best
Daniel

[diana gold]

My best guess is that the people who created it did it intentionally - they wanted this disclaimer to always be displayed and found the bug to force this behavior.

Thank you Daniel and Clyde for the detective work!

[diana gold]

Follow-up: by prefacing the use of getdataset (the company ado which I cannot edit) with capture, it suppresses the annoying disclaimer. Plus a "if error, stop", it has the exact behavior I was looking for.

Thank you all for the great insights!

[Clyde Schechter]

Um, I wouldn't do that if I were you. It also means that if -getdataset- encounters an error or somehow runs amok, the error message and halt that would otherwise occur are suppressed and your do-file will blunder on using the newly created garbage in to create yet more garbage out.

This is safer:

capture getdataset // AND THE REST OF THE COMMAND IF THERE IS ANY
if c(rc) != 0 {
    display as error "-getdataset- detected an error"
    error `c(rc)'
}

That will suppress output, but you will still be notified and forced to confront any problems encountered.

If you know what specific error messages -getdataset- is capable of throwing, and if some of them can genuinely be ignored, then you could modify the -if c(rc) != 0- to -if inlist(c(rc), 0, ...)- where you replace ... by a comma-separated list of ignorable error codes.

[diana gold]

Indeed, very important!
Thank you, Clyde.