Powerbasic Museum 2020-B

Because

• SDK is the only way to have direct access to the core Windows API.
• It doesn't use a propriatary syntax nor it hides you what is going on behind the hood.
• It is the only common denominator understood by all compilers including DotNET.
• It keeps your code small and fast.
• It allows you to write procedural code that is not harder to learn than OOP.
• It allows you to use ALL the Windows controls.
• It is easy to use with third party DLL, because DLL are the core meat of SDK.
• It handles ALL the Windows message and structures.
• It is not a dead end, because Microsoft despite what they say is always enhancing it.
• You are no tied to anybody else to write your own controls when you need them.
• There are literally millions of SDK source code examples over the NET.

And last, but not the least, ask you why third party addon providers are only SDK coders.

Patrice Terrier
www.zapsolution.com

You convinced me to go with SDK and abandon DDT.

What about few simple code for SDK UI dummies like me?
Maybe a specific forum for SDK beginners using PB ...?

Ciao
Eros

 
You can start with the Hello World programs here:
http://www.jose.it-berater.org/smfforum/index.php?topic=72.0

And then follow with the Charles Petzold examples:
http://www.jose.it-berater.org/smfforum/index.php?board=5.0

Eros

Do yourself a favor put your hand on Charles Petzold Windows programming book at Microsoft Press.
And I would grant you for the fifth edition if it is still available.

Everything is explained there, with a bunch of C examples, very easy to translate to PB because they are plain SDK, thus the syntax is the same!!!!

Portability is my keyword, avoid propriatary syntax like the plague or accept to become the hostage of somebody else ;)

Patrice,

I have in front of me, exactly Fifth Edition. I was just "ironic" with "dummies like me" :D

In any case your indication is the best one. Many new users will come here in future and for what it is in my possibility I will driven all people approaching PB to José forum.

Ciao
Eros

The single biggest improvement to my programming skills was to learn SDK programming. It was at times a pretty slow process because my knowledge of C was limited at best. I got the Petzold book, Rector & Newcomer, etc... It has taken me several years to finally understand enough of it to beome somewhat proficient. Everyday I browse through chapters in the books and find new things that I didn't know.

The whole process of learning SDK can be overwelming at first - extremely overwhelming. A lot of people don't have the time or patience to learn it in pieces - they want to know it all immediately. My advice, learn the basics about messages and controls, but save the more indepth topics like GDI (DC's, drawing, graphics) for later. It wasn't until I had to write some custom controls or enhance FireFly itself that I really needed to learn GDI stuff.

DDT is very limiting for all but the basic type of applications. Sure, you can get a program up and running quite quickly but when the time comes to do something out of the ordinary (and that time WILL come) then you are usually stuck by a DDT limitation.

The one thing that really bugs me are the people who fear monger that SDK style programming is difficult and should be avoided like the plague.  ::)  The SDK is simply a set of functions pre-built into Windows itself. Why wouldn't anyone want to tap into that? I see many times where people struggle trying to do a simple task using BASIC constructs only to later find out that one or two Win API functions could have replaced their whole code. Don't get me wrong, there are also many examples of BASIC functions that are awkward to code in WinAPI, but unless you are exposed to both types of programming then you can never decide what the best option to choose is.

Bottom line: If you are serious about being a programmer and want to progress your skills then you have to learn SDK style programming (WinAPI). You are limiting yourself if you don't. It will take time, you'll be frustrated as hell, but in the end you'll notice the difference - big time.

Many SDK examples have been posted in 1997-1999 and they are still available in the archive forum, or in POFF.
and POFF is also one of the most valuable place to learn from.

I have for myself provided many SDK examples either on the forum or with the different trial version that can be downloaded from my web site.

However since most new comers were biased with DDT, I stopped posting new SDK examples.

Perhaps we could exhume some good plain SDK examples and post them here in a dedicated SDK section.

Patrice Terrier
www.zapsolution.com

Sounds like a good idea to me.  Why don't you consider it, and tell us what you need or how you want to do it?

I am confused here a bit. MS Vista was delayed because it was totally rewritten as noted after the inner battles between the old school and new school guys at microsoft. Is all that OS  work a layer above the windows api that has been there all along then?

Fortunatly the good old API (name it FLAT API) is still there, buried low in the Windows root.

A good example of that is my GDImage (written with PB) that works like a charm with DotNET applications.

Don

QuoteSounds like a good idea to me.  Why don't you consider it, and tell us what you need or how you want to do it?

That would require a "SDK source code only" dedicated section, and a short explaination to tel us how to upload code there.

I guess time to learn api programming then if it will be here for time to come. That is good to know! Thanks.

I am more than willing to help with SDK examples.

If we can get Dominic on board as well then we would have a great knowledge base to work from.

I have exhumed 2 of my SDK examples to post them here,
when a dedicated "Only SDK source code" section become available.
Also I would like to know what to do, to upload the files there?

Patrice Terrier
www.zapsolution.com

For the people who choose the SDK approach, how do you incorporate dialog boxes?  Do you use DlgEdit etc? Do you use windows with their own message pumps (like Firefly)? Other variations?  Having to deal with the 2 "Window Types" in a typical application has always been a turn off for me in SDK programming.  Though DDT has it's short comings, it's simplicity is a nice.

Do people use SDK for the main loop and DDT for dialogs?

In SDK CreateWindowEx is the masterpiece,
altogether with the WindowProc and of course the message pump.

You shouldn't mix SDK and DDT (CreateDialog) altogether.

The beauty of CreateWindowEx is that it will let you create controls of your own!

CreateWindowEx is the mother's API to everything in Windows world.

James,

Here is how I create a "common" dialog box in GDImage, to display my True Type Font Editor dialog


