OK, here's a weird one for you. I want to print some information for the user into the Command window before I do anything else. So, I figured why not make a printf() statement the very first line of code? I suppose it should work - George does it on lines 25-35 of tekTechFileXML.il (from SourceLink). But for me, nothing is printed in the Command window. If I move the exact same statement as the first line of the procedure(), the text is printed to the Command window.
So what's my problem? Well, farther down in the procedure() a subroutine is called which uses axlEnterPath(). And the "Enter first point" prompt from axlEnterPath() comes BEFORE my printf() text, even though the printf() comes first in the code. My mind is boggled. I changed the prompt for axlEnterPath so I know it is this SKILL function that is creating the prompt which is jumping ahead of my printf() text.
Any ideas why this SKILL function can't wait it's turn? Or, better yet, how can I get the string in a printf() statement to show in the Command window if the printf() statement is the very first line of the SKILL routine?
Secondly, I want to print out a table of information which may be integers or floating point numbers. How can I do this while keeping the table nicely lined up? Here is what I've found:
%-10n - displays both number types, but pads with zeros for floating point numbers
%-10g or %g - barfs on integers
%-10L or %L - displays both number types, no padding zeros for fp, but ignores [width] field (as per page 170 of sklangref.pdf)
So, what options do I have? I want similar to %-10n output, but without zero padding. %-10g would seem to be the right choice. I've used %g in other SKILL programs and it gracefully handled both integer and fp numbers - any ideas why it isn't with integers for me now?
Glad to have been some help, and that you now have the max Lint score.
I would point out to all that SKILL Lint is a useful tool to measure the "goodness" of code, but it is entirely possible to write "bad" code which achieves a score of 100. And the converse is true also, that very good code may receive a score of less than 100 due to some nuances in the way that things are measured - sometimes there can be tricks to improve the score.