But there is still a problem to access gobal variables from within a callback. I suppose you will use "userdata" for this? Since global variables only lead to "spaghetti" code, they are generally discuraged. Therefore, using "userdata" to pass information, is the prefe...

There is absolutely nothing wrong with that "Hello World" example in WIN 10. (It works as expected.) There may be a problem, with the "Japanese" (translated) version only. This would mean, that contacting "Microsoft-Japan" would be the only path, in order to resolve the...

I have tried using longs in 32 bit fbc, but I still cannot access the python command line interpreter with "Py_Main" In this case, the C data type is probably long (C's long), which comes close to 'integer', but especially on WIN, isn't 100% compatible ... see: Comparison of integer data ...

@fxm,

since you are currently the maintainer of doc's, therefore I think that
the decision is yours. (it's not linked to a development issue)
I'd do it, for the reason of simpler maintenance (in the future, at least).

caseih wrote: At least that's what I remember that a C int is equivalent to a FB Long.

It's documented in FB-Manual, too ... see: Comparison of C/C++ and FreeBASIC

The code is safe, but very sploppy coding ... What I mean above is: you always omit the "This" specifier before the types member access, which makes code harder to read, too. Recoded version (see: comments added): type sgl2d dim as single x, y end type type polygon As sgl2d points(any) Dec...

Thx, fxm.

I've some questions regarding these changes:

1) why not the main Ptr/Pointer pages: KeyPgPtr/KeyPgPointer?
2) why is this split into two pages (it's the very same thing, after all)?

IIRC there is one page only for: Print|? (as example), KeyPgPrint.

From my point of view, there is only one thing worth a note, and that is:

Always check for "null pointer" before any other pointer usage!

(referres to any/all pointer types, if one wants to stay "on the safe side")

@Juergen Kuehlwein, unlike you, I don't think, that a dynamic WString is a prerequisite for the proposed changes, and therefore, could easily be treated on it's own. A fixed size WString, should be able to perform as needed, too. (handed over as WString Ptr, since fix len "w/string type" i...

I personally think, that we are currently dealing with a secondary issue. Let me try to explain my point of view: The currently implemented way, the CRT's file I/O functions (on WIN, at least) are dealing with strings (everything converted to ANSI/ASCII before a call). This behaviour is actually the...

You are perfectly free, to do as you please ... look it up, in the sources.

Typical of you: going off, at a tangent (not sticking to the point at issue).
Repeat: ZString Ptr (uninitialized).

Why a bug report? The test is valid, as written ... (TRUE if there is "something", FALSE on "uninitialized") Because to test strings, I never write it in this form, but rather like this: Which means that you never really test "uninitialized". (rather: initialized to &qu...

No, the return of a (uninitialized) ZString Ptr, is simply invalid ... (as expected) ' ZString_PTR_tst001.bas -- (c) 2019-07-01, MrSwiss ' ' compile: -s console -exx -w pedantic ' Dim As ZString Ptr psz If *psz Then Print *psz ' Aborting due to runtime error 7 (null pointer access) Sleep

... command line switch argument for gcc to set the linker not to show the console window by default. No, the default setting is console (if the -s switch is omitted, too). It's also a somewhat dangerous setting, in case of running a console job even once in a while, only ... See first comment from...