And I like to think that I'm welcome to provide positive and accurate information about my product.  Not opinion, but facts.  None of us would want folks to leave here with inaccurate information about PowerBASIC facts, would we?  I think not.

Best regards,

Bob Zale
PowerBASIC

I just caan't go anywhere with out getting into trouble <G>

Gentlemen,

Remember this thread is entitled "Why I choose SDK over anything else", and it is located into the "SDK programming" section.

Please re-read the first post of this thread, i think i made myself clear.

If you want to speak about PowerBASIC new features and/or DDT, then this thread is more appropriate:
PowerBASIC 10

Thank you.

...

Hi Patrice,
I see different points when programming with SDK.
The first one is the portability when you want to develop for Windows and MacOs for instance.
The second one is the perinity of the code. Are you sure that Microsoft will maintain the flat APIs in future ?
(The future is 64 bits). Even if a relative compatibility is assured, will it be the same later ?
What do you think about the evolution between Windows Mobile 6.5 and Windows mobile 7, where the code must be totally rewritten ?

Thanks

Regards

Yves

Yves,

I have no idea on Microsoft's plans, however for me the flat API is burried low in Windows's roots, and if you look at the core SDK, even the latest, then you will see that it is still there.

Most of the time, the flat API is encapsulated in higher level code, but i can't image how Windows would work without the CreateWindowEx API and its correlative winproc message cracker.

For me the fact that new "programmers" know nothing about the core SDK, means more contracts for the few who still learn how to use it. 

...

Yes, but what about the portability ?

When I see some of your last Windev codes, I find some components which are not the standard ones but some Image fields (transformed into buttons for instance). These components don't use your GDIMAGE dll but Windows Apis directly.
Doing that (which demonstrates your ability to use Windows Apis), burdens the portability of the code.
As you know, Windev uses Qt libraries to have native code on Linux. I am sure they will do the same in the MacOs environment later. The hyperfile is already compatible with Mac and Java. Is it not more judicious to learn how to use the Qt libraries than Windows ones ? Nokia is a big company and will not close tomorrow. The Qt community is big too. (Using Qt libraries is an example. I mean using cross platform librairies instead Windows ones)
For my big professional projects, I use Windev . Some critical parts of these projects are done with Delphi or Powerbasic. But now, I need a MacOs compatibility (requested by customers).
The Windev Java is not solution because of the confidentiality  of the database (the password appears in the Java code). Using virtual machines is not elegant but is the only solution for me now.
Is there a dilemma ? Have we to choose between portability and SDK competence ?
...

Yves,

I am not limiting myself to one single compiler, and i am always using what i think to be the right tool to achieve a specific task.

One of the latest huge project i have done, is written with WinDev, however it runs only on Windows, and because of the demand we have also plans to let it works on MAC OS using Cocoa, thus glad i am to be also a low level programmer and having learned C.

But for me the word portability, means mostly to keep my DLL code unchanged inside of the Windows world, and let it work with any compiler or p-code being used on that platform, because it is where i am doing my living.

Thus i wouldn't say that we have to choose between portability and SDK competence, because it is the nature of the work you have to do that will say it. When you write a complete application and when you write a graphic library addon you are realy not targeting the same market, one is the end user's and the other one is the programmer's.

...

> But now, I need a MacOs compatibility (requested by customers).
The Windev Java is not solution because of the confidentiality  of the database (the password appears in the Java code). Using virtual machines is not elegant but is the only solution for me now.
Is there a dilemma ? Have we to choose between portability and SDK competence ?

I believe there's Silverlight for mac, not sure though but anyway, (unf) we stick'd with web with all its nasty habbits.
I won't speak about Linux, don't see it as a market at all at this time.

>Using virtual machines is not elegant but is the only solution for me now.
Must say that Parallels embeds Windows XP applications rather good.

Quote from: Yves Donadini on May 01, 2011, 10:23:19 AMPowerbasic. But now, I need a MacOs compatibility (requested by customers).
The Windev Java is not solution because of the confidentiality  of the database (the password appears in the Java code).

