Sticky: PowerBASIC OpenGL Off-Site Community

[Bob Zale]

Ask yourself what a low level SDK programmer could learn from DDT contributors or proprietary code.

That's very impressive, Patrice.  It's good to know you have nothing more to learn from them.

Best regards,

Bob Zale

[Bob Zale]

I have read the posts over on the PB forum, unfortunately I can't access the examples attached to posts.  Even though I can't participate in the discussions or try out the examples...

Brice --

I'm very confused by your posts.  Over and over, I've read that you "can't post on PowerBASIC Forums" or "can't try out the examples".  You're giving folks the impression that you've been barred from using the PowerBASIC Forums, when we know that simply isn't correct.

Your problem started when you changed your password while retaining an invalid email address on file.   Without email contact, you couldn't verify th password, so then you couldn't lof in.  We fixed that problem for you, but then you rejoined the forums eight or ten more times using variations on your name, and using many different email addresses.  It was impossible to approve them all, so we consolidated them, just as you later requested.  PowerBASIC hasn't heard from you since then.  If there's another email problem, or another password problem, please contact support@powerbasic.com and they'll help.

Best regards,

Bob Zale
PowerBASIC Inc.

[Brice Manuel]

I do not see the whole SDK vs DDT argument.  I was happily using SDK via Firefly and I loved it.  Unfortunately, I never backed up my reg info before reinstalling XP.  Around that time a "friend" bought me PB Forms 1.x and I started using it and I got along with it, so my wife bought me the PBF 2 upgrade with some of her birthday or Christmas (forget which) money soon after it was released.

There are pros and cons to SDK and DDT.  Certainly nothing worth arguing about or being elitist about.  

[Patrice Terrier]

Bob,

That's very impressive, Patrice.  It's good to know you have nothing more to learn from them.

This is my opinion that i can't learn from a black box, but this doesn't mean that i do not appreciate the PowerBASIC compiler, however it is clear that PB has two kind of users.

Among the years you have pushed one group of user, but the other still exist, and they are well alive.  

...

[Bob Zale]

Patrice--

I think you you may have inferred a tiny bit of misinformation.  I haven't "pushed" one group of users.  Every user is important to us.  If you'd take a few minutes away from this attitude and just look at the PowerBASIC Forums, you'd find thousands and thousands of posts about SDK programming.

There is a place for SDK coding and there is a place for DDT coding.  We've always acknowledged that.  DDT is simply a tool to get a straightforward GUI program running quickly and efficiently.  It isn't perfect for everything, but it's wonderful for many things.

You say you "can't learn from a black box"?  You're wrong.  If that were true, you wouldn't bother using a compiler.  You'd write everything in assembler.  But, then again, an assembler is a tool, too.  Maybe everyone should go back to entering machine code with toggle switches?  What do you think?

