PureBasic Forums - English

When a desktop-scale is set (for example 200%) window-screen doesn't scale correctly.
All Gadget and the window is scaled correctly and work, but the window-screen is simple not scaled and only 1/4 (the left button corner) is filled with the graphic.

Simple run the openwindow-example from the pure ...

It seems, that the Debugger itself can't catch any crashes.

Procedure ErrorHandler()
MessageRequester("OnError Test", "Der folgende Fehler trat auf: " + ErrorMessage())
EndProcedure

MessageRequester("OnError Test", "Test starten")

OnErrorCall(@ErrorHandler())
PokeS(10, "Hello World") ; verursacht einen #PB_OnError_InvalidMemory Fehler ...

PureBasic 6.21 - C Backend (Linux - arm64)

InitSprite()

#width=1000
#height=800

OpenWindow(1,0,0,#width+200,#height,"vysnc-test",#PB_Window_SystemMenu)
EditorGadget(1,#width,0,200,#height)

OpenWindowedScreen(WindowID(1),0,0,#width,#height,#False,0,0,#PB_Screen_WaitSynchronization)

Repeat ...

First of all, this is no "really bad code".
This is how OpenWindow() worked since ... the beginning(?), it returned the OS handle.

It *IS* really bad code, because it is not documentated. You used a undocumented feature and undocumented feature can change *every* version without noticing it ...

I can't test it here, but the *mem-Buffer is to small, StringByteLength return the length without the zero-end-byte, CopyMemoryString DOES copy the zero-byte. You should add a "SizeOf(Character)".

In which world your FastDist() returns a distance in 3D space?


In many cases you can work with squares without problems.
"distance < 2" is true, then "distance² < 4²" is also true. As long as you only want to compare distances, it is faster than calculating the square root of a number.

Procedure DebugJson(injVal,deep=0)
Select JSONType(injVal)
Case #PB_JSON_Null: Debug Space(deep*2)+Hex(injVal)+" null"
Case #PB_JSON_String: Debug Space(deep*2)+Hex(injVal)+" string "+GetJSONString(injVal)
Case #PB_JSON_Number: Debug Space(deep*2)+Hex(injVal)+" number "+StrD(GetJSONDouble ...

The only methode (without reading undocumented pb-internal-data) that I found is a array in a structure:
Structure One
a1.i
b1.i
etc.i
EndStructure

Structure MyArray
Array one.one(0,0,0)
EndStructure

two.MyArray
Dim two\one(1,2,4)

three.MyArray
Dim three\one(5,6,7)

Procedure Check(*p ...

you can change the size of the labyrinth with the #widht and #height constants. My console is 120x30 Chars wide (right-click on the console-titelbar, select properties and change in the layout-tab (I have a german window, so the names may be a little diffrents).

https://i.imgur.com/bE1D70K.png

Based on https://www.youtube.com/watch?v=ZZY9YE7rZJw

This code creates from a seed a labyrinth.

; Based on https://www.youtube.com/watch?v=ZZY9YE7rZJw

DeclareModule RND
EnableExplicit

; get a random number (32bit)
Declare.l get()

; get a random double ...

Define hwnd
hwnd = OpenWindow(0, 0, 0, 230, 90, "Event handling example...", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
Debug "hwnd = " + hwnd + " == WindowID = " + WindowID(0)
This is a really bad code.

https://www.purebasic.com/documentation/window/openwindow.html
Return value ...

No! According to Microsoft a 32-bit handle works in 32-bit and 64-bit applications:


Your mistake is, that this is only valid for WIN32-API-Handles. BUT we talk about PureBasic-Handles! Handles in Purebasic are more like an ID. And this ID can be 64BIt on a 64-bit System.

OpenWindow for ...

which is ok, since it is not definied what kind of handles they return, it is only definied, that it return a "number" in Integer-range.

it is also possible, that you will have with the asm-backend strange bugs, because you used the wrong type, for example on large memory-usage it could use memory ...

as far as i know: Handles in PB are *ALWAYS* in Integer. so ".l" is not correct and when it work, it is pure luck.