Don't forget that Java on OS X is all but dead since Apple deprecated the Java runtime as of 10.6 update 3.  They were quite specific in the fact it was being deprecated and it should not be expected to be there in the future versions of OS X.

Quote from: Patrice Terrier on May 01, 2011, 12:34:02 PM
i am always using what i think to be the right tool to achieve a specific task.

Yes, but to be actually effective with a language or a tool may take a lot of time. And of course, as you said, the nature of the work is not the same when you have to code a graphic dll or when you have to target end user's who are concerned with a database content.

Quote from: Edwin Knoppert on May 01, 2011, 01:18:05 PM
I believe there's Silverlight for mac

I have tried Silverlight which is a great tool (I like the vectorial Xaml concept), but the database implementation is not very good and the Microsoft tools are expensive (We have to change Expression Studio every year, and to get Visual Studio too)

Quote from: Edwin Knoppert on May 01, 2011, 01:18:05 PM
Must say that Parallels embeds Windows XP applications rather good.

Parallels works very well with XP on my MacBook air and Windows seven on my Macbook pro, so it is the solution I use for now.

Quote from: Brice Manuel on May 11, 2011, 07:15:21 AM
Don't forget that Java on OS X is all but dead since Apple deprecated the Java runtime as of 10.6 update 3.  They were quite specific in the fact it was being deprecated and it should not be expected to be there in the future versions of OS X.

Yes, you are right, so I 'll wait for PCSoft to create a Qt version for Mac as they have begun to do for Linux

Yves Donadini wrote...

Quote
What do you think about the evolution between Windows Mobile 6.5 and Windows mobile 7, where the code
must be totally rewritten ?

Yep, that puts me out of business.  I've been developing apps for custom Windows CE devices since
the inception of Windows CE back in the late 90s, and all my development has been SDK in C or C++.
The manufacturer of the device I code for switched from using a custom Windows CE OS on its device
to Windows Mobile.  I didn't know much about Mobile but I experimented with it and found it to be
completely deplorable, i.e., real bad.  My Windows CE code wouldn't run on it without massive
modifications, which I'm not willing to undertake, so I believe I'm now out of the handheld computer
business.  As far as I'm concerned, somebody else can write programs for the miserable things!

I have stopped the development for Windows mobile phones too !!

I just read thru this thread and the SDK stuff has interrested me, but I'm not sure I have understand it totally correctly, so bear with me.
Ive just started to add buttons and textboxes and such in Powerbasic. What I'm wondering is if its simple to move from say "control add textbox" to SDK use instead?
Would it make big difference in speed or coding style? or will it add 'hundred of more lines' of code to a project?

After what I've seen this far of SDK, atleast say using DIrectX requires alot of precode before you can start doing anything thing. Its it the same way with SDK style buttons coding? I'm guessing its not, but would be nice to know.

John,

While SDK coding style would require more lines of code (the first time you write it), it produces faster and smaller EXE/DLL, gives you more control on what is going on, and provides portability of your code between multiple languages.

For example, how would you translate the DDT syntax "control add textbox" if you have no idea on how to use the CreateWindowEx API altogether with the standard "EDIT" class.

Also when using SDK style, nothing will stop you to write your own API encapsulation, and reuse it again and again from an include file or from a custom SLL/DLL, then you could CALL MyEditControl() using parameters as easily than using the DDT syntax.

...

Well, Patrice, I suspect your denigration of PowerBASIC DDT isn't entirely accurate.  SDK coding is "faster" than DDT?  Would you care to document that with some code?

You went on to say "...how would you translate the DDT syntax "control add textbox" if you have no idea on how to use the CreateWindowEx API?"   Perhaps you could explain how you would create an SDK EDIT control in the first place if you don't know the API syntax?  Both would have the identical requirement.  Only by using DDT would you have the advantage of simplicity.

Now, I'm the first to agree that WinAPI coding can be a very valuable technique.  PowerBASIC supports it fully, today, and in the future.  But DDT is just as important for its ease of use and quick-start.  Both have an important place.  So there is really no need to bend the truth to support your position.  It will stand on its own merit.

Best regards,

Bob Zale
PowerBASIC