Why I choose SDK over anything else

[Patrice Terrier]

Another big issue with DDT, is its default use of the obsolete DIALOG UNITS instead of PIXEL, making it a real nuisance and extra work to let it work with a SkinEngine

[Jeff Blakeney]

My problem with DDT is that it is included as part of the PowerBASIC language instead of being an add on product.  If it makes writing Windows programs so much easier then why not make it available as a DLL or something so that it can be used by more than just PB users?  This would also make it available to PBCC users and not just PBWIN users (why there are two different compilers in another issue).

I've used DDT for some simple programs but almost always still had to include some API calls to get things working properly.

One thing I don't like about DDT is the fact that the creation of every dialog in your program is in your main executable file and none of it goes into the resource fork.  This means a DDT program will take longer to load from disk and will use more RAM than the equivalent program written using the API and storing stuff in the resource fork.

I don't see creating a program the API way being any slower than using DDT especially if you use a form designer for both.

PB has a program, that seems to have been forgotten about, called PowerGEN.  It can generate API code for the stuff stored in a .rc file and you can even tell it that a certain button or menu item generates an event and then you can have dialogs open when different event occur.  So, with no coding of your own, you can create your .rc file, with dialogs, menus and such, then run PowerGEN and have it create code that you can compile and immediately have things happen like opening other dialogs when you click a button or select a menu item.  Then all you have to do is add the code to actually do something. 

My brother is reluctant to deal with the Windows API but he doesn't seem to have any problem with spending tons of time trying to figure out how to use someone's ActiveX control, DLL, souirce code or even another language that might make dealing with certain things easier.  I don't quite understand that mentality.  I'm quite happy to be using PB and to continue learning how to do stuff on my own with the tools that are available.  Heck, I'm even creating my own tools. 

[Norbert Doerre]

Projecting Microsoft's intentions over a long time distance since the early 80s we should consider that in near future programming with this OS might become limited only to certified external programmers who will no more have access to the windows API but only to an MS moderated kind of new .net language. Times of free programming will soon be finished because MS wants to integrate their OS into any lucrative platform of mass hardware. Already today we can see some "modern" programs designed to only show a user puzzle with a garbage of pictures only showing our small handy's screen on a 24" display.
To take part in this the new age of programming will cost a lot of money fpr programmes, and we would only be able to take a step towards this money making macro coding industry if we could convince MS that everything is programmed with their own tools we have to pay lots of fees for.

Nevertheless, i still love to program cad software via api, even including asm to achieve fast iterating routines. But I fear that with the the end of the age of my generation this playground and depthness of coding will be over. I still do it in my old ways because i'm not interested in envelopes but in their content.

[Mike Stefanik]

Times of free programming will soon be finished because MS wants to integrate their OS into any lucrative platform of mass hardware. [...] To take part in this the new age of programming will cost a lot of money fpr programmes, and we would only be able to take a step towards this money making macro coding industry if we could convince MS that everything is programmed with their own tools we have to pay lots of fees for.

I'm not really sure what you're talking about here. Microsoft provides a complete development toolchain for Windows at no cost; the Windows SDK includes compilers and you can get the Visual Studio IDE for free with one of the Express Editions. So what "fees" are you talking about here? Yes, there's expensive versions of Visual Studio but those aren't designed for individual developers or small, independent software houses with just a few programmers. If anything, the trend in the past few years has been exactly the opposite of what you're saying, with more tools being made available at a very low (or no) cost to developers.

So let's not spread FUD here. There's been no indication that Microsoft is planning to eliminate access to the core API or prevent use of third-party development tools with their desktop platforms.

[Theo Gottwald]

I think the other way is more what MS is going to.
After the strict Activiation in WinXP they have realized that they loose more and more market to LINUX.
I think they will turn the wheel a bit back in their own interest.

[Mike Stefanik]

After the strict Activiation in WinXP they have realized that they loose more and more market to LINUX.