Tools are an important part of programming.  We use them (when they're appropriate) to build upon the work of others.  A compiler is a tool.  Jose's header files are tools.  DDT is a tool.  In fact, DDT code comprises only around 2% or 3% of PowerBASIC.  Is that what you're so "worked up" about?  Well, thousands of PowerBASIC programmers use it daily, and they do quite well with it.  TCP is a tool, also.  Should we remove it tomorrow just because you don't use it?

If you prefer SDK coding for your purposes, that's wonderful.  Just ignore that 3% of PowerBASIC called DDT.  But, as Brice mentioned, there's no point in being an elitist about it.  That's just plain destructive.  Most of the folks who use DDT are pretty nice, friendly folks.  Just like you and I.  You should get to know a few of them...     {smile}

Best regards,

Bob Zale
PowerBASIC Inc.

[Patrice Terrier]

Bob,

Back to OpenGL.

We all know here, that low level SDK is the way to go with it.

If you never try BassBox (OpenGL application), then you should, because the whole project is written with your compiler, and it is probably one of the most downloaded PB project

People have been told for years that the low level flat API is over complicated, but that is just untrue, and now most of the new programmers generation are totaly lost without dotNET, MFC, VCL, Clarion, WinDev, and the other API encapsulations.

...

[José Roca]

 

I do not see the whole SDK vs DDT argument.

As I said, sharing code between SDKer's and DDTer's has become too difficult. SDKer's can't use DDT in their SDK programs and new users don't understand SDK code.

You, for example, posted in another forum:

I need to use a web gadget on a DDT form.  Unfortunately, I can't figure out how to do this, as PB does not have native support for web gadgets/controls.  I looked on Jose's forum, but could only find info for Windows created via SDK.

And you are an experienced programmer, not a novice.

There have been OpenGL examples (SDK) available for years, but in the PB forum only attract attention if you post them using DDT.

Users of SDK visual designers for PB can't use the graphic control, so they have to buy a third party one or use my freeware one.

Etc.

So there is a problem of communication and great difficulties to share code.

But this is a "fait accompli", so I'm only stating it, not whining. As long as the PB compiler will allow me to program as I wish...

TCP is a tool, also.  Should we remove it tomorrow just because you don't use it?

It's not the same, Bob. TCP can be used by both SDKer's and DDTer's.

[Brice Manuel]

My background is mostly game programming where if you wanted a GUI system that had stuff like buttons, image buttons, canvas, image box, scrollbars, tabs, etc (all the standard Windows GUI controls) you wrote your own GUI system from scratch.  You would never use Windows API for something like this.  So, I really do not "get" the SDK elitism.  SDK users just use a crutch made by another company.

SDK and DDT are two sides of the same coin in my eyes.  They are both tools and a real programmer will always use the right tool for the job.  What tool may be right for one programmer doing a job, may not be right for another programmer doing the same job.

However, I do not think code posted should be expected to be in SDK & DDT formats.  If somebody is nice enough to share code with you, you should be willing to put forth the required effort to make it work for your needs.

And you are an experienced programmer, not a novice.

To be accurate, I consider myself a PB newbie.

I really do not have an issue following SDK code, but applying it to DDT is an issue for me in some cases, but I chalk that up to being a PB newbie, not that DDT sucks.  DDT or PB isn't the problem, me not knowing how to do it is the problem  Besides that request for help, the only other time I can remember asking for help is regarding sizing a dialog by client size and that was a case I has simply overlooked/misread something in the manual.  I think I have been floundering along pretty good on my own.

However, I almost always learn something new and helpful every time I read the PB forums.

[Bob Zale]

Sorry, Jose, but it's exactly the same.  ARRAY SORT doesn't work with SafeArrays.  Should we remove ARRAY SORT?  MID$ doesn't work with unicode strings.  Should we remove MID$?  There are hundreds of sub-components in any good programming language which are dependent upon each other.  Flight attendants need a pilot to fly the plane.  Surgeons need an anesthesiologist.  And more.

Patrice wants us to remove DDT just because he prefers something different.  Patrice thinks DDT programmers are not very talented.  They have nothing to offer him.  In my opinion, he's just plain wrong.  He's a nice fellow and a good programmer, but he's wrong.  There are a lot of very talented programmers who use it.  Including me.

DDT and its sub-components are best considered as a package.  You can use SDK operations on almost all DDT dialogs and controls.  A PB Graphic Control is an intrinsic part of DDT, yet you can still use hundreds of SDK operations on it.  Should we remove it just because you can't place it on a Visual Basic Form?  I think not.  If we removed DDT, you wouldn't even have a Graphic Control to consider.  And, if we made a Graphic Control for an SDK Window, Patrice would likely complain that it's a "black box", so he won't use it.

If you use DDT Dialogs, you get a Graphic Control, if you want it.  If not, that's just great, too.  It's entirely your choice.

Best regards,

Bob

[José Roca]

 
DDT can't be removed because many people use it. It would be crazy. What I'm saying is that because DDTer's use the graphic control and SDKer's can't use it, sharing code related to graphics programming has become difficult.

Several years ago I compiled the first complete reference guide to all the GDI+ Flat API functions (more than 600), and four years ago I posted in this forum more than 300 examples (each one in 3 versions: using SDK, DDT and DDT's graphic control). The reference guide was a success... among PureBasic and ansi C programmers... It's not a joke: a PureBasic programmer used it to write one in French adapted to the syntax of PureBasic.

On July 2009, Gary was trying to use a ListView to load a JPG image with the purpose of then copy it to a graphic control. I tried once more to show how easy was using GDI+ and posted a clear and commented example: http://www.powerbasic.com/support/pbforums/showthread.php?t=41020&highlight=GDIP_DrawImage

On November 2009, I tried again, this time with a little more success: http://www.powerbasic.com/support/pbforums/showthread.php?t=41977

And all this because too many DDTer's are afraid of using anything that is not implemented in the PB language, as if his computer was going to explode if they use an API function.

DirectX? Forget it. Many people asked during years how to use it with PB. As soon as I made it possible, first writing wrapper functions for PB8 and later interface definitions for PB9, the interest vanished.

Direct2D? The next update of my headers will allow to use it with PB. But as it requires Windows 7 and the use of low-level COM, I guess that only Patrice, Petr and I will use it. So be prepared to receive requests about adding GRAPHIC2D statements to the language

[Edwin Knoppert]

Flawed form mechanisms are offered in many compilers.
DDT is no different.
And it could have been 100% flawless, PowerBASIC had the chance, believe me.
I really don't know why compiler builders implement these kind of things in such a way that in fact it is restrictive.
I tried to setup such a topic several months ago but had no response, it does not matter as it seems to most of the users, imo it says enough about the level of the programmer.
Somewhere i mentioned it that by pre-registering a simple formclass (instead of offering DDT) it would make life seriously easier already.
Only a few functions would be required to even make things more easier like a messagepump handler similar as offered now.
No one really needs Control Handle to .., they just need the info for GetDlgItem() since most users have to start somewhere and the SDK is to large to learn in a few days.

If the system was meant to be SDK one could implement a custom messagepump handler, for example to be used with a webcontrol or so, but with DDT it is never mentioned to be compatible with other calls or use.
The messagepump is such an example, there are two options here, dialog show modal or the dialog doevents but does not say you can use SDK to extend the program further, it's therefore a black box.
This is one example only.

Many people may be happy but with some clear thinking it could have been 100%.
For years i am really confused about certain steps PowerBASIC inc took like the way DDT got implemented and maybe a few other things.
Imo it's better not to implement things than half way.
But then.. that does not bring the bucks in, i understand of course.

[Theo Gottwald]

So be prepared to receive requests about adding GRAPHIC2D statements to the language

Are we going to make another wishlist thread?
I think anybody of us could sent a big wishlist to Bob. including me - just ask.

The Problem is the same like with a 64 bit compiler. The resources of PB.inc won't be large enough to fullfill all our wishes.

If we look at the alternatives, Microsoft has much more resources. And they develope the wheel somehow every two, three years new (even give it new names). Thats  just the opposite from what we want.

I don't think so much in ideologies.

If i want to make a program, i use what i have at hand.
SDK, DDT ... at the end what i want is an dialog - as fast as possible.

And actually i do not need DirectX or 2D etc. I would be happy for structural improvements:
- Improvements in MACRO abilites
- Support for Parameters in Multithreading
- Support for Multithreading in Objects
- x64 Support

In the last days i have thought about better Library organiszation using Powerbasic.
It fails because PB does include all SUBs and FUNCTIONS into the resulting EXE.
With Objects if they are bloated, its even worse.

If I include my own libraries at all i will end up with a monster programm having 90% unused binaries inside.
I'd love a Button to switch that off.

Just tell the compiler "Please do no include unused SUBs or Functions (or Variables?) i nthe final Executable/DLL".

Thats something the user can't fix.
Maybe an preprocessing pass would fix it in the compiler.

Means, i rather take a look on the hardware market and on features that we as user can not easily implement for my wishlist.

[Bob Zale]

So...  what I'm hearing now is that we made DDT far too easy for our customers to use.  If I just changed it some, and made it more difficult and unintuitive, folks would be much more likely to embrace SDK methodology.  I guess I'll have to give that a bit more thought.  {smile}

For a long time, I've considered adding a PowerBASIC Sub-Forum called "My Favorite API".  We'd encourage folks to pick one API function, and show how powerful it might be, and even easy to use.  Give newbies and DDT addicts the opportunity to try it out step-by-step and get comfortable.  If you guys will help me by adding a post or two, I'll open the forum...   Talk to me?

PowerBASIC has a fine mechanism for ideas and New Feature Suggestions.  It's easy...   Just GOTO http://www.powerbasic.com/support/request.html   Your idea will get the attention it deserves, and it will be recorded appropriately for reference by our R&D staff.   Discussing new ideas here (or anywhere) is excellent.  However, posting PowerBASIC requests here, hoping PowerBASIC employees will read it and copy it elsewhere, just doesn't seem to have the same impact and staying power for next week, next month...

Best regards,

Bob Zale

[Edwin Knoppert]

It's not that i can not suggest feature enhancements but i do similar things at the office and usually takes hours to come up with a document.
I do not want that for 'externals', and that sometimes frustrates me, i mean my laziness and the obvious changes PowerBASIC inc could make to improve certain things.
This morning it came to my mind if a callback function was used it's a DDT class, if it's an ordinary function it will be SDK (which needs DefWindowProc() and such).
But then, i haven't thought it over + i am an end-user, think about your own stuff (better) and don't depend so much on other people's arguments (and time).

[Bob Zale]

Well, Edwin, at PowerBASIC we don't depend upon the "arguments" of others.  We welcome the suggestions of our friends and customers.  We really want to know what features would help you in your day-to-day use of PowerBASIC.  If you share that information with us, it's far more likely you'll see it than if you simply sit back and wish for it.  You don't need a huge document.  You don't need fancy semantics.  You simply enter a few sentences to describe your idea.

Best regards,

Bob Zale
PowerBASIC Inc.