FUNCTION ZI_FontBox ALIAS "ZI_FontBox" (BYVAL hParent&, zCaption AS ASCIIZ, zUseText AS ASCIIZ, zUseFont AS ASCIIZ, UseSize&, UseARGB&, Use3D&) EXPORT AS LONG

    LOCAL Msg        AS tagMsg
    LOCAL wc         AS WndClassEx
    LOCAL zFontClass AS ASCIIZ * 10

    zFontClass = "zFontBox"
    UseText$ = zUseText
    UseFont$ = zUseFont

    IsInitialized& =  GetClassInfoEx(zInstance, zFontClass, wc)
    IF IsInitialized& = 0 THEN
       wcStyle& = %CS_HREDRAW OR %CS_VREDRAW
       wc.cbSize        = SIZEOF(wc)
       wc.style         = wcStyle&
       wc.lpfnWndProc   = CODEPTR(FontBoxProc)
       wc.cbClsExtra    = 0
       wc.cbWndExtra    = 0
       wc.hInstance     = zInstance
       wc.hIcon         = 0
       wc.hCursor       = LoadCursor(%NULL, BYVAL %IDC_ARROW)
       wc.hbrBackground = GetSysColorBrush(%COLOR_BTNFACE) ' %COLOR_WINDOW
       wc.lpszMenuName  = %NULL
       wc.lpszClassName = VARPTR(zFontClass)
       wc.hIconSm       = %NULL '//3.00 LoadIcon(zInstance, "SIZE16")
       IF RegisterClassEx(wc) THEN IsInitialized& = %TRUE
    END IF

    IF IsInitialized& THEN

       CALL zSetFontBoxData(Button$, UseText$, UseFont$, UseSize&, UseARGB&, Use3D&, hParent&, 1)
       Style& = %WS_OVERLAPPED OR %WS_SYSMENU OR %WS_CLIPCHILDREN
       StyleEx& = 0
       hFontBox& = CreateWindowEx(StyleEx&, zFontClass, _
                               zCaption, _ '// zCaption
                               Style&, _
                               0, _
                               0, _
                               0, _
                               0, _
                               hParent&, 0, zInstance, BYVAL %NULL)

       IF hFontBox& THEN

          CALL SetWindowPos(hParent&, %HWND_TOPMOST, 0, 0, 0, 0, %SWP_NOMOVE OR %SWP_NOSIZE)
          CALL EnableWindow(hParent&, 0) ' Disable Mouse and keyboard input

          CALL ShowWindow(hFontBox&, %SW_SHOW)
          CALL UpdateWindow(hFontBox&)


          DO WHILE GetMessage(Msg, %NULL, 0, 0)
             IF IsDialogMessage(hFontBox&, Msg) = %FALSE THEN
                TranslateMessage Msg
                DispatchMessage Msg
             END IF
             IF Msg.Message = %WM_CLOSE THEN EXIT DO ' Bail out from the message pump

           ' To force redraw of the entered text using the selected gdi+ font
             IF Msg.Message = %WM_CHAR OR Msg.Message = %WM_KEYDOWN THEN
                CALL ZI_UpdateWindow(hFontBox&, 0)
             END IF

          LOOP

          CALL EnableWindow(hParent&, 1) ' Enable Mouse and keyboard input
          CALL SetWindowPos(hParent&, %HWND_NOTOPMOST, 0, 0, 0, 0, %SWP_NOMOVE OR %SWP_NOSIZE)

       END IF

       CALL zSetFontBoxData("", UseText$, UseFont$, UseSize&, UseARGB&, Use3D&, Choice&, 0)

       CALL zSplitColorARGB(UseARGB&, A?, R?, G?, B?)
       IF RGB(R?,G?,B?) = 0 THEN
          UseARGB& = ZD_ColorARGB(A?, RGB(0, 0, 1))
       END IF

       zUseText = UseText$
       zUseFont = UseFont$

       FUNCTION = Choice&

    END IF

END FUNCTION



Note: The EnableWindow that is being used to make the dialog box modal

Quote from: Patrice Terrier on August 02, 2007, 03:58:50 PM
I have exhumed 2 of my SDK examples to post them here,
when a dedicated "Only SDK source code" section become available.
Also I would like to know what to do, to upload the files there?

Patrice Terrier
www.zapsolution.com

I have added a SDK programming board and moved this thread to it. Will add subboards later if needed.

To upload files, when you are in the edit window to post a reply, just click "Additional Options...", located just below the edit window, and then click the Browse button. The open file dialog will appear, allowing you to select the file in your computer that you want to upload. See the attached capture screen.

 
Must add that, excepting some examples in the GDI+ board to show how to use GDI+ with the DDT Graphic Control, all the GUI code that I have posted so far is SDK, and that there is a board called Charles Petzold's Examples (http://www.jose.it-berater.org/smfforum/index.php?board=5.0) where I have posted translated versions of almost all the examples published in Petzold's book Programming Windows, 5th Edition.

So, to date, what is hard to find in this forum is DDT code :)

Thanks for your code sample Patrice.

James,

QuoteFor the people who choose the SDK approach, how do you incorporate dialog boxes?  Do you use DlgEdit etc? Do you use windows with their own message pumps (like Firefly)? Other variations?  Having to deal with the 2 "Window Types" in a typical application has always been a turn off for me in SDK programming.  Though DDT has it's short comings, it's simplicity is a nice.

Do people use SDK for the main loop and DDT for dialogs?

The CreateDialog API (on which DDT is based) is just a subset of the core CreateWindoxEx API, and it is indeed... more restrictive.

If you want to mimic the behavior of a dialog then add this to your message loop:

DECLARE FUNCTION IsDialogMessage LIB "USER32.DLL" ALIAS "IsDialogMessageA" (BYVAL hDlg AS DWORD, lpMsg AS tagMSG) AS LONG

like this:

          WHILE GetMessage(Msg, %NULL, 0, 0)
              IF IsDialogMessage(hMain, Msg) = %FALSE THEN
                 CALL TranslateMessage(msg)                ' Translate The Message
                 CALL DispatchMessage(msg)                 ' Dispatch The Message
              END IF
          WEND


And use the "#32770" class to register your main window form.

Note(s):
- IsDialogMessage can also be used with standard window.
- Avoid mixing SDK and DDT altogether.

