GETDESKTOPSIZE causes this error
ps. gernot could you look into why all windowed binaries on win32 become blacked-out after minimizing them for a 10-15 minutes? (http://www.glbasic.com/forum/index.php?PHPSESSID=08fb82b7a4fc8a22989ce37c276aaa8f&topic=9963.0)
Quote
_______________________________________
*** Configuration: WIN32 ***
precompiling:
GPC - GLBasic Precompiler V.10.053 SN:17b922e3 - 3D, NET
Wordcount:1334 commands
compiling:
C:\Users\A10TRI~1\AppData\Local\Temp\glbasic\gpc_temp0.cpp: In function `int __GLBASIC__::__MainGameSub_()':
C:\Users\A10TRI~1\AppData\Local\Temp\glbasic\gpc_temp0.cpp:794: error: no matching function for call to `GETDESKTOPSIZE(DGInt&, DGNat&)'
C:/Program Files (x86)/GLBasic_v12/Compiler/platform/Include/glb.h:1369: note: candidates are: void __GLBASIC__::GETDESKTOPSIZE(DGInt&, DGInt&)
C:/Program Files (x86)/GLBasic_v12/Compiler/platform/Include/glb.h:1370: note: void __GLBASIC__::GETDESKTOPSIZE(DGNat&, DGNat&)
*** FATAL ERROR - Please post this output in the forum
_______________________________________
*** Finished ***
Elapsed: 3.0 sec. Time: 01:44
Build: 0 succeeded.
*** 1 FAILED ***
how do you uses it? Its look like its trying to return something, which you cant do that with that command.
Here its do compile fine here with that command in both v12.312 and v12.096.
That is odd - GETDESKTOPSIZE works with both integers and floats here :
LOCAL x%,y%
GETDESKTOPSIZE x%,y%
DEBUG x+" "+y
The memory problem only happens in debug mode - in release mode there is no steady increase in memory usage.
I dont understand...i dont ever use debug mode lol
Its working now..that error doesnt show up anymore.....
Somehow my projects have been getting buggy..almost seems like a bug with IDE
im have seen isssues like that some times.
often its a misplaced variable, or missing ; or something like that on the just previous command or a variable conflict. That can have tricked to there was a issue on GETDESKTOPSIZE.
Howover im diddent see the c++ files around what its said on those lines. But its something like that.
Eh, how do you write programs without using the debug mode, hemlos? I would tear my hair out.
Quote from: Moru on 2014-Sep-06
Eh, how do you write programs without using the debug mode, hemlos? I would tear my hair out.
I rarely use Debug mode, practically never. If you know your code and you know what should be happening it's usually obvious when something doesn't work. I've probably posted more completed GLB games than most users, so it's not of vital importance (well, to me anyway).
I'm use debug very must due im use stdout very much. Without logcats, android extras won't have been possible and when you do complex games.
But it's depend how complex they are of course.
I'm pretty much the same as Ian in that I rarely use debug mode unless something is not acting right & it's not obvious. Sometimes I might track some variables (mainly floats for rounding errors etc) as it's less messy in the debug window than showing on screen plus being able to scroll through them is better.
When I started with GLB I used debug a lot more until becoming more familiar with it's syntax & commands but now mainly if something goes wrong or doesn't look right I pretty much know where to look in the code. I try as much as possible to avoid lengthy sections of code which also helps me find whats not working right.
Lee
Quote from: Moru on 2014-Sep-06
Eh, how do you write programs without using the debug mode, hemlos? I would tear my hair out.
I did use it when i wrote APE and the Bezier Lib too, also when i do speed tests to compare stuff such as Table based random numbers....mathematical beasts inside and out.
Like Ian, Typically i can predict what is supposed to be happening time-wise cpu/gpu-wise and memory-wise with the program, I dont need to use the debug mode.
However, this is only because I wrote it, i wouldnt be able to do that with other peoples software especially if its a large one.
Furthermore this program is so simple, its really a no brainer(thats my speed).
There is very little math and processing happening behind the scenes, the program doesnt really require alot of calculations at all, so debug mode isnt needed here imho.
Regardless, the IDE seems to spit out errors after compiling a few dozens times in one sitting.
If i reboot, delete the binaries, and rebuild them, everything is fine.
I seriously doubt its my computer, because ive experienced this on other computers too.
ps. ARRAYS[]/GETTIMER()/PRINT/SHOWSCREEN/KEYWAIT to step through, during runtime to get all the info i need. IMO its quick, and dirty, and effective.
I'm sure you all know what you are doing and don't think you need the debug mode but when you say that you have to delete all files and restart the IDE and so on, next time just try to switch the debug mode on and then off again and see if that solves the problem :-)
Release mode usually supresses some error messages that would have stopped bugs from showing up later. The earlier you catch a bug, the less you have to search for the cause. It can be something really simple that won't show up until users start testing the game.
For example this program:
GLOBAL test[]
REDIM test[5]
test[6] = 1
KEYWAIT
END
In debug mode the debug window will tell you array out of bounds, in release mode it will just exit without any error message at all.
I find that I seldom use the debug mode for actually stepping through a program but I do like it for the extra error messages I get.
I did need to use it when i had an overstack crash that i couldnt pin down.
The debugged points right to it. :booze:
@Everyone:
Does anyone else run GLBasic binaries for hours, minimized to a windows 7 desktop?
Do you get the blackout error too?
I would love to run a glbasic binary server host program, but i cant due to this problem.
Have you tried a command line application instead? But I guess you loose access to grafics commands then. I have only run command line applications for hours and hours in the background.
Pretty much 9/10 times if my program just quits it's an out of range array error & I know where to start looking from what was going on before the crash. On the odd occasion where I cannot work out the exact area of the crash then I will normally turn on debugging.
I'm not saying that I am an expert coder who never makes mistakes because I do, but I coded for so many years without a debugger being available that finding problems/errors in my code is normally a quick process. Also I split my code as much as possible into small chunks of which a lot of routines are reused from other projects which work so that helps me narrow down the cause of any problems.
Lee
Overstack error in the output of ide:
/path/path/program.gbas (200)
The number here is the line number when it finds the overstacked array.
@moru: yes a terminal will run good, still, it would be nice to find a fix for the graphical.
I can run the program on the desktop with no problem for a long time, just not minimized.
I have an idea for a fix to this problem with blackout...
Detect minimized window, stop calling graphics commands until focus is regained.
Somehow i dont expect it to be a fix though...because its not just the program going black, its the entire window and window buttons and title bar too.
How long are you waiting for the program to start up again after minimizing and bringing it up again? I have seen heavy games after minimizing, taking very long time to get back again since they have to swap out and back in. Could take 5 minutes sometimes if you are very low on memory and fragmented swapfile.
This is on an SSD and 8 gig of ram...swap is off.
The program remains black indefinetly, ive let it sit there for a long while.
Hemlos, please forgive me for making the following joke: when looking at your 1st post here the compiler exactly tells you where the problem is, so no need to guess etc. So I think I know why you dont use debug mode: you simply dont know how to read it. :D
Sorry mate, joke aside, you probably have done something like this:
LOCAL a#
LOCAL b%
GETDESKTOPSIZE a, b
And this will give the error you described. You cant mix Ints and floats in GETDESKTOPSIZE (and probably a few other commands that have reverence arguments). Make both arguments ints or both floats and it works just fine. And that is exactly what the compiler told you.
About the other issue (hanging window) please dont span this over many threads, keep it in one.
Thats the point...ts not a syntax error, yet a compiler error.....
This matter to idiots like me.
Actually GETDESKTOPSIZE is only defined if the arguments are either both DGNATs or both DGINTs. If you mix data types or use any other data type (e.g. int64) it is not defined and be considered as a user/syntax error. But IMHO this would need to be stated in the help file.
This is exactly why it says at the bottom of the error report "Please post this on the forums".
LOCAL sx%, sy%
GETDESKTOPSIZE sx, sy
SETSCREEN sx, sy, FALSE
WHILE TRUE
PRINT "Ein kleiner Test :D", 10, 10
SHOWSCREEN
WEND
END
The coordinates are wrong after SETSCREEN to Desktopsize...
Technically it is correct - unfortunately with borders it means that not all of it can be displayed...