PureBasic Forums - English

Thanks again! Browsing the khronos site, my understanding is that any OpenGL calls made in the current thread, regardless of whether the code is called in a DLL, will act on the current context, so I shouldn't need the handle. I'll give it a try.

This not just MacOS and Windows ARM -- I'm on Windows x86 and continue to see this issue across several versions of PB. It appears to be something scaling related, given the workarounds that have been found.

Same issue here: https://www.purebasic.fr/english/viewto ... 91#p629691

I find that if you click on the label field to the left, you can then click the property field to the right without it scrolling. There are some other workarounds on the linked page.

Thanks! I had seen that in various places; was wondering if I was missing something. Any cross-platform (or even platform-specific) code for the others anyone is aware of.
Anyone an OpenGL expert? Is it even necessary if the PB code and foreign (DLL) code are executing in the same thread? Seems ...

Is it possible to get the OpenGL context handle for a given OpenGlGadget? Is this what is returned by GadgetID() for an OpenGLGadget? I want to pass the context's handle for a specific OpenGLGadget to OpenGL code in a DLL (in a different language).

I've also been seeing this more lately on Windows 11. It seems usually restarting the compiler fixes it, but sometimes an IDE relaunch is required. I haven't pinned down the circumstances to make a more informed report.

Note that issue also occurs on Mac, so the Windows workaround won't work there. I've also noticed it comes and goes, and that sometimes tabbing through the cells or clicking the very left edge of the checkbox cell works.

I'm also unclear on this, and as far as I can tell, these are not described in the documentation anywhere beyond

Specific OS path separator characters are available #PS, #NPS, #PS$ ('\') and #NPS$ ('/').

(looks like there links have never been completed)

and the changelog:

- Added: #PS, #NPS ...

Finally got it figured out. For posterity:

PrototypeC ProtoJL_Init()
PrototypeC ProtoJL_Eval_String(Eval.p-ascii)
PrototypeC ProtoJL_AtExit_Hook(Status.i)
PrototypeC.d ProtoJL_Unbox_Float64(*jlptr)
PrototypeC.l ProtoJL_Unbox_Int32(*jlptr)
PrototypeC ProtoJL_Box_Float64(num.d)
PrototypeC ProtoJL ...

In the second case, which I think is correct, do I have to do something to convert back from UTF-8?

Ok, if I convert to using the * with the default declaration (i): Then the relevant output line is: If I specify a string type,
then I get:

Relatively new to PB and trying to work with calling a DLL. Specifically looking at interfacing to the Julia runtime as described here: https://docs.julialang.org/en/v1/manual/embedding/#Embedding-Julia. While the calls are not crashing, it's also not clear that parameter passing is working. In ...

I experimented further with this (using the x86 build) by adding an instance of each control type to the form and found that I could access the properties for most controls through the panel, but not the treeview or the listicon. I also could not access the properties for the window/form itself, so ...

I was wondering that, though it does work for the Mac demo. I was also wondering if it might be that I have the very latest Windows 11 and whether anyone else is running 22H2?

As a follow up, I've confirmed that this works as expected on Mac (Arm build), so don't think it's me.

Looking to move to and license PB, but this will be a showstopper.