If SDK is the way to go, what does PowerBasic bring to the party?
Why Basic and SDK, why not just SDK? Or SDK with ATL, MFC or WTL wrappers?
I agree with the points you make but you don't carry the argument to it's logical conclusion.
I like Basic for text manipulation but I am trying to be rational because I think easy is better than hard.
If you use c you don't have to translate the code at all, just use it.
Visual designers, compilers, debuggers and IDE's that are free and much better than PowerBasic.
Workspace and project support.
Oop if you want it.
Much more free code, not stuck in Windoz($).
Free gui libraries like wxwidgets that work in all the popular operating systems.
Twenty-something keywords vs over six hundred going on seven.
Books in the same language you program in.
If Basic does not make things easier, then why use it? It looks like you have to learn c in order to program PowerBasic in SDK anyway. I am looking at PwrC by Edwin Knoppert to eliminate Pbforms and just use PowerBasic to make dll's for c instead of the other way around.
Open source has taken over the c and cpp development so future compatability does not depend on a crabby old man in Florida looking at retirement.
Having said all of the above, I like Basic but you have me thinking that maybe it is time to reconsider future investments in time.

 
Apparently you don't realize that Patrice and I are old enough to have been skilled programmers long before the first C compilers for PCs did appear. I wrote my first programs for PCs using GW-BASIC, an interpreter, then used MSBASIC, a compiler. The C and Pascal compilers, as well as QBASIC, come later. And once you have been using a language for some years, is more difficult to change. I liked Turbo Pascal, and used it, but I could not stand the syntax of the C compilers.

Anyway, this thread is not about Basic vs C, but about SDK style programming vs proprietary systems, be it called DDT or whatever. If you learn SDK programming, you can use what you have learned with other languages, even assembler. If you compare programs written with PB, C or MASM, using the SDK programming style, you will see how similar they look. If we change of language, we don't need to relearn Windows programming.

QuoteIf you learn SDK programming, you can use what you have learned with other languages, even assembler.

Yes, that is the point, SDK gives you portability and once you learned it, then you learned it for ever, what ever the language being used. And, for me, the BASIC syntax is easier to read and maintain that C code with its many obscurification variation.

The only C syntax I like, is C#, but C# is managed code, and this lead to other problems when mixing with low level programming (because of the framework and the way the GC has been designed), this is the reason why I have never used C# into serious programming (understand commercial projects).  8)

Note: When I need to prototype something very fast, then I use... WinDev (it works great with plain Win32 DLL written with PB)

OK, I guess you are right but I still wish we had namespaces, static binding, modules, iterators & modern stuff like that with the basic syntax.

Are the rules for processes, threads and the window memory architecture the same now as it was for windows 95?
I found the book by Richter "Advanced Windows" circa 1997 (3rd ed) for 1.69$ and the new book (5th ed?) is about 50$. Are the old win95 books better for SDK study? I think the new ones only cover NET.
Will the old book be even better for learning Win32 than the new one? I need to watch the pennies now . I have the Petzold book already.
thanks,

 
I come late to Windows and started with Windows 2000, and regarding Windows books, the only one that I have read is Petzold's Programming Windows. Both Petzold and Richter books use plain C code, that is easier to understand to non C++ (and now .NET) programmers. The only problem is that aren't up to date, but you can complement them with the documentation provided by Microsoft. Anyway, 1.60$ is a truly bargain.

Has anyone taken a look at Mr. Turner's book on Window's programming?  I know I downloaded it couple years back, but I just never got to reading it all.  That might be the closest thing to a real PowerBASIC tutorial.

One of the deciding factors for me in adopting PowerBASIC as my main language is that it doesn't change completely every couple years.  And regarding SDK style programming, Charles Petzold makes the interesting comment in his Windows 95 book that the programs in that book are not very different at all from the ones that would have run on Microsoft's first version of Windows in 1985 or so.  It seems to me then that for folks that got on that band wagon early, they have made pretty good use of their time. 

Of course the Api takes a pretty concentrated effort to learn, but so too does any attempt to master whatever new class library such as MFC or .NET that Microsoft trots out every few years.  At least if you stick to the SDK approach what you learn year after year will be cumulative as you branch into new areas of the Api.  With the class library approach, when the next one comes out you pretty much have to throw away most of what you've learned and start anew.

In terms of the argument as to why bother with PowerBASIC if you code Api style - why not just use C, well, I find I'm considerably more productive with a basic syntax language.  I personally think the whole typedef thing with C/C++ is pretty ridiculous.  I find that it is rare that it catches any coding errors.  It may catch a few here or there, but it isn't worth the effort and miseries and obfusciacations it causes.

Like Patriece says, I am lately just coming to realize what a truely elegant and beautiful thing the Windows Api is.  What has given me that insight is my recent excursions into learning Linux.  So far I have not been able to find anything nearly so elegant as the Windows Api.  Actually, all the Linux GUI toolkits with which I am familiar remind me of PowerBASIC's DDT.  Usually there seems to be functions to create buttons, functions to create labels, functions to create whatever, just like 'Control Add Button', 'Control Add Combobox', etc.  Now, to me that is workable, but not elegant.  What's elegant is a setup like RegisterClassEx() where you specify the general characteristics of some window or control, then use CreateWindowEx() to instantiate an object of that class.  With that one call you can create a pre-defined window such as a lowly label; you can create a top level window of a class you yourself have defined that can contain labels or anything else; and you can create instances of custom controls, ActiveX controls, and even dialog boxes.  Now that is elegant.  To my mind, a full understnding of the elegance of that architecture verges on the intellectual beauty emminent, for example in such a beautiful intellectual creation as calculus or the definition of the derivitive in mathematics. 

Thanks for this very interesting tutorial.

The main problem in SDK Programming is the time. Mostly I'm programming in C on Unix machines.  One day we need quickly a program for Windows. I wrote this program with DDT.  This program had to be finnished within some days, there was no time for the time consuming SDK. Ok there are some limitations, but you can enhance DDT Code with SDK Code ( e.g. handling the data grid ), but I think that DDT is good enough for many tools and programs. My program were used by nearly 20000 users.  ( Inhouse )