And they really haven't lost much marketshare to Linux in the desktop space at all; Windows is still has over 90%, Mac OS X is around 5% and and Linux is still at around 1%. Where Microsoft is not doing well at all is the mobile marketplace, which is dominated by Android and iOS. We'll see if they're able to turn things around, but they really haven't been able to find their footing there. Perhaps that'll change now with their decision to port Windows to the ARM Cortex processors.

[Bob Zale]

Another big issue with DDT, is its default use of the obsolete DIALOG UNITS instead of PIXEL, making it a real nuisance and extra work to let it work with a SkinEngine

You know, Patrice, I have to admit it...   For years, we've been trying to hide it from you, but it looks like you were just too smart for us.  Those darn Dialog Units are the default -- and if you want to change it to pixels, you have to type 6 new letters, and a comma, too!  But I think we have a solution!  We're going to build in the macro "P", which auto-expands to "PIXELS,"!     <g>

Bob Zale

[Paul Squires]

 

[Patrice Terrier]

Bob,

Re-read my post from December 2009, and you will see that i am refering to the use with a SkinEngine.

WinLIFT is not able to change anything in a code that has been already written, because it customizes the existing EXE on the fly.

If DIALOG UNITS have been used, there is no way for me to edit the code, resize and allign the controls, then recompile...

The only thing i can do, is to deal with the existing EXE from my best.

...

[Bob Zale]

I'm afraid I don't see it as a problem.  But it's your software and your opinion, whether it's 2009 or 1989.  Do what's best for you and yours.

As to the "...Obsolete Dialog Units...", I guess I didn't get that memo from Ballmer.  I think they can be pretty handy for certain types of applications.  To each his own.

Regards,

Bob Zale

[Bob Zale]

If DIALOG UNITS have been used, there is no way for me to edit the code, resize and allign the controls, then recompile...

That's interesting...

If PIXELS have been used, can you edit the code, resize and align the controls, then recompile?

Bob Zale
PowerBASIC Inc.

[Patrice Terrier]

Bob,

Correct you are, in either case i am dealing with the EXE.

However, when changing from twips to pixels, there is a lot of editing because size and location are not the same, thus a macro won't be of any help to change them.

I think new DDT users must be warned that the low level API works with pixels exclusively.

And because this thread is entitled "Why I choose SDK over anything else", i am just expressing here my personnal opinion.

...

[Bob Zale]

Well, my basic point here is that once you convert the initial sizes from dialog units to pixels, you're pretty much done.  Every other operation could use pixels after that.  The whole point of dialog units is to just give you a pleasing dialog size on a variety of monitors.  Once the ratio is established, it remains a constant forever.

Bob

[Theo Gottwald]

I believe we will not get perfect matching positions on this topic today, maybe also not this week.
What i can say is that i want to choose PB 10 (while not because of DDT   ) over any other compiler out there.

I'd also love if it could do such phantastic designs like Patrice is doing with his DLL's,
but this will stay a dream for a while.

We all know that DDT is a integral Part of PowerBasic and will be.

We also know that besides the "Pro's" who may also work with other compilers, and prefer using SDK, there are a lot of people who prefer DDT.

Also we know that it's not likely that any of these facts is going to change soon.
Some of the DDT commands are somehow just API calls behind (IsWindow()) etc.

They're good as first steps and they may have their fans as SDK also has fans.

So my opinion is that for small programms that need quickly beeing ready i use DDT.
While for complicated projects i prefer SDK style.

But often enough i find myself mixing around and i had never had problems with this.
At least I know now that when i need to use Patrice's Tools, then i will have to stay with DIALOG PIXEL or use SDK.

[Bob Zale]

Actually, Theo, you'll have to give up using any Dialogs at all.  Dialogs can only be created using Dialog Units.  Once created, you can interrogate them to determine the size in pixels, and you can do anything else you like in pixels.  Dialogs are sized by Windows using the monitor info and the default font info, so as to give them a pleasant appearance across various platforms.  A very good idea...   and hardly obsolete.

Best regards,

Bob