Why I choose SDK over anything else

[Patrice Terrier]

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.

[Patrice Terrier]

James,

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

Code Select Expand


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

[José Roca]

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.

[José Roca]

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

[James Klutho]

Thanks for your code sample Patrice.

[Patrice Terrier]

James,

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?

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:

Code Select Expand


          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.

[Paul Breen]

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.

[José Roca]

 
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.

[Patrice Terrier]

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

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

[Paul Breen]

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,

[José Roca]

 
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.

[Frederick J. Harris]

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. 

[Ingo Maurischat]

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

[Patrice Terrier]

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.

[José Roca]

 
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.