IF A <> 0 AND B <> 0 THEN....    <--- Never any issues with this, and it's actually quite readable and easy to understand.

IF A * B THEN....   <--- This might run faster and be shorter code, but there's always the chance that SOMETIME, it's going to overflow.  And, I know myself -- when it does, something like this would drive me absolutely insane trying to find it and debug it.  Because, after all, it works perfectly well all the rest of the time!

I totally agree, since unsigned variables are possible in QB64.
QB4.5 didn't allow unsigned variables, so it was never an issue back in those days...  (I'm just an old style SCREEN 0 type of programmer.)

Now, with that caveat said, I'd also like to say, "I don't have a clue what variable TYPE an IF statement actually uses for internal calculations."  When we do A * B, is the intermittent result that we compare against 0 an _UNSIGNED _BYTE like the two initial variable types?  Is it a LONG?  A _FLOAT??

That is a very good question...
It seems like it could cause occasional "unexpected results" depending on what the answer really is.
Back in QB4.5, I'm pretty sure that all internal functions like VAL(num$) would ALWAYS be interpreted as a SIGNED FLOAT.

And since it sounds like you just want to grab a segment of a screen, why don't you give these little routines a quick try:

Code: QB64: [Select]

1. SCREEN 0
2. REDIM Array(0) AS STRING
3.  
4. FOR i = 1 TO 25 'draw an original screen
5.     COLOR 4
6.     LOCATE i, 1: PRINT i;
7.     COLOR 15
8.     LOCATE i, i: PRINT i;
9. NEXT
10.  
11. ScreenSave 0, 10, 10, 20, 20, Array() 'save a portion of it
12. SLEEP
13. CLS 'clear it
14. SLEEP
15. ScreenRestore 0, 10, 10, Array() 'restore it exactly where it was
16. SLEEP
17. CLS 'clear it
18. SCREEN _NEWIMAGE(120, 50, 0) 'and make a larger screen
19. SLEEP
20. ScreenRestore 0, 10, 10, Array() 'restore it to that larger screen
21. SLEEP
22. ScreenRestore 0, 45, 7, Array() 'And to showcase that we can move this text elsewhere...
23.  
24.  
25. SUB ScreenSave (Image, X1, Y1, X2, Y2, Array() AS STRING) 'coordinates of the screen to copy
26.     $CHECKING:OFF
27.     IF X1 > X2 THEN SWAP X1, X2 'go from left to right, not right to left
28.     IF Y1 > Y2 THEN SWAP Y1, Y2 'and from top yo bottom, not bottom to top
29.  
30.     DIM M AS _MEM
31.     M = _MEMIMAGE(Image) '
32.     E = ConvertOffset(M.ELEMENTSIZE) 'How many bytes per pixel are in memory?  Screen 0 uses 2 bytes, 256 color screens use 1, 32-bit screens use 4
33.  
34.     Length = (X2 - X1 + 1) * E 'Width of stored area * bytes per pixel
35.     Rows = (Y2 - Y1 + 1) 'Number of rows to store
36.  
37.     REDIM Array(1 TO Rows) AS STRING 'Array to store the data
38.     FOR i = 1 TO Rows
39.         Array(i) = SPACE$(Length) 'Set the array to the proper length to store each row of data
40.     NEXT
41.  
42.     count = 0
43.     IF E = 2 THEN
44.         FOR y = Y1 - 1 TO Y2 - 1 'for text screens, we need to change the coordinates from using text locations
45.             '                     (starting at 1,1), and convert them to memory locations starting at 0,0.
46.             count = count + 1
47.             _MEMGET M, M.OFFSET + (y * _WIDTH + X1) * E, Array(count) 'get the rows into memory starting from the proper offset
48.         NEXT
49.     ELSE
50.         FOR y = Y1 TO Y2
51.             count = count + 1
52.             _MEMGET M, M.OFFSET + (y * _WIDTH + X1) * E, Array(count) 'get the rows into memory starting from the proper offset
53.         NEXT
54.     END IF
55.     _MEMFREE M 'Free the temp mem block
56.     $CHECKING:ON
57. END SUB
58.  
59. SUB ScreenRestore (Image, X1, Y1, Array() AS STRING) 'coordinates of the screen to copy
60.     $CHECKING:OFF
61.     y2 = Y1 + UBOUND(Array) - 1
62.  
63.     DIM M AS _MEM
64.     M = _MEMIMAGE(Image) '
65.     E = ConvertOffset(M.ELEMENTSIZE) 'How many bytes per pixel are in memory?  Screen 0 uses 2 bytes, 256 color screens use 1, 32-bit screens use 4
66.  
67.     length = LEN(Array(1))
68.     Rows = (y2 - Y1 + 1) 'Number of rows to store
69.  
70.     count = 0
71.     IF E = 2 THEN
72.         FOR y = Y1 - 1 TO y2 - 1
73.             count = count + 1
74.             _MEMPUT M, M.OFFSET + (y * _WIDTH + X1) * E, Array(count) 'get the rows into memory starting from the proper offset
75.         NEXT
76.     ELSE
77.         FOR y = Y1 TO y2
78.             count = count + 1
79.             _MEMPUT M, M.OFFSET + (y * _WIDTH + X1) * E, Array(count) 'get the rows into memory starting from the proper offset
80.         NEXT
81.  
82.     END IF
83.     _MEMFREE M 'Free the temp mem block
84.     $CHECKING:ON
85. END SUB
86.  
87.  
88.  
89. FUNCTION ConvertOffset&& (value AS _OFFSET)
90.     $CHECKING:OFF
91.     DIM m AS _MEM 'Define a memblock
92.     m = _MEM(value) 'Point it to use value
93.     $IF 64BIT THEN
94.         'On 64 bit OSes, an OFFSET is 8 bytes in size.  We can put it directly into an Integer64
95.         _MEMGET m, m.OFFSET, ConvertOffset&& 'Get the contents of the memblock and put the values there directly into ConvertOffset&&
96.     $ELSE
97.         'However, on 32 bit OSes, an OFFSET is only 4 bytes.  We need to put it into a LONG variable first
98.         _MEMGET m, m.OFFSET, temp& 'Like this
99.         ConvertOffset&& = temp& 'And then assign that long value to ConvertOffset&&
100.     $END IF
101.     _MEMFREE m 'Free the memblock
102.     $CHECKING:ON
103. END FUNCTION
104.  