But for all that I have to say that your work is absolute fantastic, thanks again.

Ingo

When i realy need to produce something fast, then i am using a true RAD tool with everything built-in: WinDev.
When i want to stress myself with DotNET, then i am using: Visual Studio and C#.
When i want to take full control of my code, then i am always back to plain SDK coding style using my own libraries, and PB.

:)

 
The main problem with DDT is that SDK programmers can't use it. If DDT was a wrapper on top of CreateWindowEx instead of on top of the Windows dialog engine, SDK programmers will use DDT statements when useful, just as they often use OPEN with files instead of CreateFile. Because of this incompatibility, the community is currently split between SDK programmers and DDTers.

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 ;D

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.  :)

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.

Quote from: Norbert Doerre on January 13, 2011, 08:25:43 AM
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.

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.

Quote from: Theo Gottwald on January 13, 2011, 07:57:09 PM
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.

Quote from: Patrice Terrier on December 23, 2009, 04:45:01 PM
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 ;D

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

 ;D

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.

...

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

Quote from: Patrice Terrier on January 14, 2011, 09:14:04 AM
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.

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.

...

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

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  ;D ) 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.

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

I don't see any real problems in dealing with DDT created Dialogs. A window is a window, no matter how it is created.

The API provides all the necessary functions to convert between Dialog Units and Pixels.

When drawing into a Dialog or its controls, any common DC passed from Windows (ie. GetDC) will have the default set to MM_TEXT which is basically pixel mode, so drawing should not be a problem.

I don't see what the problem is here.

DDT is simply a high level wrapper over the Windows Dialog API's, so it isn't doing anything out of the ordinary.

EZGUI uses Dialogs too, except I use a Custom Dialog class, rather than the default class in Windows. Even though internally the API's called require Dialog units for the Dialog (Form) everything else is done using pixels internally. Even controls are created using CreateWindowEx, rather than define them in a Dialog Template.

The mixing of Dialogs which use Dialog Units and the Windows API is not all that difficult. If WinLift can skin an EZGUI app, I see no reason it can't skin a DDT app.

I agree 100% with Chris here. A window is .. a window is .. a window.
Thats what i say. I create a Dialog with DDT and use API to size, to move it, to make invisible or enable it.
I get the CONTROL HANDLE TO h& ... and the Power is mine.

Or lets say like this: I pledge for taking out the best of both worlds.
And of course i vote for a DDT Design thats as much upwards (API-) compatible as possible.

.NET doesn't use twips anymore.

Nowdays, people are using LCD display, and they use them at their highest possible resolution. Well behaved interfaces should be based on anchor properties to change the size and location of child controls when the main window is resized.

Example of anchor properties:
http://www.jose.it-berater.org/smfforum/index.php?topic=3655.msg11844#msg11844

...

WinLIFT skins DDT perfectly, that is not the problem.

...

Theo,

QuoteCONTROL HANDLE TO h&

Try to use cut and past of the DDT syntax into C++ or WinDev, and you will understand why i stay with the strict API syntax.

...

I have downloaded the WINDEV Demo last time when you recomended ist.
I tried 15 Minutes but i did not understand a thing about it.
Maybe I'd first need a cours of 1-2 days how to make the first steps using WinDev - it like another world to me.

Actually I use only PureBasic for x64 and PowerBasic for Programming.
And of course: WinRobots for Scripting.

Theo,

I am not in favor of C++, nor of WinDev, it is just that they are the largest programming platforms.

Tooks me three monthes to get comfortable with the WinDev concept, however i can tell you that i can do things with it, in a fraction of the time it would take me with any other tool.

It is not perfect, not as fast as PowerBASIC, however you can write very large project with it, and it follows the industry standard.

And if you want, you can even write code with it, like this:

wc.cbSize = Dimension(wc)
IsInitialized is int =  GetClassInfoEx(Instance, zClass, wc)
IF IsInitialized = 0 THEN
 wc.style         = wcStyle
 wc.lpfnWndProc   = &WndProc
 wc.cbClsExtra    = 0
 wc.cbWndExtra    = 0 // Extend_cbWndExtra * 4
 wc.hInstance     = Instance
 wc.hIcon         = Null//API(USER32, "LoadImageA", Null, "GoldFish.ico", 1, 0, 0, 0x00000010 + 0x00000040)
 wc.hCursor       = API(USER32, "LoadCursorA", Null, IDC_ARROW)
 wc.hbrBackground = Null
 wc.lpszMenuName  = Null
 wc.lpszClassName = &zClass
 wc.hIconSm       = Null
 IF RegisterClassEx(wc) THEN IsInitialized = True
END

IF IsInitialized THEN
 x = Max((GetSystemMetrics(SM_CXSCREEN) - MyWindow..Width) / 2, 0)
 y = Max((GetSystemMetrics(SM_CYSCREEN) - MyWindow..Height) / 2, 0)
 w = MyWindow..Width
 h = MyWindow..Height
 dwStyle = WS_POPUP|WS_THICKFRAME|WS_CAPTION|WS_SYSMENU|WS_MINIMIZEBOX|WS_MAXIMIZEBOX|WS_CLIPSIBLINGS|WS_CLIPCHILDREN|WS_VISIBLE
 
 hMain is int = CreateWindowEx(  0,          // SDK extended style
 zClass,       // Set this one to your default path name
 MyWindow..Caption,  // Caption
 dwStyle,      // SDK style
 x,          // X location
 -2000,        // Y location
 w,          // Width
 h,          // Height
 0,          // Parent handle
 0,          // Control ID
 Instance,     // Instance
 0)
 IF hMain THEN
     
   SetStaticValue("hMain", hMain)
   
   // Create the GDImage graphic control
   hImageCtrl is int = CreateWindowEx( 0,
   GDImageClassName,
   "",
   WS_CHILD|WS_VISIBLE,
   GraphicControl..X,
   GraphicControl..Y,
   GraphicControl..Width,
   GraphicControl..Height,
   hMain,
   IDC_MAIN_GDIMAGE,
   Instance,
   0)

   // Change the WinLIFT skin theme here:
   sTheme is string
   sTheme = ExePath() + "Naavi.sks"
   
   IF skInitEngine(sTheme, "") THEN
     skSkinWindow(hMain, "Dock|Undock|Minimize|Maximize|Restore|Close")

     // Load animated background.
