Talk:VIEW PRINT - QB64 Wiki

Talk:VIEW PRINT

From QB64 Wiki

Jump to: navigation, search

<stylin> regarding this item: "A non-parameter VIEW PRINT statement can also disable the viewport when finished.", I think the "If topRow% and bottomRow% are not specified, the text viewport is defined to be the entire screen." item is sufficient to explain the situation. That is, it makes sense to think about the text viewport as always being "enabled", and by default it is set to encompass the entire screen. There doesn't seem to be a need for that particular addition.


<stylin> along the above lines, perhaps the "disable the viewport" comment in the example could be changed to "reset the text viewport", with another PRINT statement following to show that the print cursor location is moved to the top corner of the screen.

This issue is one of the reasons I reverted the page! To end a viewport, VIEW PRINT can be used alone. It would NOT be the same as saying that the viewport is the entire screen. If you want to explain both in one description then do that. That was why Galleon preferred my example to your's. But realistically both examples were similar in what they did.

What MIGHT make sense to YOU or ME is irrelevant! The Wiki should AT LEAST describe things accurately and completely. People should not have to assume anything.

ALSO could you please get rid of that "error is thrown" stuff. How about "error 5 occurs"?


<stylin> I fail to see the difference. "VIEW PRINT 1 to xx", where xx is the number of text rows, behaves the exact same as "VIEW PRINT", and in fact, that is exactly how the functionality is implemented in the runtime source, so it is indeed more accurate to say that the text viewport is always enabled and is by default the entire screen.


<stylin> Regarding the run-time errors, "error 5 occurs" is pretty cryptic, IMO. Using a textual description is much better than a "magic number".

No the "illegal function call is fine. I just don't like "thrown" as it is unprofessional.


As to VIEW PRINT the numbers are not number of lines. The values are the ROW coordinates used. What is the BIG deal about adding clarity? I may revert the LTRIM$ and RTRIM$ pages because the examples are silly and you removed any mention of how they work with numbers converted to strings. You also removed the STR$ link. Why? Was it hurting anything?


<stylin> I'm aware of what the parameters to VIEW PRINT represent; it just so happens that because they are 1-based, 1 is the top-most row, and "the total number of rows in a particular screen mode" is the bottom-most row.


<stylin> Regarding "throw", it is in fact one of the "professional" terms used to describe error events. It's mostly used when talking about exceptions (which are "caught"), but because run-time errors in QB64 behave similar to exceptions (that is, they propogate out of procedures and halt the program unless "caught" or "trapped" by the user) it seems appropriate.


<stylin> Regarding the LTRIM$/RTRIM$ examples, they show what happens when the input value both needs and does not need trimmed. The RTRIM$ examples append a character to show that the trailing spaces have indeed been removed, which wouldn't be visible otherwise. You are free to adjust the examples how you see fit. Keep in mind that the blueprint is the primary priority right now, so you are just making things worse by reverting updated pages.

"Thrown" is a programmer's word for it. Not something easily understood by new people.

If the "blueprint is the primary priority right now" then why are you continuing to remove content? THAT IS MY PRIORITY! Continue to remove content, then I will revert anything you touch! That includes Aoeu's stuff too. So far he has been pretty reasonable, but you are IMPOSSIBLE! I cannot change your mind about anything talking, so I'll just do it by ACTING. I already re-added stuff to the VIEW PRINT page, so cut me some slack!

I DO NOT INTEND TO HAVE TO REDO DESCRIPTIONS because you think parts are not necessary or KEYWORD LINKS would be too long!


<stylin> Against my better judgment, I've actually been adding description items, not removing them, even though some of the new content may reiterate existing content -- I can't remove or change anything, so I add, according to Galleon's rules. If you really think STR$ should be placed in the "see also" section of LTRIM$, then just take 2 seconds and add it. Perhaps you should should rearrange your priorities to match up with the other contributors' priorities, that is, creating a wiki that's well-written. IMO, well-written means not having unnecessary information to clutter the page; the STR$ page already has a link to LTRIM$, which is fine, but LTRIM$ has nothing to do with STR$, IMHO.