DDT vs Graphic Window

[Gary Beene]

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

[Chris Holbrook]

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.

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

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.

[Bob Zale]

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.

[Gary Beene]

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

[Barry Marks]

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

[Gary Beene]

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

[Chris Holbrook]

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

' 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

[Bob Zale]

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.

[Rodney Hicks]

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.

[Fred Buffington]

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.

[Gary Beene]

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

[Steve Rossell]

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.

[Chris Holbrook]

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

[Gary Beene]

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

Holiday wishes,
Gary

[Gösta H. Lovgren-2]

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

[Barry Marks]

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

[Fred Buffington]

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.

[Barry Marks]

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

[Michael Mattias]

>..that hadn't occurred to me.

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