Announcement

Collapse
No announcement yet.

DDT vs Graphic Window

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

  • Michael Mattias
    replied
    >..that hadn't occurred to me.

    I'd like a nickel for every time I've heard that in a 'software development' context.....

    Leave a comment:


  • Barry Marks
    replied
    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

    Leave a comment:


  • Fred Buffington
    replied
    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, 04:49 PM.

    Leave a comment:


  • Barry Marks
    replied
    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

    Leave a comment:


  • Gösta H. Lovgren-2
    replied
    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)
    =====================================

    Leave a comment:


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

    Holiday wishes,
    Gary

    Leave a comment:


  • Chris Holbrook
    replied
    "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.

    Leave a comment:


  • Steve Rossell
    replied
    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.

    Leave a comment:


  • Gary Beene
    replied
    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

    Leave a comment:


  • Fred Buffington
    replied
    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.

    Leave a comment:


  • Rodney Hicks
    replied
    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.

    Leave a comment:


  • Bob Zale
    replied
    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.

    Leave a comment:


  • Chris Holbrook
    replied
    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

    Leave a comment:


  • Gary Beene
    replied
    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

    Leave a comment:


  • Barry Marks
    replied
    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

    Leave a comment:


  • Gary Beene
    replied
    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

    Leave a comment:


  • Bob Zale
    replied
    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.

    Leave a comment:


  • Chris Holbrook
    replied
    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.

    Leave a comment:


  • Gary Beene
    started a topic DDT vs Graphic Window

    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
Working...
X