//      gsUsePlugin = gsPluginPath + "HUD_Beam.dll"
     gsUsePlugin = gsPluginPath + "HUD_Vortex.dll"
     ExeRun(ExePath() + "ZWP.exe " + gsUsePlugin, exeInactive)
     apiSleep(200)
     
     GetWindowRect(hMain, lpw)
     NewW = lpw.nRight - lpw.nLeft
     NewH = lpw.nBottom - lpw.nTop
     
     IF hImageCtrl THEN
       SetStaticValue("hImageCtrl", hImageCtrl)
       skSetAnchorCtrl(hImageCtrl, ANCHOR_HEIGHT_WIDTH)
       // Add a skinned border around the GDImage control.
       skBorder(hImageCtrl, GraphicControl..X - 1, GraphicControl..Y - 1, GraphicControl..Width + 2, GraphicControl..Height + 2, 0, 1)
     END
     
     // Create and skin the zoom slide control.
     IF SplitTemplate(SlideZoom..Name, x, y, w, h, "", "", 0) THEN
       dwStyle = WS_CHILD | WS_VISIBLE | WS_TABSTOP | TBS_VERT | TBS_BOTTOM | TBS_AUTOTICKS
       hCtrl = CreateWindowEx(0, "MSCTLS_TRACKBAR32", "", dwStyle, x, y, w, h, hMain, IDC_MAIN_SLIDEZOOM, Instance, 0)
       skSkinChildCtrl(hCtrl, 0)
       skSetAnchorCtrl(hCtrl, ANCHOR_RIGHT)
       SetStaticValue("HWND_MAIN_SLIDEZOOM", hCtrl)
     END
     
     IF SplitTemplate(BTNSELECT..Name, x, y, w, h, sLabel, sImagePath, dwStyle) THEN
       hCtrl = skButtonImage(hMain, sImagePath, x, y, IDC_MAIN_LOADIMAGE, 5)
       skSetAnchorCtrl(hCtrl, ANCHOR_BOTTOM_RIGHT)
       skCreateTooltip(hCtrl, "WinLIFT ButtonImage")
     END  
     
     // Create and skin the check box composited button.
     IF SplitTemplate(CheckComposited..Name, x, y, w, h, "", "", 0) THEN
       sLabel = "Transparent HUD mode"
       dwStyle = WS_CHILD|WS_VISIBLE|WS_TABSTOP|BS_AUTOCHECKBOX|BS_LEFT|BS_TOP
       hCtrl = CreateWindowEx(0, "BUTTON", sLabel, dwStyle, x, y, w, 18, hMain, IDC_MAIN_CHECKBOX, Instance, 0)
       skSkinChildCtrl(hCtrl, 0)
       skSetAnchorCtrl(hCtrl, ANCHOR_CENTER_HORZ_BOTTOM)
       ZI_UseWinLIFTbackground(hImageCtrl, True, False)
     END
     
     // Create WinLIFT ClockControl, based on template.
     IF SplitTemplate(Clock..Name, x, y, w, h, sLabel, sImagePath, dwStyle) THEN
       hCtrl = skClockCtrl(hMain, sImagePath, x, y, 0, 0, IDC_MAIN_CLOCK, 0x7FCB0000, 0x7F8F8F8F, 0)
       // Anchor the button to bottom left.            
       skSetAnchorCtrl(hCtrl, ANCHOR_BOTTOM)
       skCreateTooltip(hCtrl, "WinLIFT clock control")
     END
     // Create WinLIFT LeftKnobControl, based on template.
     IF SplitTemplate(KnobLeft..Name, x, y, w, h, sLabel, sImagePath, dwStyle) THEN
       hCtrl = skKnobGauge(hMain, (sImagePath), x, y, 0, 0, IDC_MAIN_KNOBLEFT, 0, 0, 0, 0)
       // Anchor the button to bottom left.            
       skSetAnchorCtrl(hCtrl, ANCHOR_CENTER_HORZ_BOTTOM)
       skCreateTooltip(hCtrl, "WinLIFT knob gauge")
       SetStaticValue("HWND_MAIN_KNOBLEFT", hCtrl)
     END
     // Create WinLIFT LeftKnobControl, based on template.
     IF SplitTemplate(KnobBig..Name, x, y, w, h, sLabel, sImagePath, dwStyle) THEN
       hCtrl = skKnobGauge(hMain, (sImagePath), x, y, 0, 0, IDC_MAIN_KNOBBIG, 0, 0, 0, 0)
       // Anchor the button to bottom left.            
       skSetAnchorCtrl(hCtrl, ANCHOR_CENTER_HORZ_BOTTOM)
       skCreateTooltip(hCtrl, "WinLIFT knob gauge")
       SetStaticValue("HWND_MAIN_KNOBBIG", hCtrl)
     END
     // Create WinLIFT RightKnobControl, based on template.
     IF SplitTemplate(KnobRight..Name, x, y, w, h, sLabel, sImagePath, dwStyle) THEN
       hCtrl = skKnobGauge(hMain, (sImagePath), x, y, 0, 0, IDC_MAIN_KNOBRIGHT, 0, 0, 0, 0)
       // Anchor the button to bottom left.            
       skSetAnchorCtrl(hCtrl, ANCHOR_CENTER_HORZ_BOTTOM)
       skCreateTooltip(hCtrl, "WinLIFT knob gauge")
       SetStaticValue("HWND_MAIN_KNOBRIGHT", hCtrl)
     END

     // Create and skin the check box visual plugin button.
     IF SplitTemplate(SEL_Plugin..Name, x, y, w, h, "", "", 0) THEN
       sLabel = "Vortex"
       h = h / 2
       dwStyle = WS_CHILD|WS_VISIBLE|WS_TABSTOP|BS_AUTORADIOBUTTON|BS_LEFT|BS_TOP
       hCtrl = CreateWindowEx(0, "BUTTON", sLabel, dwStyle, x, y, w, 18, hMain, IDC_VORTEX, Instance, 0)
       SendMessage(hCtrl, BM_SETCHECK, BST_CHECKED, 0)
       skSkinChildCtrl(hCtrl, 0)
       skCreateTooltip(hCtrl, "Visual plugin")
       skSetAnchorCtrl(hCtrl, ANCHOR_CENTER_HORZ_BOTTOM)

       sLabel = "Laser beam"
       dwStyle = WS_CHILD|WS_VISIBLE|WS_TABSTOP|BS_AUTORADIOBUTTON|BS_LEFT|BS_TOP
       hCtrl = CreateWindowEx(0, "BUTTON", sLabel, dwStyle, x, y + h, w, 18, hMain, IDC_LASER_BEAM, Instance, 0)
       skSkinChildCtrl(hCtrl, 0)
       skCreateTooltip(hCtrl, "Visual plugin")
       skSetAnchorCtrl(hCtrl, ANCHOR_CENTER_HORZ_BOTTOM)  
     END

     // Create and skin the check box visual plugin button.
     IF SplitTemplate(CheckPlugin..Name, x, y, w, h, "", "", 0) THEN
       sLabel = "Visual plugin"
       dwStyle = WS_CHILD|WS_VISIBLE|WS_TABSTOP|BS_AUTOCHECKBOX|BS_LEFT|BS_TOP
       hCtrl = CreateWindowEx(0, "BUTTON", sLabel, dwStyle, x, y, w, 18, hMain, IDC_MAIN_PLUGIN, Instance, 0)
       skSkinChildCtrl(hCtrl, 0)
       skCreateTooltip(hCtrl, "Enable/disable visual plugin")
       skSetAnchorCtrl(hCtrl, ANCHOR_CENTER_HORZ_BOTTOM)
     END
     
     // Start with the default picture.
     sResource is string = ExePath() + "Resource\"
     sUsePhoto is string = sResource + "Naavi.png"
     UseThisPhoto(sUsePhoto)
     
     // Add a transparent logo on the top right corner.
     sUsePhoto = sResource + "GDImage.png"
     // Load image and retrieve the width and height of its bitmap.
     hBitmap is int = ZI_CreateBitmapFromFile(sUsePhoto, w, h)
     // Use the new hBitmap to create a sprite image on the top right corner.
     ZD_DrawBitmapToCtrl(hImageCtrl, GraphicControl..Width - (w + 10), 10, hBitmap, ZD_ColorARGB(255, 0), ID_LOGO, ZS_VISIBLE)
     // Anchor the logo to the top right corner.
     ZD_SetObjectAnchorMode(ID_LOGO, ANCHOR_RIGHT)
     // Lock and disable the sprite image.
     ZD_SetObjectLocked(ID_LOGO, True)                
   END
   
   ShowWindow(hMain, SW_SHOW)
   
   // Create a fall down effect animation.
   x = Max((GetSystemMetrics(SM_CXSCREEN) - MyWindow..Width) / 2, 0)
   y = Max((GetSystemMetrics(SM_CYSCREEN) - MyWindow..Height) / 2, 0)
   w = MyWindow..Width
   h = MyWindow..Height
   dwStyle = RDW_INVALIDATE|RDW_INTERNALPAINT|RDW_ERASE|RDW_ERASENOW|RDW_UPDATENOW|RDW_ALLCHILDREN|RDW_FRAME
   ShowWindow(hImageCtrl, 0)
   FOR k = -h TO -1  STEP 8
     MoveWindow(hMain, x, k, w, h, 1)
     RedrawWindow(hMain, Null, 0, dwStyle)
   END
   ShowWindow(hImageCtrl, SW_SHOW)
   FOR k = 0 TO y
     MoveWindow(hMain, x, k, w, h, 1)
     RedrawWindow(hMain, Null, 0, dwStyle)
   END
   ShowWindow(hMain, SW_HIDE)
   x = Max((GetSystemMetrics(SM_CXSCREEN) - NewW) / 2, 0); y = Max((GetSystemMetrics(SM_CYSCREEN) - NewH) / 2, 0)
   MoveWindow(hMain, x, y, NewW, NewH, 0)
   ShowWindow(hMain, SW_SHOW)

 
   // Main message pump.  
   WHILE GetMessage(Msg, Null, 0, 0)
     TranslateMessage(Msg)
     DispatchMessage(Msg)
   END


     WP_Destroy()
   
   nRet is int = Msg.wParam    

