GETDESKTOPSIZE

[Hemlos]

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?

_______________________________________
*** 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 ***

[spacefractal]

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.

[MrTAToad]

That is odd - GETDESKTOPSIZE works with both integers and floats here :

Code: (glbasic) [Select]

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.

[Hemlos]

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

[spacefractal]

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.

[Moru]

Eh, how do you write programs without using the debug mode, hemlos? I would tear my hair out.

[Ian Price]

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

[spacefractal]

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.

[fuzzy70]

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

[Hemlos]

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.

[Moru]

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:

Code: (glbasic) [Select]

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.

[Hemlos]

I did need to use it when i had an overstack crash that i couldnt pin down.
The debugged points right to it. 

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

[Moru]

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.

[fuzzy70]

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

[Hemlos]

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.