princ lines not showing up

[mracad]

I am testing 2010 lisp routines in 2013. One thing I noticed is princ lines are not showing up on the command line until after the lisp routine has finished. Is there a setvar that controls this behaviour?

[Kent1Cooper]

---

@mracad wrote:

I am testing 2010 lisp routines in 2013. One thing I noticed is princ lines are not showing up on the command line until after the lisp routine has finished. Is there a setvar that controls this behaviour?

---

Just guessing here [my version is too old to test that comparison], but might it make any difference to use (prompt) instead of (princ)?  You don't indicate what you're using (princ) for, but that and (print) and (prin1) have the possibility of sending something out to a file in addition to putting it on the Command: line.  When the latter is all you really need to do, (prompt) is all you need.  I see a lot of use of (princ) for mere prompting, which doesn't seem like the "intent" of the (prin...) functions to me, even if they work to do that [or did, prior to 2013?].  I'm wondering whether maybe (prompt) has other operational differences that might make it not subject to whatever your problem is.

[mracad]

I am printing information to the command line to let users know that something is happening.

Example -

(princ "\nReading the Excel file. Please wait.")

then i read the excel file, then let them know when it is done (princ " Done.")

Some of the Excel files are huge and take 10-40 seconds to read, so a message that something is happening is important (so they don't beat on the computer thinking it's crashed or to have time to get another cup of coffee).

FYI - I have always used princ vs prin1, print or prompt. I just tried prin1, print or prompt and they all produce the same behavior.

Here is a routine to test behavior -

(defun C:TEST ()
  (princ "\nThis is a test....")
  (princ "\nThis is still a test....")
  (princ "\nEnd of test.")
  (princ)
)

returns

Command: TEST
This is still a test....
End of test.

Ahhh...... after further testing....

So, I now see that the 1st princ line is NOT showing up on the command line, unless I F2 to the Text Window. So, this is a problem in the command dialog box. If I comment out the 1st princ, then the 2nd princ doesn't show up.

Note adding a (princ " ") at the beginning helps, while (princ) doesn't help.

But, this still doesn't fix the problem with reading big Excel files. I found out I can (textscr) to see, but it is an annoying extra step for the user.

[scot-65]

Have you tried (princ "\n \nTest this? ")

Have you adjusted the display to show 3 command lines (or 4) in lieu of just 2?

???

[mracad]

Yes I have tried (princ "\n \n XX") and my command line is already set to 4 lines.

Here is a routine that demonstrates my problem - the princ text doesn't show up until after routine finishes.

Note - this test takes around 4 seconds on my computer. You might have to change the 6000000 to a larger number for more time between princ functions.

(defun C:TEST ()
  (textscr)
  (princ "\n \nStart of test...")
  (setq KK 0)
  (while (< KK 6000000)
    (setq KK (1+ KK))
  )
  (princ "done")
  (princ)
)

[pbejse]

---

@mracad wrote:

Yes I have tried (princ "\n \n XX") and my command line is already set to 4 lines.

Here is a routine that demonstrates my problem - the princ text doesn't show up until after routine finishes.

---

If you're pertaining to result/value of the expression .unless you include the print  function  inside the loop you will not see anything at all but 

Start of test...done

...

(while (< KK 6000)
(print (setq KK (1+ KK)))
)

....

HTH

[mracad]

The example had a princ statement before the loop and a statement after. The problem is the first statement isn't showing up until after the loop.

I am wanting the 1st statement to show, then run the loop and finally show the last statement.

[Hallex]

You may want to create helper function like this one:

(defun done()
(setq kk 1);;	set start here
(princ (strcat "\nStarted with: " (itoa kk)))
(while (< KK 100);;	set limit here
(princ (strcat "\nRiched at: " (itoa (setq KK (1+ KK)))))
(if (= kk 300)
(princ (strcat "\nFinished to : " (itoa kk)"\nDone")))
)
(princ)
  )

 Just change the global arguments start and finish

hth

[matus.brlit]

you probably solved this by now, but the cause might be CLIPROMPTUPDATE system variable

you want to have it set to 1, default is 0

[dbroad]

Kent had the right idea in his first post.  Use prompt instead of princ.  The reason that the first line is not printing is that it waits until a newline character is sent.  Prompt is specifically intended for the use you illustrated.  The idea with princ not immediately sending the prompt to the screen is that other princ calls could follow, effectively concatenating the lines into a single line.  The newline character is when the message is actually sent. 