The Screen Information is stored in a REDIM array, which you use to pass the information back and forth between the two subs, which in this case is found near the top of the code with: REDIM Array(0) AS STRING.

Note, this should work in graphic modes just the same as it does for SCREEN 0, though I haven't tested it extensively.

I'm sorry it took so long for me get back to you.

Thanks for the code and REMarks you provided.  It's a little more than I need at the moment because my program always uses a SCREEN 0, 80 character width display, but I'm sure I can learn a lot from it for future projects.  I like the way that you and Luke both comment each line to explain exactly what it does and why it's needed.

There were a lot of articles you had posted back on [abandoned, outdated and now likely malicious qb64 dot net website - don’t go there], one in particular that explained in great detail how the SCREEN 0 memory works -- (that 2 bytes are used for each character position, first byte = ascii value of character, and the second byte = the foreground and background colors).  I think that MOD could then be used to get those 2 values from that second, single byte.
That article was a lot of help when I had to manually calculate the 'offset' and 'length' variables needed when I was using the older BSAVE, BLOAD method to transfer screen data.  As a matter of fact, I'm still using the older 'offset' and 'length' variables _as_part_of_ the newer _MEM command(s) method.

It would be nice if those old acticles could be found and restored here at qb64.org if/when they are made available from [abandoned, outdated and now likely malicious qb64 dot net website - don’t go there] because I'm sure that lots of other people would find them interesting and useful.

