PureBasic Forums - English

Yes there seems to be a problem here too, mine crashes as soon as I try to collapse, and I get Invalid Memory Access error at 0, pointing to: Event = WaitWindowEvent() on both examples, I am sure Chris must have made a bit of a slip up somewhere and will have it fixed soon.
I am using win7 starter, PB460.

electrochrisso wrote:That's great stuff Chris, I expect that ProGUI should be good for animations and certain types of game programming too then.

Yep that's right mate Being able to make a rich multimedia type application should be a breeze! You could even have a full game running inside a PanelEx with real-time hardware accelerated alpha blending and resizing (when an image is loaded into the SuperBuffer the alpha channel is pre-multiplied and hence allows the GPU to handle everything); in comparison, PureBasic's DrawAlphaImage is very slow as uses CPU pixel based routines (I think the PB team chose this method for ease of cross platform porting).

Zach: Thanks for reporting the bugs (and Oliver too!), as Chris speculated I made a slip-up In my haste to get the new release out I didn't check that the UserLib version was working correctly doh! The ImageButtonEx and TextControlEx are now sub-classed PanelEx's however the culprit of the bugs is the UseGadgetList command in the UserLib version, which is not getting restored to the parent PanelEx gadget list when a skinned control is created inside. Also I've buggered up the positioning of the Frame3DGadget inside nested PanelEx's which is down to a single command being incorrect (MapWindowPoints_).

I'll have a fix ready soon guys and I'd just like to thank you all for reporting the bugs (you're all in the credits! ), V1.34 was a little rushed as I've been concentrating on the new V1.5 (SuperBuffer) and V2.00 core development.

Chris.

I figured you've been busy as you haven't been very active on the Forums and emails were taking a few days to hear back.. But its good to know that you are working on stuff.

You've got a good loyal customer base (I hope) so don't rush it too much. This is a very complex software suite and I'm sure everyone knows that.. I do hope you are continuing to see sales as well, or at least have made a fair bit of money off all this.

Is V2.0 going to be the new rendering system with DirectX and such?

Zach wrote:I figured you've been busy as you haven't been very active on the Forums and emails were taking a few days to hear back.. But its good to know that you are working on stuff.

Yes sorry I haven't been as quick to reply as I usually am, the code I'm working on at the moment is pretty critical and I don't want ProGUI to fall like a house of cards later on due to me making mistakes in the new core code, thanks for understanding and being patient with me though!

Zach wrote:You've got a good loyal customer base (I hope) so don't rush it too much. This is a very complex software suite and I'm sure everyone knows that.. I do hope you are continuing to see sales as well, or at least have made a fair bit of money off all this.

Thanks mate I really appreciate the loyalty of my user-base (over 100 registered now!) and the enthusiasm for the project even though I'm not making as much money as I'd like at the moment (still early days though, I get around 1 to 4 Platinum sales a month on average), the support of you guys makes it worth while

Zach wrote:Is V2.0 going to be the new rendering system with DirectX and such?

Yep that's correct The code will be ready for cross-platform then too but this will take a while longer to release after V2.00 (DirectX).

Chris.

I've been meaning to ask about the Cross Platform vision.. For a Windows only product I can certainly see the benefit of supporting DirectX, for example. But for hardware acceleration across 2 or 3 major platforms OpenGL looks to be the only real solution there.. I would think it a pain to maintain both a DirectX and OpenGL codebranch, no? It almost feels like OpenGL from the beginning would have been a good idea since it can work across all 3 major platforms, and you wouldn't be repeating work..

But this isn't meant to be discouragement or doubt about ProGUI in the future, I'm just kind of thinking out loud and asking some questions.. I'm always curious to learn what plans you have for the future and how you will lay them out, and arrive at final goals..


Glad to hear you're getting sales still. I never really can tell how big the PB community is outside of the regulars here on this Forum; although I am guessing you get Blitz customers too and maybe some AutoIT..

But when you get around to releasing C/C++ bindings I think ProGUI will have the potential to really take off.

Zach wrote:I've been meaning to ask about the Cross Platform vision.. For a Windows only product I can certainly see the benefit of supporting DirectX, for example. But for hardware acceleration across 2 or 3 major platforms OpenGL looks to be the only real solution there.. I would think it a pain to maintain both a DirectX and OpenGL codebranch, no? It almost feels like OpenGL from the beginning would have been a good idea since it can work across all 3 major platforms, and you wouldn't be repeating work..

I've thought a lot about this too Zach, and using just OpenGL or the PB command set did cross my mind. The problem is with Windows and back compatibility. As it stands GDI and GDI plus has to be used with OS versions less than Vista for performance (and DirectX/OpenGL might not be installed for instance) so using just one technology isn't an option. I decided the best way to go is by creating my own Image sub-system that ProGUI uses internally to render (and is available externally to the user) with "drivers" for each platform. So for instance the new ProGUI API command ImgBlit would call sb_Blit (SuperBuffer Blit) which in turn on Windows versions less than Vista calls GDI BitBlt or on OS >= Vista would call Direct2D DrawBitmap. It's then just a case of maintaining the pluggable "driver" code on all OS/Platforms that sb_Blit calls. For the rest of ProGUI, the actual implementation doesn't matter because all it ever sees is the top level ImgBlit command. On MacOS or Linux, the driver code could simply use for the most part the PB command set (which uses OpenGL)

I might not have explained that very well lol

Zach wrote:But this isn't meant to be discouragement or doubt about ProGUI in the future, I'm just kind of thinking out loud and asking some questions.. I'm always curious to learn what plans you have for the future and how you will lay them out, and arrive at final goals..

Oh no of course not mate I didn't think that, it's cool that you're interested in how the stuff works internally

Zach wrote:But when you get around to releasing C/C++ bindings I think ProGUI will have the potential to really take off.

I hope so too I've purposely been holding the C/C++ wrapper back as I want to iron out all the kinks and get it all working how I want it before unleashing it on a potential shit storm of customer support

Chris.

Yep that's right mate Being able to make a rich multimedia type application should be a breeze! You could even have a full game running inside a PanelEx with real-time hardware accelerated alpha blending and resizing (when an image is loaded into the SuperBuffer the alpha channel is pre-multiplied and hence allows the GPU to handle everything); in comparison, PureBasic's DrawAlphaImage is very slow as uses CPU pixel based routines (I think the PB team chose this method for ease of cross platform porting).

Super mate, I think this will be a real boon for ProGUI and am sure will bring you in a lot of new customers for ya.
It might be a good idea for people to upgrade to Platinum before there be a substantial future price rise.

electrochrisso wrote:Super mate, I think this will be a real boon for ProGUI and am sure will bring you in a lot of new customers for ya.

hehe I hope so Chris

electrochrisso wrote:It might be a good idea for people to upgrade to Platinum before there be a substantial future price rise.

yep it's probably a good idea if you have the spare cash to upgrade but don't worry just yet, the price won't be increasing for a while.

Guys, I've sorted the ExplorerBar collapse crash bug in the UserLib version. I didn't realise that the GdiAlphaBlend command was being imported (LoadLibrary) outside of the ProGUI_Init procedure which TailBite doesn't allow and hence when you clicked on the ExplorerBar header the prototype was referencing a null pointer!

I should have the new release ready later today.

Cheers!

Chris.

Great news

Although I have been wondering.. is there a way to get Codehints using the DLL version?
I'll always prefer the Userlib because of them, but also because I want the GUI compiled into the EXE and prefer not to distribute a DLL but I've been curious about this for a while.

Do they come from the Residents file? I wonder if you can use the DLL, but instead of using the PB Include, use the Residents file instead...

They come from the userlib itself.

Guys I've fixed all the reported bugs (and a couple of other ones I've found) but I'll release it tomorrow as I'm a bit tired now and want to thoroughly test everything (got the docs to update too).

