Announcement

Collapse
No announcement yet.

DDT vs Graphic Window

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • DDT vs Graphic Window

    I've just started working with PB and need a clarification of a DDT vs a graphics window. Is it the case that a DDT cannot contain an image (other than by using an image control) and that you cannot print to a DDT?

    Also, is it true that graphic windows cannot control controls?

    It's not clear why there is a need for both types of windows if a DDT could contain an image.

    Thanks,
    Gary

  • #2
    Originally posted by Gary Beene View Post
    I've just started working with PB and need a clarification of a DDT vs a graphics window. Is it the case that a DDT cannot contain an image (other than by using an image control) and that you cannot print to a DDT?
    no, you can put an image on a DC (Device Context, q.v.) and (I'm guessing here!) any visible window has a DC. The difference with a GW is that inside your application, a tiny team from PowerBasic Inc does all the repainting of the window so that you do not have to look after the WM_PAINT and WM_ERASEBKGND messages.

    Originally posted by Gary Beene View Post
    ...is it true that graphic windows cannot control controls?
    Not quite sure what you mean by "control controls", but you cannot put Windows controls, which are child windows themselves, on a GW. Although, I understand that each GW is in fact a dialog coupled to a custom window class on which the images are drawn, but, as with your rhinocerus, I would hate to get between the GW and its parent.

    Originally posted by Gary Beene View Post
    It's not clear why there is a need for both types of windows if a DDT could contain an image.
    My guess is that it is because whatever you put on a GW's DC (by whatever means, GRAPHIC statements or SDK style drawing on the DC) is persistent, which just makes life easier.

    Comment


    • #3
      Originally posted by Gary Beene View Post
      I've just started working with PB and need a clarification of a DDT vs a graphics window. Is it the case that a DDT cannot contain an image (other than by using an image control) and that you cannot print to a DDT?
      Hi Gary--

      There is no single item called "A DDT". DDT is the entire system of dialogs and controls in PowerBASIC. The easiest way to display an image on a dialog is with an IMAGE CONTROL. If you want to add text, graphic primitives, or more, to that control, then you'd generally use a GRAPHIC CONTROL or even a GRAPHIC WINDOW (which would be completely separate from the dialog). You can add many other controls to the dialog to provide other services, as needed.

      Best regards,

      Bob Zale
      PowerBASIC Inc.

      Comment


      • #4
        Sorry, but I was careless in the wording of my post. By DDT I meant to refer to a dialog window.

        I was trying to understand when a GRAPHIC WINDOW was appropriate, rather than a image/graphic control on a dialog. I can imagine uses for a GRAPHIC WINDOW but don't know if my imagination matches the PB/Win intent of having the capability.

        It wasn't clear to me whether a dialog can have a picture in it, have graphic primitives drawn on it, or allow printing directly to it - in the same way that VB6 forms supports such operations, including being able to put controls in the dialog over the picture. If a dialog does not support images/graphic primitives, then that explains the need to have a GW.

        Chris' comment about a GW not being able to contain Windows controls answers part of the question. And I'm assuming from Bob's response that dialogs do not support images/graphics primitives/printing.

        Thanks for your responses. I'm enjoying the get-acquainted phase with PB/Win!

        Gary

        Comment


        • #5
          Originally posted by Gary Beene View Post
          I was trying to understand when a GRAPHIC WINDOW was appropriate, rather than a image/graphic control on a dialog. I can imagine uses for a GRAPHIC WINDOW but don't know if my imagination matches the PB/Win intent of having the capability.
          I'm not 100% sure I'm right in this case but in general compilers provide a lot of different ways to do the same thing so we can pick the one that works best in any given situation. I suspect that's the case with DDT having both a graphic control and a graphic window. They're there so we can pick the one we think is the best fit for what we're doing.

          Barry

          Comment


          • #6
            In the Help file, under the GRAPHIC ATTACH statement topic, it says that the hWin argument is "Handle of the GRAPHIC WINDOW, DIALOG, OR BITMAP ..."

            I've tried to use the GRAPHIC ATTACH to a DIALOG and get no compile error, but none of the GRAPHIC methods I tried (such as PRINT) seems to work.

            So, I'm definitely unsure if a DIALOG is supposed to work with graphics. The Help says so, but I'm looking for an example to confirm it.

            Barry, thanks for your comment. I'm still unsure of when a GW is the best answer as opposed to another DIALOG. It does seem easier to pop up a GW, but beyond that I don't know enough yet about PB to know any other reason to use a GW. I'll be playing with it for the next day or so and see what I can come up with.

            Regards,
            Gary

            Comment


            • #7
              Originally posted by Gary Beene View Post
              And I'm assuming from Bob's response that dialogs do not support images/graphics primitives/printing.
              No, you can draw on a dialog's DC too, but that is done by using Windows API functions (in other words a SDK technique). For more information, you do a lot worse than to start with Chris Boss's 101 here.

              You can also mix DDT and SDK techniques, accepting the limitations of this approach as many PowerBasic programmers do. For more information, search this forum!

              For example, you could declare a dialog DDT-style then write on it SDK style, as in the compileable example (V8.04) below. :

              Code:
              ' to show drawing direct on a dialog's DC
              ' Chris Holbrook 26 Dec 2008
              #compile exe
              #dim all
              #include "WIN32API.INC"
              %IDD_DIALOG1 = 101
              '---------------------------------------------------------
              callback function ShowDIALOG1Proc()
                  local ps as paintstruct
                  local x, y as long
              
                  select case as long cbmsg
                      case %WM_PAINT
                          beginpaint cbhndl, byval varptr(ps)
                              movetoex ( ps.hdc, 0, 100, byval %null)
                              for x = 0 to 400 step 12
                                   y = sin(x)*50 + 100
                                   lineto (ps.hdc, x, y)
                              next
                          endpaint   cbhndl, byval varptr(ps)
                  end select
              end function
              '---------------------------------------------------------
              function pbmain()
                  local lRslt as long
                  local hDlg  as dword
              
                  dialog new %HWND_DESKTOP, "Drawing on a dialog           Chris Holbrook Dec 26 2008", _
                      159, 177, 268, 121, %WS_SYSMENU,,to hdlg
                  dialog show modal hDlg, call ShowDIALOG1Proc to lRslt
                  function = lRslt
              end function

              Comment


              • #8
                Originally posted by Gary Beene View Post
                In the Help file, under the GRAPHIC ATTACH statement topic, it says that the hWin argument is "Handle of the GRAPHIC WINDOW, DIALOG, OR BITMAP ..."
                I believe it actually says:

                hWin:Graphic window, bitmap, or control to be used with GRAPHIC statements

                A dialog is commonly described as a "container for controls", so that's usually the best approach. Create a Graphic Control (even if it's as large as the entire dialog), place it on the dialog, then write to it with Graphic statements.

                Bob Zale
                PowerBASIC Inc.

                Comment


                • #9
                  In the PB\Samples\DDT\Graphic subdirectory there is a program called boltcalc.bas.
                  This might show you some of what you're looking for.
                  If you have PBForms, in the Sample directory there is a graphics.bas which shows the usage of some of the graphic tools.
                  Rod
                  In some future era, dark matter and dark energy will only be found in Astronomy's Dark Ages.

                  Comment


                  • #10
                    Gary, let me give you an example of using both.
                    First, You can make a dialog using DDT (dynamic dialog tools) or you can use SDK in which you create the window using a window create api and have more control over it. That is not to say there isn't plenty of control when using ddt, however.

                    For my programs, I use primarily DDT for all the dialogs that the user interfaces with. For printing reports, I use a graphic window for print preview
                    and xprint to print the report. The XPRINT and GRAPHIC statements have most things in common so that a preview/print program is made pretty easy.

                    I use quite a few graphic controls in my dialogs, more than i do in my print/preview actually. I do use some graphics in the reports but only when the report needs it. What I mean in this case is like graphic render, versus
                    graphic line. I am not considering Graphic Line a graphic in this sense.
                    Client Writeup for the CPA

                    buffs.proboards2.com

                    Links Page

                    Comment


                    • #11
                      This is all excellent help. I'll be trying it out all the suggested code today.

                      Bob, my Help file actually says (I'm copying this verbatim):

                      "Handle of the GRAPHIC WINDOW, DIALOG, or BITMAP to be used with GRAPHIC statements."


                      This is from my PB/Win 9.0 installation. Perhaps there's an update I'm missing, that took out the word DIALOG? Based on what you said, I'll just assume it's a typo.

                      Thanks again for all the help.

                      Gary

                      Comment


                      • #12
                        No it is not a typo. If it is a graphic control then you specify the handle of the dialog box that is the parent of the graphic control and the id will be the control id of the graphic control assigned by you in the control add graphic statement. If it is a graphic window or memory bitmap you specify the handle of the graphic window or memory bitmap and the id will be zero.
                        Sincerely,

                        Steve Rossell
                        PowerBASIC Staff

                        Comment


                        • #13
                          "Oh, what a tangled web we weave, when first we practise technical authorship"

                          My advice - learn by copying code, changing bits of it, etc. Don't let the help file be your bible - they're still arguing about what every version of the Bible means.

                          Comment


                          • #14
                            Steve, thanks for the clarification.
                            Chris, that's a great quote. I'll follow your advice.

                            Holiday wishes,
                            Gary

                            Comment


                            • #15
                              Gary, it's not so much what you read, it's what you see. Unfortunately (too) much of PB help appears opague, or at least very dark grey, to more than a few of us. That's where the forums are invaluable (if not always crystal clear either). The key is to keep asking until you get it. It can be painful sometimes, but well worth the effort.

                              =====================================
                              "If stupidity got us into this mess,
                              then why can't it get us out?" "
                              Will Rogers (1879-1935)
                              =====================================
                              It's a pretty day. I hope you enjoy it.

                              Gösta

                              JWAM: (Quit Smoking): http://www.SwedesDock.com/smoking
                              LDN - A Miracle Drug: http://www.SwedesDock.com/LDN/

                              Comment


                              • #16
                                Originally posted by Gary Beene View Post
                                Barry, thanks for your comment. I'm still unsure of when a GW is the best answer as opposed to another DIALOG. It does seem easier to pop up a GW, but beyond that I don't know enough yet about PB to know any other reason to use a GW. I'll be playing with it for the next day or so and see what I can come up with.
                                I've only used graphic controls so far. I haven't found a reason to look at graphic windows. I read about them when I first started using PB but I don't think I understood the difference unless it's that you can't put other controls on a graphic window, which would make sense.

                                Since you can make a graphic control fill the client area I'm not sure what advantage a graphic window might have. Maybe someone can comment on the differences in the two and when one might be preferable to the other. I couldn't find much in the help about their difference.

                                Barry

                                Comment


                                • #17
                                  Barry, as I said in a previous post, with the similarity of the graphic and xprint statements, the most obvious use
                                  for a graphic window is a print/preview.It also easier for things like graphs, etc that may or may not be printed too.
                                  PB9 now has some input statements I believe to go along with graphic statements that PB8+ did not have making
                                  an interactive report possible.
                                  For example, displaying a tax form with user input then printing it. Although this is possible with ddt (I have done it),
                                  It looks like it may be much simpler with graphic statements.
                                  Last edited by Fred Buffington; 27 Dec 2008, 05:49 PM.
                                  Client Writeup for the CPA

                                  buffs.proboards2.com

                                  Links Page

                                  Comment


                                  • #18
                                    Originally posted by Fred Buffington View Post
                                    Barry, as I said in a previous post, with the similarity of the graphic and xprint statements, the most obvious use
                                    for a graphic window is a print/preview.It also easier for things like graphs, etc that may or may not be printed too.
                                    PB9 now has some input statements I believe to go along with graphic statements that PB8+ did not have making
                                    an interactive report possible.
                                    For example, displaying a tax form with user input then printing it. Although this is possible with ddt (I have done it),
                                    It looks like it may be much simpler with graphic statements.
                                    Yep you did say that but I read it after I'd made my post. I haven't done anything involving printing so that hadn't occurred to me.

                                    Barry

                                    Comment


                                    • #19
                                      >..that hadn't occurred to me.

                                      I'd like a nickel for every time I've heard that in a 'software development' context.....
                                      Michael Mattias
                                      Tal Systems (retired)
                                      Port Washington WI USA
                                      [email protected]
                                      http://www.talsystems.com

                                      Comment

                                      Working...
                                      X