(defun C:TEST ()
  ;(textscr) skip the textscr switch if you just want a delay message to appear.
  (princ "\nStart of test...\n") ;;first solution is to add a newline at the end of the message.
  (setq KK 0)
  (while (< KK 6000000)
    (setq KK (1+ KK))
  )
  (princ "done")
  (princ)
)

(defun C:TEST ()
  ;(textscr) again skip the textscr unless you need it later.
  (prompt"\Start of test...") ;this should work and is preferrable on dual screen systems.
  (setq KK 0)
  (while (< KK 6000000)
    (setq KK (1+ KK))
  )
  (princ "done")
  (princ)
)

[mracad]

Just tested - (defun C:TEST () (prompt"\Start of test...") ;this should work and is preferrable on dual screen systems. (textscr) (setq KK 0) (while (< KK 6000000) (setq KK (1+ KK)) ) (princ "done") (princ) ) Note - I put the textscr after the prompt - now the text screen shows up, but it is blank until the while statement is finished. So, I'm not seeing a change in the result. BTW, I am running G.204.0.0 AutoCAD 2013 SP2 on Windows 7 Pro SP1 64-bit

[dbroad]

Well, it looks like the behavior of print functions has taken a negative turn since I last checked this issue.  Used to be that 

(princ "\n your message \n") would be enough  or its equivalent in prompt.  Something about the system has changed recently.  So if you really need a wait message right before a non-interactive portion of your lisp, you will need a prompt that requires user input such as an alert message or a getstring message to hit return to continue.  I would avoid doing any of that unless the wait is excessive.

(defun C:TEST ()
;(prompt "Start test\n")
(alert "\nStart of test...")
(getstring "\nStart of test, hit return to begin: ")
;(textscr)
(setq KK 0)
(while (< KK 6000000) (setq KK (1+ KK)))
(princ "done")
(princ)
)

I suspect that this change occurred when autocad was split into a user interface part and the core console.

[llorden4]

Ever find a solution for this?  I'm a few years behind your post but I have the exact same need.

[mracad · Accepted solution]

No.
What I do instead is use the following -
(grtext -1 "This is one area to write.")
(grtext -2 "This is another area.")

[llorden4]

Wow, that's hard to notice but at least it's something.  Might as well flag that as your answer, not sure you'll find anything better.

[john.uhden]

My "pea brained" knowledge recalls that princ and print return the string, while prompt always returns nil.  That's why I always construct my Kosterian (ands ...) with (or <good> (prompt "bad")).

I do recall though that some (maybe all) commands don't allow interruption with princs, so they don't show up until after the command is completed.  So I think the lesson is to do your pr* stuff either before or after a command, but not during.

[llorden4]

I actually do call the Princ function prior to the the ActiveX routines but it still doesn't display until after that called routine completes.

I tried making it a called function so there would have to be a return before the ActiveX routine was called and that didn't work either.

I've tried playing with the QAFLAGS settings with no change in results.

I went so far as to put in a 50000 cycle countdown loop between the Princ and the routine and still no change.

Somebody does not want this notice to happen.

Because of a lengthy delay, I'm currently going with an Alert box to make it noticeable.  It adds another delay and pauses until there's user input, but at least the user is aware there is going to be a delay.

[john.uhden]

We need to find out who that somebody is!

It's probably either Christian Laettner or that North Korean maniac.

"Everybody hates Christian Laettner."  But I don't.  That shot he got off with 1 second left to beat Kentucky decades ago was fantastic!

A lot of people think it was Bobby Hurley, but I think that Grant Hill threw the inbounds pass.

[joselggalan]

For trying another possibility.
Enable PRINx output echo in ACAD in visualLISP.

1.- Tools -> Environment Options -> General Options
2.- In the "Diagnostics" tab, check that the option is activated.

Apologies, the images are of Autocad in Spanish.

regards..

[mracad]

Changing 'Print notification after load' only prints a message after loading a subroutine and doesn't fix the problem.

Here again is a simple program to demonstrate the problem -

(defun C:TEST ()
  (textscr)
  (princ "\n \nStart of test...")
  (setq KK 0)
  (while (< KK 6000000)
    (setq KK (1+ KK))
  )
  (princ "done")
  (princ)
)

Note - using princ, print, prin1, prompt all produce the same result. No print to screen until after the while statement is finished.