Cheers!

Chris.

I'm not sure if its a Purebasic bug or ProGUI, but if I include a #PB_Text_Border flag on a Purebasic StringGadget, it doesn't draw any borders at all, makes the StringGadget totally invisible.
It's supposed to Draw a sunken Border (see this screenshot from older version, sunken border on Calculated ID field)

Zach wrote:I'm not sure if its a Purebasic bug or ProGUI, but if I include a #PB_Text_Border flag on a Purebasic StringGadget, it doesn't draw any borders at all, makes the StringGadget totally invisible.
It's supposed to Draw a sunken Border (see this screenshot from older version, sunken border on Calculated ID field)

The #PB_Text_Border flag is only supported in TextGadget, If you're using it in a StringGadget the constant value probably is the same as #PB_String_BorderLess which would make it appear invisible.

Chris.

oh my god I'm so fucking retarded

I failed to notice when referencing my original code for the results field that it WAS a TextGadget



Also... just had fun trying to get my event to work for the on-the-fly calculation for those input forms... The new guiMap() Map I'm using is working great, but I keep forgetting to add half a dozen quotation marks (for the string based keys) and extra () encapsulation when modifying older code


But everything is working great so far, and a lot easier too, thanks to this GUI Map idea

Zach wrote:oh my god I'm so fucking retarded

I failed to notice when referencing my original code for the results field that it WAS a TextGadget

no worries!

Zach wrote:Also... just had fun trying to get my event to work for the on-the-fly calculation for those input forms... The new guiMap() Map I'm using is working great, but I keep forgetting to add half a dozen quotation marks (for the string based keys) and extra () encapsulation when modifying older code


But everything is working great so far, and a lot easier too, thanks to this GUI Map idea

That's cool man yea maps are pretty neat! usually faster at accessing than iterating through a list too (but at the expense of using a little extra memory).

I'm just doing some final tests on the new version, should have it released in a couple of hours

Chris.