Painting graphics: Delph versus C / GDI
RDBBolotin
I am starting a port of a C language DOS program to 16-bit Windows. I have
chosen to use Delphi 1.0 for the Windows user interface. The guts of the
program (complex data structures, number crunching, file handling, etc.)
will remain C language in a C DLL (I'm not about to rewrite 50,000 lines
of C code painstakingly developed over the last 7 1/2 years).
Most of the user interface is text displays. Grids, setup forms with edit
fields, etc.. This stuff will all be converted to Delphi controls which
call C functions which will return the actual character strings to display
in the controls. This is pretty clear to me, and not all that much
different from the way the DOS version is currently written.
The thing which is less clear to me is what to do about the graphical
charts (enhanced stock market style open, high, low, close type charts).
Again, the guts of these complex and specialized charts are already
written in C and I have no desire to rewrite the C code. The choices are
(1) callback into Delphi code for the actual graphics painting and
printing of the charts, or (2) have the C code paint and print the
charting windows directly with GDI calls.
I assume it is possible to call back into the Delphi code?
But from a performance standpoint, would it be better to code the graphics
from C with direct API calls? This is a commercial product and performance
is important, but with today's fast computers it's probably less important
than in days gone by.
Possibly even more important than performance is my impression is that
graphics printing from Delphi is only a bitmap dump type print. On the
other hand, direct GDI yields printouts at the full resolution of the
printer. Is this correct?
Would using the Delphi graphics facility make printing easier and less
error prone? It isn't only the actual GDI call for printing. It's also
having a Printer Setup menu.
What advantages will direct GDI offer? To do direct GDI, somehow I must be
able to pass WM_PAINT messages from Delphi into the C DLL. My concept is
that this is the ONLY message the C code will process. I would like to use
Delphi to draw the scroll bars, a couple buttons, etc. and only call the C
code to paint the portion of the windows where the actual graphical charts
are drawn based upon directions from the Delphi code. Can this be done
with Delphi 1.0?
I am at a critical juncture with this question. My first goal is to
migrate the charts to Windows because they are what stands to benefit the
most. In particular, my very first goal is just a simple Windows utility
to display and print the charts, since the DOS version doesn't support
chart printing.
Should I be reading Petzold to learn about GDI programming? If I am going
the GDI route, I can write a simple C language user interface for the
print utility based upon one of Petzold's sample programs. Then as the
next step, if I could put the C code into a DLL and start handling the
more involved user interface in Delphi.
But if the goal is to paint graphics in Delphi, I really don't need to
read Petzold cover to cover to get started. The only C issue would be
interfacing Delphi with a "machine independent" C DLL (no Windows stuff in
the DLL at all). I could finish Petzold at my leisure.
Before anyone starts yelling at me how I should read Petzold anyway as
background material, I should mention that I have already read the book
"Teach Yourself Windows 95 Programming in 21 Days" cover to cover. This
book also talks about C language API programming. I started with the "21
Days" book because it had an emphasis on writing programs which can be
compiled for either 16-bit or 32-bit, where the Petzold books seemed
directed either towards 16-bit or 32-bit. I got enough background from the
"21 Days" book to make the decision to target 16-bit first (with the
assumption that 32-bit will basically be a recompile). The "21 Days" book
is more of a hand holding tutorial than Petzold, and was therefore a good
way to start. But Petzold seems to go into more depth about some topics
such as GDI and printing graphics, so now I am now also reading Petzold's
"Programming Windows 3.1". It is good to get two perspectives.
As another aside, my investment in the existing C code is forcing me to
maintain a platform independent "core" in C rather than writing the whole
program in Delphi. But I am convinced this is the proper approach anyway.
Who knows what the future of Delphi or VB is? Who knows when I might have
to port this program to a Mac or UNIX or some future environment? Use
Delphi or VB for what it does best - the Windows user interface - but code
platform independent code in platform independent C/C++ for portability.
As well as the Delphi versus GDI for graphics questions, I would greatly
appreciate hearing if there are any fatal flaws in my general plan here.
Thanks in advance!
Bob Bolotin
rdbbo...@aol.com
John Grant
In article <4tsrl9$1...@newsbf02.news.aol.com> rdbbo...@aol.com (RDBBolotin) writes:
>I am starting a port of a C language DOS program to 16-bit Windows. I have
>chosen to use Delphi 1.0 for the Windows user interface. The guts of the
>program (complex data structures, number crunching, file handling, etc.)
>will remain C language in a C DLL (I'm not about to rewrite 50,000 lines
>of C code painstakingly developed over the last 7 1/2 years).
nor is it a wrong choice. Delphi has a lot of things going for it.
But with that much C code, there is some merit to keeping it all in
in C/C++ or writing it all in Delphi.
>Most of the user interface is text displays. Grids, setup forms with edit
>fields, etc.. This stuff will all be converted to Delphi controls which
>call C functions which will return the actual character strings to display
>in the controls. This is pretty clear to me, and not all that much
>different from the way the DOS version is currently written.
>
>The thing which is less clear to me is what to do about the graphical
>charts (enhanced stock market style open, high, low, close type charts).
>Again, the guts of these complex and specialized charts are already
>written in C and I have no desire to rewrite the C code. The choices are
>(1) callback into Delphi code for the actual graphics painting and
>printing of the charts, or (2) have the C code paint and print the
>charting windows directly with GDI calls.
>
>I assume it is possible to call back into the Delphi code?
I don't know. I haven't worked with mixed languages in Windows.
Your choice might depend on the availability of high-level graphing
objects. If you have such objects in Delphi, it would be worthwhile
doing it in Delphi, otherwise if you have to code it yourself, it
may not make much difference whether you code it in C or Delphi.
>But from a performance standpoint, would it be better to code the graphics
>from C with direct API calls? This is a commercial product and performance
>is important, but with today's fast computers it's probably less important
>than in days gone by.
I wouldn't worry about any performance problems calling between
languages and either C or Delphi will be very fast anyway.
>Possibly even more important than performance is my impression is that
>graphics printing from Delphi is only a bitmap dump type print. On the
>other hand, direct GDI yields printouts at the full resolution of the
>printer. Is this correct?
That's terrible for your customers. Nobody should have to accept
that. You need a proper printing facility, and whether Delphi has
it or not is irrelevant - you can code this yourself. Generally
speaking, you should always try to structure your code so that
the same code can be used for drawing on the screen and printing.
For example:
case WM_PAINT:
PAINTSTRUCT ps;
RECT rect;
HDC hdc=BeginPaint(&ps);
GetClientRect(hwnd,&rect);
DrawMyPicture(hdc,&rect);
EndPaint(&ps);
break;
case WM_COMMAND:
switch(idmenu){
case IDM_PRINT:
PRINTDLG pd;
RECT rect;
pd.lStructSize=sizeof(pd);
...
rect.left=rect.top=0;
rect.right= GetDeviceCaps(pd.hDC,HORZRES);
rect.bottom=GetDeviceCaps(pd.hDC,VERTRES);
if(PrintDlg(&pd)){
DrawMyPicture(pd.hDC,&rect);
DeleteDC(pd.hDC);
}
break;
In your DrawMyPicture() routine, you do all of your drawing in a
relatively device independent manner. You don't have to know what
type of device it is. Heck, you don't even have to know if the
user has set up the paper in landscape or portrait mode. Just look
up the size of the paper and draw.
>Would using the Delphi graphics facility make printing easier and less
>error prone? It isn't only the actual GDI call for printing. It's also
>having a Printer Setup menu.
Use the COMMDLG PrintDlg() function for printer setup (common to
all Windows apps, regardless of language)
It's quite probable that Delphi has an object that handles this
relatively transparently to you, including a 'Print Preview' choice.
OWL & MFC have it, so I'm sure Delphi has it.
>What advantages will direct GDI offer? To do direct GDI, somehow I must be
>able to pass WM_PAINT messages from Delphi into the C DLL. My concept is
No, you don't pass the message to the DLL. All you do is call
the DrawMyPicture() function which may be a Delphi function or a C
function and it may be in your .EXE or in a separate .DLL.
>that this is the ONLY message the C code will process. I would like to use
>Delphi to draw the scroll bars, a couple buttons, etc. and only call the C
>code to paint the portion of the windows where the actual graphical charts
>are drawn based upon directions from the Delphi code. Can this be done
>with Delphi 1.0?
You need to get some ideas from Delphi people on the details.
Are you aware of the following groups?:
alt.comp.lang.borland-delphi
alt.lang.delphi
comp.lang.pascal.delphi.components
comp.lang.pascal.delphi.databases
comp.lang.pascal.delphi.misc
comp.lang.pascal.delphi.advocacy
comp.lang.pascal.delphi.components.misc
comp.lang.pascal.delphi.components.usage
comp.lang.pascal.delphi.components.writing
comp.lang.pascal.delphi.announce
comp.sources.delphi
>I am at a critical juncture with this question. My first goal is to
>migrate the charts to Windows because they are what stands to benefit the
>most. In particular, my very first goal is just a simple Windows utility
>to display and print the charts, since the DOS version doesn't support
>chart printing.
>
>Should I be reading Petzold to learn about GDI programming? If I am going
Petzold's book is always good reading, but there's really very
little to know about GDI stuff. There's nothing magic about it.
There are functions for drawing lines, filled polygons, text etc.
It's not much different than any graphics subsystem in any O/S.
You probably won't use the more complex features like regions.
If you need axes, you won't find anything for them at all. You
will need to write your own axis routine with lines, ticks &
labels. But I'm sure you can find canned objects to do this for
you. There's a pretty comprehensive Delphi site, but I can't
remember where it was. Go to www.borland.com and read David
Intersimione's "a sip from the firehose" column - in there he
recommends a Delphi site. I had a look - it's pretty good.
>the GDI route, I can write a simple C language user interface for the
>print utility based upon one of Petzold's sample programs. Then as the
>next step, if I could put the C code into a DLL and start handling the
>more involved user interface in Delphi.
>
>But if the goal is to paint graphics in Delphi, I really don't need to
>read Petzold cover to cover to get started. The only C issue would be
Just look at the on-line help under GDI functions and check out
the list. There aren't many. Petzold does a good job of explaining
viewports & mapping modes. For simplicity, you can start off with
the default MM_TEXT, where your addressable logical co-ordinates
are just pixels (whether screen or printer).
>interfacing Delphi with a "machine independent" C DLL (no Windows stuff in
>the DLL at all). I could finish Petzold at my leisure.
>
[...read ...21 days book already...]
>such as GDI and printing graphics, so now I am now also reading Petzold's
>"Programming Windows 3.1". It is good to get two perspectives.
Yup.
>As another aside, my investment in the existing C code is forcing me to
>maintain a platform independent "core" in C rather than writing the whole
>program in Delphi. But I am convinced this is the proper approach anyway.
Let me back up a bit. You say you have 50k lines of C code for
the DOS graphics? Regardless of whether you do it in C or Delphi,
it's still almost a complete re-write because Windows graphics
is completely different than DOS graphics. So if you have to
re-write it for Windows, perhaps it's just as easy to do it in
Delphi.
Normally, when people used mixed languages, they put the
number-crunching code (i.e. C, FORTRAN) in DLLs and then do a
pretty GUI front-end in something like VB, calling the DLL functions
only to do the processing. In your case, you're contemplating calling
the DLLs to draw the graphics. I suppose that's ok, because there are
lots of VBX and custom controls that are used to draw fancy displays.
I have no experience with VBX or commercial packages.
>Who knows what the future of Delphi or VB is? Who knows when I might have
I'm sure Delphi, VB & C++ all have bright futures.
>to port this program to a Mac or UNIX or some future environment? Use
That's significant problem for Delphi and VB - not being available
on unix or Mac. At least the C/C++ language can be ported, but
there are still problems in converting the GUI code. There are
several packages, but many people have said that they produce Mac
apps that look like Windows apps and that's not good enough (they
say).
>Delphi or VB for what it does best - the Windows user interface - but code
>platform independent code in platform independent C/C++ for portability.
>
>As well as the Delphi versus GDI for graphics questions, I would greatly
>appreciate hearing if there are any fatal flaws in my general plan here.
Post your questions to the delphi groups to take advantage of
their experience.
--
John A. Grant jag...@nrcan.gc.ca
Airborne Geophysics, Geological Survey of Canada, Ottawa
If you followup, please do NOT e-mail me a copy: I will read it here.