No announcement yet.

Bug, or by design?

  • Filter
  • Time
  • Show
Clear All
new posts

  • Bug, or by design?

    FOR I = 1 TO 129
        S1 = S1 + "S"
    FOR I = 1 TO 78
        S2 = S2 + "S"
    SCREEN 0, 1
    COLOR 9, 0, 0
    PRINT "Current file: ";
    COLOR 12, 0, 0
    PRINT S1
    PRINT ""
    COLOR 9, 0, 0
    PRINT "Current file: ";
    COLOR 12, 0, 0
    PRINT S2
    In the above code, S1 is correctly appended to the end of its
    "Current file: ", and the line wraps to the next line.

    However, S2 is printed on the line AFTER its "Current file: ".

    I discovered this phenomenon when I was using my wrapper EXE
    to decode MP3's, and one of the MP3 path names was 78 chars
    in length.

    MY fix was quite easy - use ANSI coding for the colors, using
    STDOUT. I always have ANSI.SYS loaded, because of my DOS BBS.
    However, other programmers might not be so fortunate.

    This test code, and my actual EXE, are run from a full screen DOS box.

    Clay C. Clear

    mailto:[email protected][email protected]</A>

    [This message has been edited by Clay Clear (edited August 06, 2002).]

  • #2
    Try putting a semi-colon after "print s1". i.e. "print;s1;". This
    prevents the program from assuming a Cr/Lf.

    There are no atheists in a fox hole or the morning of a math test.
    If my flag offends you, I'll help you pack.


    • #3

      Thanks, tried it, made no difference. You're a lot more of a
      PB/DOSer than I am, so if you have any other ideas, I'm all ears!

      Thanks again.

      Clay C. Clear

      mailto:[email protected][email protected]</A>


      • #4
        OK, I figured out a workaround.

        IF LEN(strvar$) < 80 THEN
            FOR I = 1 TO 90 - LEN(strvar$)
                strvar$ = strvar$ + " "
        END IF
        This FORCES the string appended to "Current file: " to always be
        greater than 80 chars (one screen line length in text mode). And, since
        my two production apps use non-solid background colors, the spaces
        appended to strvar$ will be invisibile.

        Obviously, my production code will use "FOR I = 1 TO 81 - LEN(strvar$)".
        No use adding more white space than necessary. Apparently, the
        important thing is that the whole line either all fit on one
        display line, OR, it be greater than the length of one display line, in
        chars, in order for the strings to be properly appended, and in the latter
        case, to have linewrapping.

        Clay C. Clear

        mailto:[email protected][email protected]</A>


        • #5
          I see QB does the same thing, so it's presumably "by design". Some oddball
          quirk of print field handling, I guess.

          Tom Hanlin
          PowerBASIC Staff


          • #6

            If I recall correctly, here are the rules PRINT uses:

            If the cursor is on column 1, the variable is printed. If it is longer than 80 characters, the text will wrap to the next line.
            If the cursor is to the right of column 1, and the variable to be printed will fit on the current line, it is printed on the current line.
            If the cursor is to the right of column 1, and the variable to be printed is longer than the space available on the current line, PRINT issues a CR/LF and prints the variable on a new line. Again, if the data is longer than 80 characters, it will wrap to the next line.

            I believe the only way to ensure two strings will always be printed end to end is to combine them:

            PRINT S1$ + S2$

            P.S. The FOR loops are a bit slow compared to the built-in STRING function:

            S1 = STRING(129, "S")
            S2 = STRING(78, "S")

            Alan C. Earnshaw
            Information Management Systems, Inc.
            Alan C. Earnshaw
            Information Management Systems, Inc.


            • #7
              An oblique somewhat related buglet I've found but seems not to be
              able to get 'demonstrated' appropriately is that a request to return
              the position of the cursor after one of these 79/80 character string
              deals differs between running the program in the IDE, and IDE compiled
              code, as opposed to PBC hard compiled executables when running in the
              debug mode with debug code turned on.

              Trying to make decisions on what to do with string concantenations
              based on where the cursor is supposed to be in user-I/O dynamic variable
              length operations, at least for me, isn't stable for 79/80th column
              character counts from the cursor return positioned.

              It's related to a call for POS(0) and only shows up in these odd
              line wrap or deals where the string to be printed has a trailing
              semi-colon that is supposed to leave the cursor were it was without
              wrap. I'll, for example, want to check the cursor position to
              decide what to do with a follow on single character to add to that
              line of print, but the return in the debugging operation leaves the
              cursor position corrupt on the screen, but not necessarily in the
              final executable! Or .. the reverse!

              Column count based on cursor position found works fine other than

              I've only seen it in CALLS to SUB's, the complexity of which seems
              to be such that demonstrating it, to date, hasn't been acknowledged.
              It's been many months since I stumbled on this one and turned it
              in and going back for through this at this time would be a huge
              mess to even attempt.

              IIRC the work around was to re-write everything so that the length
              was known before printing, rather than determine where the cursor
              was and then try to figure out what could be added or not, in
              realtion to the 79/80th columns.

              Mike Luther
              [email protected]
              Mike Luther
              [email protected]


              • #8
                Example code...!?

                Mike, we need to see some example code that demonstrates the problem...

                Afterall, the section of the RTL that deals with the cursor handling does not vary depending on whether you are compiling from the IDE or command-line, or running in the IDE... so how such a problem can possibly occur is unclear.

                PowerBASIC Support
                mailto:[email protected][email protected]</A>
                mailto:[email protected]


                • #9
                  Lance ..

                  I submitted it. Months ago. It was in the submission work sent
                  in to more than one person there over the date range of August 16-17,
                  2001, per my records here. The indeterminate range is there because
                  although I'm in Texas and in the CDT time zone, the entire system
                  here has to run on GMT! Thus sometimes arguments arise over what
                  was done on a given day because of that!

                  Absolutely no word on what was ever *DONE* with it was ever sent
                  back to me at all from anyone a PB that was ever received here. Not
                  one word. It is now so far back in the past I simply cannot go back
                  to it .. There have been ten subsequent modifications in the entire
                  code profile for that one INCLUDE file that involves the SUB where it
                  was discovered since that date. As well, a complete re-compilation
                  of each and every single executable and library module in the entire
                  111 executables and libraries CAREFULLY entrusted to PowerBASIC
                  with a HUGE amount of pride in PB, was done on September 3, 2001.

                  That pride in your product is even more entrenched today Lance than
                  it was then.

                  You just sometimes SOLVE problems, Lance, by figuring ways not to throw
                  errors even when you sometimes cannot figure out how they are thrown. You
                  simply plow around them. No code is perfect, even "Hello World", if
                  one no speak English!

                  I'd have been happy to do whatever was necessary to display the stuff
                  for anyone who could load and run the development source to do it. But
                  the full code which was involved here which was running then and is
                  still running now to display things, won't even run without close to
                  650K free memory for most of what is needed. My entire standard memory
                  model in which to work has a minimum of 682K main memory free. I have
                  work which has grown to need have close to all that to even begin to
                  run in the debugging mode! And the IDE and PBD are still so far off
                  line for the actual operation of the code as to what is being shown,
                  that it is virtually impossible to do any debugging without setting
                  old-fashioned hard break routines to freeze operations for much
                  of what I must do to even illustrate anything for anyone there.

                  Please sweet Lord, oh my Lord, may the IDE in the NEXT version of
                  PowerBASIC for DOS go back to plowing the correct row without the
                  mule cockeyed side stepping in front of the Go-Devil!

                  And then we have to go through this excercise about EMS, XMS, compliance ..
                  what constitutes a standard under which PB can be expected to work.

                  I've asked this before. I'll ask it again!

                  What *IS* the EXACT compliance model which we must use with PB to
                  determine must be present in order to submit and clear all this stuff?

                  WIN-XP? Chuckle.

                  It's obvious that I'll likely never be able to submit what is needed to
                  show you many things seen here. Is there ANYTHING available to you
                  folks at all in the WIN world, which will even come close to letting
                  anyone do what can be done with PB in DOS under OS/2? At least I
                  have the satisfaction of knowing that whatever I work with in OS/2
                  will be reasonably SOLID and STABLE -- all the way from code that
                  worked in 1984 terms, through at least December of 2006 at this point!

                  I wonder where all of this will be in other operating system platforms
                  by December of 2006?

                  You folks, to the best of my knowledge, have no way at all to reproduce
                  much of any of this without running OS/2 and DOS-VDM's. I think, at
                  one time, long ago and far away, that might have been a possibility,
                  but I doubt it at this point. And you know, I don't blame you folks
                  one bit for what you are doing! You'd corporately die, in my opinion,
                  without doing exactly what you are doing and doing right!

                  But your development platform, as WIN moves forward, for DOS which is
                  still terribly important in terms of embedded systems and so on, is,
                  as I see it, getting more and more crowded along your shoulders.

                  I don't see how anyone is going to go forward with PB for DOS with
                  WIN-XP and so on only providing 280-300K in main memory and so on
                  in the future, but then, I'm no guru at any of this. Maybe that
                  constitutes the standard? I doubt it!

                  Yes, I fully admit that you cannot fix what you can't see. And I'm not
                  complaining! I'm genuinely concerned how things are going to work
                  out for all of us together in this ship of dedicated souls as this
                  whole Big Boy's arguement gets even bigger soon.

                  All I am trying to do is alert people who are possibly running outside
                  the boundaries of what you folks can't see, with what you have to
                  work with for development, as to what they MIGHT see and how to work
                  around it when they hit it!

                  No, I am *NOT* complaining! Heck, PB is one of the most brilliantly
                  conceived and exectuted development tool sets that *ANYONE* can ask
                  for. But when we send you something, if you can't run it in the
                  envelope that we have which produces it, regardless of where the
                  problem is that throws the error or corrupts the matrix, we'll never
                  see it, will we?

                  The time to have asked about what was shown was in August of the
                  year of 2001, Lance. A whole year has passed since them, my very
                  special and dedicated friend, for whom I have a very great respect
                  and whom is a far smarter puppy than I will ever be.

                  But Mikey Dog does try, he really does! I did what was suggested
                  by everyone back a year ago. Din' work. I solved the problem by not
                  stepping outside the rows like a cockeyed mule pulling a Go-Devil
                  in a Texas cotton patch full of Boll Weevils, turnin' stubble for
                  next year's crop, wondering what he ought to step in next when the
                  row runs out slaunchwize, suh!

                  Mike Luther
                  [email protected]

                  [This message has been edited by Mike Luther (edited August 13, 2002).]
                  Mike Luther
                  [email protected]


                  • #10
                    Mike, the [large] files you submitted on 15/16th Aug 2001 pertained to an Error 611 when you ran under OS/2. On the 6-9th August 2001 we discussed an IDE line sync issue when debugging code.

                    As far as I can see, there is not a single mention of a problem with text positioning or wrapping at column 79/80 as you mention [far] above.

                    Sorry! Would you care to submit code that does clearly demonstrate that, when running in plain DOS or under Windows (as opposed to an OS/2 VDM session)?


                    PowerBASIC Support
                    mailto:[email protected][email protected]</A>
                    mailto:[email protected]


                    • #11
                      Lance ..

                      I wish I could submit it. Not only is the entire arena long gone
                      over what produced it, plow-around, but I have absolutely no way
                      to run, debug, make any use of PowerBASIC whatsoever for for any
                      development purposes outside of OS/2 DOS-VDM's.

                      It was thought to be related to a CHR$(7); type issue and per my recall
                      the suggestion was to look at the interpretive printing side of things
                      as to all this. I did. But that didn't fix the issues in the debugging
                      side of it all, if my memory is correct.

                      From the Email inbound to you'all, I referenced this earlier possible
                      piece to the puzzle as:

                      As well as what was sent in to you over the CHR$(7); deal, I have *FINALLY*
                      been able to freeze one of this 600 series errors which illustrates exactly
                      what David complains about in his post about the problems about IF / THEN
                      issues. The *DO* exist. They are a PEST to find.
                      This is part of the, ".. what was sent to you over the CHR$(7); deal",
                      in that text quote from the 611 error submission. It is an issue, wherein
                      the way that screen I/O is printed as to how it should be printed, works
                      one way in compiled code. But it doesn't ALWAYS work as expected when you
                      go to debug it in the IDE .. or .. the PBD! Most of the time the IDE does
                      what you would expect for the way things are called for as to how it should
                      do this.

                      But .. when the code gets VERY large, here we go again, with the line sync
                      all bawled up, the IDE's handling of 'cursor position' fails in regard to
                      the 80th character, which was the implication I got from this thread as
                      it developed.

                      I've seen this 'in spades.'

                      Further, when the code becomes so large that you can no longer run it at
                      all in the IDE, like my work mostly is, then the PBD doesn't handle it
                      'correctly' either! The operational results of the compiled code with
                      the debug option on are DIFFERENT than those without it!

                      The erruption of the 611 error problem reported was right in this same
                      area of color changes, POS(0) reporting, the whole works, as was submitted.
                      That's why that sentence above started with the phrase that was used!

                      So, for whatever, I've ALREADY submitted all that I will ever be able to
                      submit for test, sadly. I found this one in a very specific error throw
                      in my PBU module INSCREEN submitted to you olks which clearly could and
                      did show it at that point in the product development cycle.

                      I simply cannot go back and do all the hundreds of hours of work all over
                      yet again to do any better than I did .. much as I want to. I held the
                      code in focus for as long as I possibly could .. then was forced to
                      move onward.

                      Malcomb Forbes was said to have always been caught, at times, looking far
                      off into the distance, as if in a trance. Once asked about it, he is
                      reported to have said that once upon a time, he was on the ferry in
                      Manhattan, and a treasure of a girl dressed in white ran down the dock
                      trying to get on the ferry. The horn honked. The ferry pulled away from
                      the dock. That priceless treasure was left standing all alone on the dock
                      as the ferry sailed away as he watched her there. He is said to have never
                      been able to forget her, what she looked like and what it was like to have
                      her just vanish into the distance, never to be seen again.

                      All I can do now is alert this user that there IS an issue around the 80th
                      character, in which what one expects from cursor location reporting is not,
                      necessarily what one gets in the IDE, may be not be the same at all in
                      compiled programs, and different in the PBD as well, for very large
                      projects with SUB's that have these functions built into them.

                      If you hit it, try to figure out what to print before you print it and
                      not to get caught trying to let the development scenario tell you
                      what is going on at the 80th column.

                      And .. if someone else finds this and can call it out so that you folks
                      can see it, will you PLEASE post it back to Empire Central? They
                      cannot fix what they cannot see demonstrated.

                      Mike Luther
                      [email protected]

                      [This message has been edited by Mike Luther (edited August 13, 2002).]
                      Mike Luther
                      [email protected]


                      • #12
                        Mike, we appreciate that you saw something. Whether it was a UFO or
                        swamp gas is harder to define. Given your unusual operating environment
                        and that you can't or won't duplicate the problem(s) yourself, though,
                        what you're reporting here is the foggiest sort of hearsay. If and when
                        you can show us something concrete, we will be awfully glad to see it.
                        In the meantime, please refrain from telling ghost stories. To the best
                        of our knowledge, the compiler isn't haunted.

                        Tom Hanlin
                        PowerBASIC Staff


                        • #13
                          On the other hand, Tom, this IS a Peer Support Forum. Meaning, if
                          we users can help each other out with a work-around to common problems,
                          like the famous insert-a-$SEGMENT fix, or Mike's work-around above, we
                          aren't required to justify this to anybody at PowerBasic. It works, and
                          that is all most of us need to know about such fixes.

                          [This message has been edited by Jerry Mason (edited August 15, 2002).]


                          • #14
                            Adding code to your program that "seems to" fix problems that you
                            haven't identified and don't understand is a matter of superstition,
                            not prudent design. I can't stop anyone from doing it, but I won't
                            encourage it as a practical programming principle.

                            Tom Hanlin
                            PowerBASIC Staff


                            • #15
                              I always controlled cursors and lines with a view screen .