Oh, and thanks again for getting the problems with VAL fixed a few years ago.  That was one of the first bugs I ever reported way back in the SDL days, and it just so happens that this program I'm working on right now is the same one I was using when I noticed the problems with VAL.

Stuart

Basically, the program I've been working on uses a SCREEN 0 text screen that is always a minimum of 80 characters x 50 lines, and could conceiveably be as large as 80 chars x 200 lines when using QB64.  The usual size is between 66 and 130 lines depending on the screen resolution, available desktop space and _FONT used.


Here's the problem : 

I'm currently using the code below to BSAVE a copy of a certain segment of the video memory for SCREEN 0 which has already been calculated using the 'offset' and 'length' variables.

Next, the subroutine at line 1400 resets the screen size to either a 50 line screen (using a different _FONT), or...  a more than 50 line screen.  The actual number of lines will vary as described above.

After the new SCREEN 0 text screen has been established at 1400 (using the WIDTH command), the new screen will be blank, so the BLOAD statement is used to write the previously saved screen data to the beginning segment of the new SCREEN 0 video memory at &HB800 and then the KILL command deletes the temporary file that was used.


Everything works just like I want it to, but...  I don't really like having to save and then delete a file from disk each time the routine is used.

I'm pretty sure that one or more of the _MEM commands can be used to do all of this in QB64, but even after reading the info here :  https://www.qb64.org/articles/articlemem.txt I just can't figure out exactly how to go about doing it.  I'm thinking that the BSAVE and BLOAD lines just need to be replaced with the proper variant of _MEM such as _MEMIMAGE and/or _MEMCOPY or _MEMGET and _MEMPUT, but who knows?

Thanks in advance for any help that can be provided.

Fooling around a little with Win API... I hope the wife doesn't find out. So, coincidence or does this code actually work...

Yes!  I added your code to the top of my sample program, made changes on two lines, and it works perfectly.

Now, if one of the developers could incorporate this into QB64.exe (at least for the Windows part of the code) then the _DESKTOPWIDTH and _DESKTOPHEIGHT commands would work a lot better.

I'm not sure if this is a bug or if it's by design but when a QB64 program first starts, _DESKTOPWIDTH and _DESKTOPHEIGHT both return the correct values for the desktop size...

...However, if the desktop resolution is changed _after_ the program has been started, _DESKTOPWIDTH and _DESKTOPHEIGHT still return the same values as they did when the program was first started.

This problem was first reported back in May of 2014 on the [abandoned, outdated and now likely malicious qb64 dot net website - don’t go there] forum, but I wanted to repost it here since [abandoned, outdated and now likely malicious qb64 dot net website - don’t go there] isn't available anymore and new users of QB64 may not be aware of it.

ON KEY(n) and ON TIMER(n) both work, but if they are used together in the same program there _will_ be unexpected results.


For some reason, after the "ON TIMER(n)" statement has been used and then "TIMER ON" activates it and then "TIMER OFF" disables it, the subroutine that it uses gets called by the "ON KEY(n)" statement instead of the subroutine that "ON KEY(n)" is supposed to use.

I am including an example program that demonstrates this odd behavior if anyone wants to check into it.

The example program works in QB4.5 without any problems, but QB64 has a problem with it.

Basically, if/after ON TIMER(n) GOSUB is used, then : 
After TIMER ON (and then TIMER OFF) is used XX number of times, then
ON KEY(n) will use the ON TIMER(n) subroutine XX number of times before
it starts to use it's own subroutine.

I'm currently running Windows XP Home Edition SP3 (using QB64GL version 1.2) and I've also tested this as far back as SDL version 0.954 and it has the same problem.


As I recall, back in 2014, the verdict was that there IS a problem BUT the section of code that handles these events was written by Galleon and he would have to check into it himself.



  [ You are not allowed to view this attachment ]