;D

Quote from: Patrice Terrier on January 14, 2011, 09:36:43 PM
.NET doesn't use twips anymore.

That may be true, but twips have nothing to do with Dialog Units.  A twip is simply:   Inch / 1440.  No more.  No less.

Bob

Quote
Well behaved interfaces should be based on anchor properties to change the size and location of child controls when the main window is resized.

I agree, which is why I added this feature to EZGUI 5.0.

Just a comment about dot.net ...

Dot.net is in a sense a "wrapper" over the Windows API. WinForms in dot.net (and WPF) are wrappers over the API to supposedly make programming easier. I was reading some interesting articles lately, and IMO Microsoft has simply been trying different wrappers over the API over the years simply because they felt working with the API directly was to difficult. Thats why they created MFC. WinForms (in dot.net) was suppose to replace MFC. WPF is suppose to replace WinForms from what I have read.

The point is that Microsoft keeps trying to add layers to the operating system to supposedly make programming easier.

If Microsoft can build wrappers over the API to make things easier, I don't see why DDT should be viewed any differently. Obviously pure SDK style coding is not what Microsoft feels is best. They wrote Windows and they feel working purely at the API level is not easy.

I may have taken a different approach from Powerbasic on how to design a higher level wrapper over the API, but I agree with them that such a set of wrappers is necessary for PB.

QuoteA DLU is based on the size of the dialog box font, normally 8-point MS Sans Serif. A horizontal DLU is the average width of the dialog box font divided by four. A vertical DLU is the average height of the font divided by eight.

