PureBasic 5.30 beta 9 released!

[macros]

@DK_Peter
Seems it isn't the fault of your code.
I stepped trough the program and it crashes every time at

Code: Select all

Scr = OpenWindowedScreen(WindowID(Win), 0, 0, 1024, 768,#False, 0, 0, #PB_Screen_SmartSynchronization)

I will test further and maybe have to report a bug.

[DK_PETER]

@macros
That's an odd one indeed.
Try setting the compiler's subsystem to OpenGL....It might do the trick.
Best regards
Peter

[Didelphodon]

Nice, will come in handy for my PureFiler and stuff. Thx a lot.

[netmaestro]

I get an IMA at RenderWorld() for this code and every 3D example code from the examples folder. PB Win x86 on Win 8.1 64bit. Am I missing a dll or something?

[Comtois]

I get an IMA at RenderWorld() for this code and every 3D example code from the examples folder. PB Win x86 on Win 8.1 64bit. Am I missing a dll or something?

may be directx9 ?

http://www.purebasic.com/documentation/ ... ine3d.html

[netmaestro]

Thanks Comtois, that worked. I guess what confused me is that the 3D engine initialized ok and the problem didn't appear until the code actually ran. I would have thought that if the environment weren't in place then InitEngine3D() would return 0.

[macros]

@DK_Peter

Found the corresponding bug:
http://www.purebasic.fr/english/viewtop ... 8&p=445665
and with debugger disabled your code runs
Nice 3D example!

I added some info to the bug report.

[luis]

A suggestion though: Could we have a GetGadgetAttribute with

Code: Select all

#PB_OpenGL_ProcAddress

(or something) so we can retrieve all the OpenGL extensions and use the full potential of the latest OpenGL versions ?

Or better yet a crossplatform GetProcAddress() so it would be possible to use it not only with the gadget but with the opengl subsystem too.



EDIT: I meant GetProcAddress() not GetProcessAddress() sorry

[grabiller]

A suggestion though: Could we have a GetGadgetAttribute with

Code: Select all

#PB_OpenGL_ProcAddress

(or something) so we can retrieve all the OpenGL extensions and use the full potential of the latest OpenGL versions ?

Or better yet a crossplatform GetProcessAddress() so it would be possible to use it not only with the gadget but with the opengl subsystem too.

Indeed, good point.

[coco2]

Sounds good thankyou!

Update looks great! I guess the JSON module I wrote last month is no longer needed

Lol! But think of the knowledge and experience you gained

[marc_256]

Love it ...
can't wait for the final.

WAW

Good work team, since the canvas gadget, the open GL gadget is the best thing i need for now...

marc,

[staringfrog]

The #PB_Event_SizeWindow and #PB_Event_MoveWindow events are no longer reported in realtime in the main event loop. This is to reduce problems with flickering on resize.

If you meant that notoriously odd Win PanelGadget behaviour that sends the whole form flickering like mad on every resize event including splitter shift — then it didn't have helped, once again. Tried binding together with smartwindowrefresh on WinXP, with exactly the same result. Guys, if you're so smart and assembly-wise and all (and you certainly are), why don't you devise a winpanel control of your own at last? Tons of posts through the past decade on this matter on this forum, several API workarounds, and still no clear solution. Something tells me that MS would never care to do this the right way.

If I remember well, there was another topic here, with debates over scarce comprehensive reference sources on PureBasic and some 'subversive wiki activity' in this respect. Indeed, what PB needs now is not one golden but olden all-in-one textbook but a series of new and up-to-date references (like General Overview, PB and ASM, PB and WinAPI, PB and 3D, PB Libraries etc). I'm afraid this #PB_Event_SizeWindow binding as a strict new norm is just another brick in the wall for Gary's brilliant and veritably seminal best-seller, as his listings of the main loop now look certainly obsolete and incomplete. I believe however extensive .chm/online manual would never suffice, to promote such a beautiful and flourishing language as this. Books still make sense. And market.

[Tenaja]

...why don't you devise a winpanel control of your own at last?

Stargate already has:
http://www.purebasic.fr/english/viewtop ... bbargadget

That is the gadget used in the IDE itself. Converting the IDE was "easy", though, because it did not use the panelgadget to contain the scintilla gadgets:
http://www.purebasic.fr/english/viewtop ... 00#p375061

Using tabbargadget and that technique, the panelgadget becomes moot.

[Bananenfreak]

Thank's fantasie team.

Unfortunately, i can't really see (or maybe i missed them) new features on the 3D side. (by referring to this)

Relax Alexi, Relax. Take a seat, take a tea and wait a while. You want so much, but not all of this is useful for everyone... I think also it´s not easy to implement.

[staringfrog]

...why don't you devise a winpanel control of your own at last?

Stargate already has:
http://www.purebasic.fr/english/viewtop ... bbargadget

That is the gadget used in the IDE itself. (...)

Using tabbargadget and that technique, the panelgadget becomes moot.

Right, I've already noticed how IDE utilized this really cute Stargate lib, of course. However, what I need is a basic panel gadget (for a fixed set of resizable containers fitted with bookmarks), and not some 'visual stubs of bookmarks' with all that advanced functionality and flexibility. Look, I'm just a common user, not even an advanced 'recreational programmer', as Petzold put it. I've bought PB about a year ago, to re-write some of my code from the time when VB5 was young and powerful and unwieldy as hell. Thus, all I need for my forms is a standard set of controls, no more but no less. I understand from both your posts and my tests that this is indeed a perennial Windows graphic bug, and I'm not the first one here to suggest re-writing of PanelGadget for Windows. Here in this announcement thread I'm only to report the unchanged odd behaviour of PanelGadget (that sends the whole form wobbling on resize) in 5.3 b2, despite the improved window redrawning performance and algorithms.

Sorry for a bit of offtopic anyways.

P.S. Yes, and I believe I've read all the pertinent recipes from this forum. WS_ClipChildren won't help, as (while flickering disappears) the PanelGadget stops redrawing itself, leaving trails of border lines on resize (apart from other demerits of this method) [also reported here].