Program ends without warnings in small screen

[Petr]

Code: QB64: [Select]

1. V& = _NEWIMAGE(10, 10, 256)
2. _DEST V&
3. SCREEN V&
4. DIM colors(15) AS _UNSIGNED LONG
5. FOR a = 31 TO 16 STEP -1 '15 colors
6.     PSET (1, 1), a
7.     _SOURCE V&
8.     B& = POINT(1, 1)
9.     colors(b) = _RGB32(_RED32(B&), _GREEN32(B&), _BLUE32(B&))
10.     _PALETTECOLOR b, colors(b)
11.     PRINT colors(b), B&
12.     b = b + 1
13.     SLEEP
14. NEXT a
15. _FREEIMAGE V&
16.  

soultion is bigger _newimage in begin. Is this known bug, if this is bug?

next bug:
program print nothing - but resolution is enough:

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(19, 22, 256)
2. PRINT "A"
3. SLEEP
4.  

[Petr]

I found, in first souce do it PRINT, with newimage 20x20 program starts, but as show second source, A is not printed.

[bplus]

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(19, 22, 256)
2. _PRINTSTRING (1, 1), "B+"
3. SLEEP 'hit a key twice to close window

[Petr]

Hi Bplus. Yes, but try use it in SCREEN 0. For example if you print to virtual screen, you need not graphic screen, but _PRINTSCREEN need it.

[bplus]

OK I got another idea, be right back!

[bplus]

Didn't work.

Isn't 256 a graphics screen? specially from _NEWIMAGE

[Petr]

for _PRINTSTRING you need grphic screen, for _PUTIMAGE too. In case, you need print to small text screen, with PRINT, it works not. I ask why :-D Next ask is, if PRINT fail, why first program is quit. This muss be something in C level. Maybe textscreen need headers and footers, I do not know...

[Petr]

I do next experiments, so it works not in graphic mode only. In text mode it works.

[Cobalt]

so is your image(window) a text area or a graphical area? if you want text you need to use 0(zero) not 256. your first example flat out crashes on my computer. probably cause windows can not fit the title bar in a space 10 pixels wide.
if you want a text area 10 characters square then you need to use _newimage(10,10,0)

otherwise I'm going to guess that the area is just too small for the OS to use.

[FellippeHeitor]

@Petr:
Your first example interestingly doesn't crash on my Windows XP machine. It probably crashes on other systems for the reasons already outlined by Cobalt above: your OS has trouble creating a window that small.

"Is this a known bug, if this is a bug", you ask? I wouldn't call it a bug especially since it works as expected on my Windows XP VM, but it definitely doesn't sound like something productive or practical. Why would you have a program screen that small? It looks like malpractice.

For the next "bug" in your original post: You create a screen that's small enough to fit a character, but then you use PRINT, which will create a new line immediately after printing. Then what happens to your expected "A" character? It gets scrolled up. It wouldn't happen if you did this:

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(19, 22, 256)
2. PRINT "A";
3. SLEEP
4.  

Notice the semicolon (;) after the PRINT line? That'll keep the cursor from going down and creating a new blank line.

About _PRINTSTRING, it does work well on text screens but instead of pixel coordinates it takes character positions. It becomes a macro to replace a LOCATE and a PRINT:

Code: QB64: [Select]

1. _PRINTSTRING (10, 12), "Text"
2. 'is the same as:
3. LOCATE 12, 10
4. PRINT "Text"

Just notice that row/column parameters are swapped (LOCATE takes a row and a column, while _PRINTSTRING takes x, y coordinates).

[Petr]

Jesus Maria, how could me escape? How could I not have noticed? Semicolon! This can not be true. :-D Thank you very much. With this practice - yeah, it's probably a stupid practice, today am i do one stupid thing and it's not going and it's not going again...  and it's still not going.... I have weaker days ... last twenty years ....: D