I want my button to be 20 dialog units from the top, and 8 d.u. from the left.
After resize, WM_SIZE gives you the size in pixels, with d.u. to get the position right, the values need to be scalled, and this means extra computation.
With modern Themed interface, DLU has been left out in favor of the use of pixels and anchor properties.

I have even added myself anchor properties inside of my graphic GDImage control, to allow the resizing of sprites and widget, on the same principle than Visual Studio and WinDev are doing for child controls when designing a new interface. Indeed a GDImage control could be used to build a complete interface, because there is no difference between a window and a GDImage graphic layer object.


Chris,

QuoteIf Microsoft can build wrappers over the API to make things easier, I don't see why DDT should be viewed any differently.

Because they are Microsoft.
Now ask yourself what would happen to your users the day you are out of buisiness.
And if they want to get retired, do you think they will be able to sell their source code to anybody else?

When you write DLLs to achieve specific tasks, things are different, because if GDImage or WinLIFT come to an end, you will always find other DLLs to replace them, but what if the runtime itself disappear.

Only Microsoft can take the decision to stop VB without too much prejudice for themselves, but for their users it was an extreme prejudice.

This is the main reason "Why i choose SDK over anything else"  ;D


...

Microsoft designs code wrappers - That is good.
Microsoft designs Dialog Units - That is good.
PowerBASIC uses Microsoft-Designed Dialog Units as one option - That is bad.

Is there some problem with this logic?

Bob Zale

Quote from: Patrice Terrier on January 15, 2011, 09:38:16 AM
I want my button to be 20 dialog units from the top, and 8 d.u. from the left.

Here's the secret ingredient...   Call GetClientRect() on the dialog in question (That's a Windows API function for those not familiar).  It returns the size of the Dialog Client Area in pixels.  Use that size as the basis for everything else you do on that dialog for the duration of the program.  You never, ever have to use Dialog Units for any other purpose.  Not even once.

Of course, if you do this, you won't be able to complain about PowerBASIC. <<g>>  That would be really disappointing!

Bob Zale
PowerBASIC Inc.

Bob,

I like your compiler, and i wrote many times that it is my favorite one.

However, i feel free to express myself in my dedicated section, and people coming here are also free to express their own.

PB10 seems to have some very nice new features, and i hope that 64-bit will be next on the list.

...

quote ----IF pixel would have been the default then i probably wouldn't care.

You can make a DDT program. Starting with DIALOG NEW PIXELS, hParent, "Dialog1", 520, 262, 302, 197, TO hDlg  Have all your children in pixels as well. So it is an option with DDT to use DLG units or Pixels....    ???

Beside rather than beating up DDT ask for a CreateWindow - CreateWindowEx DCWT wrapper or something and present the positive reasonings.
Why it should be put in PB and the benefits you feel.

Or make your own wrapper ?


Or make a ddt to CreateWindow  tool.... you would have to fill in a few blanks after the conversion would save a lot of time no ?

I like that Bob follows our discussion, but i really prefer to hear something from him about PB 10.
To me it doesn't make sense to warm up the old discussion about the "Kings beared" once more.

While he could tell us news about PB 10 and when he believe it could be available!

@Bob i hope you enjoy the staying in Jose's Forum and use it for your relaxation and to collect new power for the big thing you have in the box in front of yours. Which is hopefully soon ready.

Because we all know there are many out there waiting for it to be available.
And they hope it will be as good and as stable and as bug free as any PB Version before.

Which is going to be difficult if not impossible,
because i believe that this time we will be having the most complex PowerBasic ever!

About the wrappers. Thanks Jose, they will be available. Take a look, thousand of them!
http://www.jose.it-berater.org (http://www.jose.it-berater.org/smfforum/index.php?topic=3958.msg13461;topicseen#msg13461)

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. (http://www.jose.it-berater.org/smfforum/index.php?topic=1129.0)

If you want to speak about PowerBASIC new features and/or DDT, then this thread is more appropriate:
PowerBASIC 10 (http://www.jose.it-berater.org/smfforum/index.php?topic=3958.0)

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.  8)

...

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

Bob,

I am not bending the truth, this thread is entitled "why i choose SDK over anything else"

I can't see any denigration, i just wrote SDK produces faster and smaller EXE/DLL, that's a fact (and this is also true with the C++ runtime, managed code, and WinDev).

PowerBASIC programmers have the choice to use either the DDT encapsulation, or direct call to the core API.

You give us the choice, and that is fine thank you.

...

I like the power of SDK, but also like simplicity. Therefore, currently I'm using my own wrappers and classes. For GUI programming, the main class is CWindow, that is Ansi, Unicode and High DPI aware, and 100% SDK compatible.

A simple example with a text box and a button:


#COMPILE EXE
#DIM ALL
%UNICODE = 1

' // Include files for external files
#INCLUDE ONCE "CWindow.inc"   ' // CWindow class

%IDC_TEXTBOX = 101

' ========================================================================================
' Main
' ========================================================================================
FUNCTION WinMain (BYVAL hInstance AS DWORD, BYVAL hPrevInstance AS DWORD, BYVAL lpszCmdLine AS WSTRINGZ PTR, BYVAL nCmdShow AS LONG) AS LONG

   ' // Set process DPI aware
'   SetProcessDPIAware

   ' // Create an instance of the class
   LOCAL pWindow AS IWindow
   pWindow = CLASS "CWindow"
   IF ISNOTHING(pWindow) THEN EXIT FUNCTION

   ' // Create the main window
   pWindow.CreateWindow(%NULL, "CWindow Test", 0, 0, 0, 0, 0, 0, CODEPTR(WindowProc))
   ' // Set the client size
   pWindow.SetClientSize 500, 320
   ' // Center the window
   pWindow.CenterWindow

   ' // Add a text box control
   pWindow.AddTextBox(pWindow.hwnd, %IDC_TEXTBOX, "This is a textbox", 150, 100, 200, 23)

   ' // Add a button
   pWindow.AddButton(pWindow.hwnd, %IDCANCEL, "&Close", 350, 250, 75, 23)

   ' // Default message pump (you can replace it with your own)
   pWindow.DoEvents(nCmdShow)

END FUNCTION
' ========================================================================================

' ========================================================================================
' Main callback function.
' ========================================================================================
FUNCTION WindowProc (BYVAL hwnd AS DWORD, BYVAL uMsg AS DWORD, BYVAL wParam AS DWORD, BYVAL lParam AS LONG) AS LONG

   ' // Process window mesages
   SELECT CASE uMsg

      CASE %WM_COMMAND
         SELECT CASE LO(WORD, wParam)
            CASE %IDCANCEL
               ' // If the Escape key has been pressed...
               IF HI(WORD, wParam) = %BN_CLICKED THEN
                  ' // ... close the application by sending a WM_CLOSE message
                  SendMessage hwnd, %WM_CLOSE, 0, 0
                  EXIT FUNCTION
               END IF
         END SELECT

      CASE %WM_DESTROY
         ' // End the application
         PostQuitMessage 0
         EXIT FUNCTION

   END SELECT

   ' // Pass unprocessed messages to Windows
   FUNCTION = DefWindowProc(hwnd, uMsg, wParam, lParam)

END FUNCTION
' ========================================================================================


José,

Yes, that is a good example of the power offered by SDK coding style.
Wrinting our own encapsulation without any limitation, gives us the control on everything.

Also SDK is a must, to write small and fast low level addon DLLs. 

...

QuoteI'm just showing the facts. Pure SDK is harder to use but produces faster and smaller executables

José Roca

This thread is almost 5 years old and has been read almost 15000 times!

I made the big jump myself, at the time of PBDK, if this is something you can remember :)

