Bug, or by design?

[Clay Clear]

DEFSTR S
DEFINT I
'
FOR I = 1 TO 129
    S1 = S1 + "S"
NEXT
'
FOR I = 1 TO 78
    S2 = S2 + "S"
NEXT
'
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
'
END(0)

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).]

[Mel Bishop]

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


------------------

[Clay Clear]

Mel,

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>

[Clay Clear]

OK, I figured out a workaround.

IF LEN(strvar$) < 80 THEN
    FOR I = 1 TO 90 - LEN(strvar$)
        strvar$ = strvar$ + " "
    NEXT
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>

[Tom Hanlin]

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

[Alan Earnshaw]

Clay,

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$

Alan

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.
http://www.infoms.com

[Mike Luther]

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
that.

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]

[Lance Edmonds]

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.



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

[Mike Luther]

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).]

[Lance Edmonds]

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)?

Thanks!



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

[Mike Luther]

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).]

[Tom Hanlin]

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

[Jerry Mason]

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).]

[Tom Hanlin]

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

[Barry Erick]

I always controlled cursors and lines with a view screen .

------------------