Hello property still someplace the disk lie around of PBDK. Anybody needs the disk? :)

Windows via Interrupt! ;D

Greetings Peter

That was a very sad news, and i think many will felt abandoned, fortunatly SDK coders will survive.

Thank you Bob for your invaluable contribution to the programming community.

Hello I thinks that also the very bad one news is!

A black day for the Basic world! :'(

Remembers that Bob would be happy who the PowerBASIC project was continued!

Peter,

With such a strong personnality Bob had, i wonder who could take up on his work...

There will be a gap of course. Always when a strong personality leaves there is a gap.

A gap in competence and more important a gap in Leadership.

There is always a risk that the successors have different ideas and split or fight each other.
And if such happens, the gap can not be filled, and the ship will possibly sink.

In this case the only sollution is, to have one person to clearly have the last word and say where the boat should drive.
To just fill the gap as good as possible. And keep the boat swimming. Any clear direction will be Ok at this time.

Personally i think - but this only an assumption - that even with PB 10 there have been other programmers been involved.

I further assume that Bob could organize what happens next, so i hope they will now be strong and unique.
And keep the boat swimming.
I also believe that this is what Bob would expect of them.
They should not look back to much, but keep his boat in the wind, trying to make things as they expect he would have done them.
And especially be unique and stay together in this hard time.

At a later time they will get the chance to grow in new directions, if they pass this hard time and stay strong.

Theo,

I think you are very optimistic...

I had the dream that PB11 will allow me to create a 64-bit version of my WinLIFT/GDImage with just a {simple} recompile.
But i will probably have to refurbish my VS2010, in order to have it, and this means so much extra work in perspective.

However i think my situation is better than DDT users, and other third party addon providers.

...

¿A simple recompile? The headers need to be changed as well as all these LONG and DWORD variables used to hold values such pointers and handles. Also the alignment on many of the structures and some other things.

José,

Yes i know that, and this is the reason why i enclosed the word "simple" with braces {} ,
but anyway so much simple than to convert all my PB code to C or C++.

:)

It should be possible to produce 32/64 bit cross-compatible headers for PB.

In OxygenBasic I use a type called sys which automatically changes from 32 bits to 64 bits according to compilation mode.

For example:


  type WNDCLASSEX
  int cbSize
  int Style
  sys lpfnwndproc
  int cbClsextra
  int cbWndExtra
  sys hInstance
  sys hIcon
  sys hCursor
  sys hbrBackground
  sys lpszMenuName
  sys lpszClassName
  sys hIconSm
  end type


Alignment is internally adjusted so that 64 bit types are aligned to the next 64bit boundary.


Charles

Charles,

WinDev does exactly the same:
nInt is system int = 0 // adjust the size automatically to 4 bytes in 32-bit, and 8 bytes in 64-bit
and the alignment works the same as you describe.

And when using the system keyword, the only thing i have to do, is to select the platform for which i want to produce the new EXE.

That's really simple, isn't it ?

Another great thing i like with WinDev, is the fact that it is able to produce code either for Windows, Android, or Mac OS (with some restrictions).
All you have to do is to use the WLanguage (it looks almost the same than PowerBASIC), and when {compiling} for the Android or the Mac platform, it is turned automatically into Java code on the fly...

By the way i love my new Android Galaxy TAB2 10.1 tablet  :)

Hi Patrice,

Producing compiled code to run on tablets and other devices, poses a few problems. Emitting C source code seems to be the most practical solution for universal compatibility - so I am gradually heading in this direction.

I wonder if Tablets, with their low-powered ARM-based processors will eventually displace the PC.

Charles

QuoteI wonder if Tablets, with their low-powered ARM-based processors will eventually displace the PC

Charles,

I must say that i am realy amazed by the speed and the very small size of the Android applications, and also by the speed of the WiFI connection that is much faster than on my quad core i7 ASUS PC.

I can also play full HD movies directly from a very small 16Gb micro SD (with a 10 speed indice) without any problem and perfect audio sound quality.

...

I think they have hard coded many of the intensive operations into silicon - especially on the video/graphics side. Ypu can see that Intel's aspiration to make the Pentium a do-everything processor has been overtaken in recent years. It has become a huge and hungry beast constrained by its ancient lineage  :)


(http://t3.gstatic.com/images?q=tbn:ANd9GcTt7Tj9DbgqxIQ-d43_B044Yrn3b1EneAMDDK2ZN5mwkYMzyQlR)