sgf0z@watt.acc.Virginia.EDU (Steven Glenn Fox) (11/02/90)
Sorry if this has been discussed in the past but I am new to the C++ arena and c.l.c++. Has anyone used Turbo C++ and the Zinc Interface Library ? I am embarking on a new project that will employ a GUI and be coded in C++ for the PC environment. This combination (TC++ and Zinc) seems to be just what I need, but I am a little wary with two relatively new products. I would like to hear any feedback on Zinc and GUI development. How well developed is the product? the class libraries? the docs and support? the event manager? Thanks in Advance! Steven G. Fox sgf0z@virginia.edu University of Virginia uunet!virginia!sgf0z Department of Systems Engineering Charlottesville, Va 22903 (804) 982-2073
jdm5548@diamond.tamu.edu (James Darrell McCauley) (11/03/90)
In article <1990Nov2.015742.19381@murdoch.acc.Virginia.EDU>, sgf0z@watt.acc.Virginia.EDU (Steven Glenn Fox) writes: To: sgf0z@watt.acc.Virginia.EDU (Steven Glenn Fox) Subject: Re: Turbo C++ and Zinc Interface Library, Recommendations? In article <1990Nov2.015742.19381@murdoch.acc.Virginia.EDU> you write: |> Sorry if this has been discussed in the past but I am new to |> the C++ arena and c.l.c++. me too |> Has anyone used Turbo C++ and the Zinc Interface Library ? a little |> I would like to hear any feedback on Zinc and GUI development. |> |> How well developed is the product? the class libraries? the docs |> and support? the event manager? Though I'm still trying to figure everthing out, I've found the Zinc libraries to be very nicely done. Their reference manual is very good (in explaining the use of each object type). The programmer's guide is okay but perhaps a little compact for my tastes. (I didn't learn C from K&R!) Tech support is fair (talked to them twice). Their BBS could use a few more examples. One frustrating thing is their format for icons (bitmaps), though I've just overcome that problem. Their tech support suggested that I use graph paper to create them, but I've just hacked one of Jef Poskanser's pbm utilities to go from PBM -> Zinc Format. I'll post it a little later once I get a message to Mr. Poskanser. I have been very impressed with the look it gives. BTW, they're now shipping 1.01 upgrades to all registered users. --- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - James Darrell McCauley jdm5548@diamond.tamu.edu Dept of Ag. Engineering (409) 845-6484 Texas A&M University, College Station, Texas 77843-2117, USA - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
brown@cs.utk.edu (Lance A. Brown) (11/03/90)
Where can I get the address of the company that puts out the Zinc Library? Thanks, Lance Brown -- ------------------------------------------------------------------------------ Lance A. Brown brown@cs.utk.edu 3500 Sutherland Avenue, Apt. L-303 Graduate Student in Computer Science Knoxville, TN 37919 Sun SparcStations are Neat! ------------------------------------------------------------------------------
ronb@burklabs (Ron Burk ) (11/06/90)
sgf0z@watt.acc.Virginia.EDU (Steven Glenn Fox) writes: > I would like to hear any feedback on Zinc and GUI development. I believe the latest issue of Tech Specialist has a review. as a review.
jrv@sdimax2.mitre.org (VanZandt) (11/07/90)
I recently got a copy of the Zinc library demo disk. Here are my
initial reactions...
--- Demo disk files ---
Root directory files:
README 857 9-01-90 2:00p
DEMO EXE 214785 9-01-90 2:00p
D_HELP HLP 13908 9-01-90 2:00p
SOURCE <DIR> 9-01-90 2:00p
Source code files:
D_CALC CPP 4924 9-01-90 2:00p
D_CLASS CPP 1963 9-01-90 2:00p
D_CTRL CPP 10922 9-01-90 2:00p
D_DATA CPP 2723 9-01-90 2:00p
D_DEMO CPP 4851 9-01-90 2:00p
D_DEMO HPP 2706 9-01-90 2:00p
D_DIRECT CPP 7104 9-01-90 2:00p
D_EVENT CPP 6840 9-01-90 2:00p
D_GRAPH CPP 2395 9-01-90 2:00p
D_ICON CPP 10380 9-01-90 2:00p
D_PIANO CPP 5826 9-01-90 2:00p
D_WIN CPP 11415 9-01-90 2:00p
--- Comments & Questions ---
The demo runs in graphics mode by default, but will also run in several
text modes and the user can switch from one mode to another. The text
mode windows look a lot like those in the TCE. The graphics mode
windows look much sharper.
Size: The demo file is 214K - how much of this is TC++ library code,
and how much is Zinc library code? What is the minimum size of a
program using Zinc? Presumably the demo uses nearly all the functions.
Will the linker include functions for unused features?
Speed: Opening 24 overlapping graphics mode windows of various sizes,
then closing them, took about 2.7 sec on a 25 MHz '386. The same
sequence in text mode took about half as long.
Mouse functions: With a mouse, multiple windows can be opened, with the
most recently opened window being active. The active window has
minimize and maximize buttons in the upper right and an anonymous
button in the upper left. Clicking on the anonymous button brings up a
generic window menu with the options restore, close, move, resize,
maximize, and minimize. I found these functions easier to access
directly: move a window by dragging on its title, resize it by dragging
on a side or a corner, minimize or maximize by clicking the appropriate
buttons, and close by hitting the escape key. The "restore" command
undoes the effect of the minimize or maximize command. In contrast,
the minimize and maximize buttons in the corner of the window are
toggles. Windows can fall partly off the screen, so long as part of
the top edge remains visible. Clicking in an inactive window makes it
active and brings it to the front. Dragging on a menu will move the "current
choice" bar, but releasing the mouse button does not select the highlighted
choice. An explicit click is needed.
I found no way to pop up the generic window menu with keyboard
commands. However, there are alt-function key combinations for those
commands, plus exit and editing commands.
Is the programmer responsible for restoring material covered by a
window, or does the library code save and restore it for him? (This is
a time+complexity vs. space tradeoff.)
The text for windows (including the help windows) are in the separate
file D_HELP.HLP. The demo will run without the text file, but buttons
that would call up text windows don't work. Keeping the two files
together is a configuration control problem. Here is a dump of the
beginning of D_HELP.HLP:
0000H AF 05 01 00 23 00 CE 32 00 00 54 68 65 20 66 6F '/...#.N2..The fo'
0010H 6C 6C 6F 77 69 6E 67 20 61 63 74 69 6F 6E 73 20 'llowing actions '
0020H 63 61 6E 20 62 65 20 70 65 72 66 6F 72 6D 65 64 'can be performed'
0030H 20 6F 6E 20 77 69 6E 64 6F 77 73 3A 20 0D 0A 0D ' on windows: ...'
0040H 0A 20 20 4D 41 58 49 4D 49 5A 45 20 3C 41 6C 74 '. MAXIMIZE <Alt'
0050H 20 46 31 30 3E 20 20 20 20 4D 49 4E 49 4D 49 5A ' F10> MINIMIZ'
0060H 45 20 3C 41 6C 74 20 46 39 3E 0D 0A 20 20 4E 45 'E <Alt F9>.. NE'
0070H 58 54 20 20 20 20 20 3C 41 6C 54 20 46 36 3E 20 'XT <AlT F6> '
0080H 20 20 20 20 4D 4F 56 45 20 20 20 20 20 3C 41 6C ' MOVE <Al'
0090H 74 20 46 37 3E 0D 0A 20 20 53 49 5A 45 20 20 20 't F7>.. SIZE '
00A0H 20 20 3C 41 6C 74 20 46 38 3E 20 20 20 20 20 43 ' <Alt F8> C'
00B0H 4C 4F 53 45 20 20 20 20 3C 45 73 63 3E 0D 0A 20 'LOSE <Esc>.. '
00C0H 20 52 45 53 54 4F 52 45 20 20 3C 41 6C 74 20 46 ' RESTORE <Alt F'
00D0H 35 3E 20 0D 0A 0D 0A 54 68 65 20 66 6F 6C 6C 6F '5> ....The follo'
00E0H 77 69 6E 67 20 6F 70 65 72 61 74 69 6F 6E 73 20 'wing operations '
00F0H 63 61 6E 20 62 65 20 70 65 72 66 6F 72 6D 65 64 'can be performed'
...which is straight ASCII text, except for the first ten bytes (and
some bytes near the end of the file). The text does not appear in the
source code. Can it be maintained by a straight ASCII text editor? If
so, how do the first ten bytes get added? How is the correspondence
between the windows and their respective text maintained?
The text file has CRLFs only at the end of paragraphs. Wordwrapping
is done on the fly, and changes when the window "maximize" button is
toggled.
In text mode, or in graphics mode on a VGA, the current status is
indicated by "square root" symbols to the left of the corresponding
menu buttons. In graphics mode on a Paradise EGA, there was no
indication.
In graphics mode, window buttons for "close", "minimize", and
"maximize" are displayed with a 3D effect as if they were lighted from
the upper left. Menu buttons lack this. In menus, buttons are merely
black text on white (or black on gray for the current button).
In the sample pulldown menu, each pulldown menu is left-aligned with
its button in the menu bar. Is this a requirement? (If so, then
buttons with wide pulldown menus cannot be placed near the right end of
the menu bar.)
Many of the windows have buttons with labels like "about the help system"
that pop up associated information windows. Apparently these windows
are special cases of the help window. This means that if you ask for help
from within an information window, the help window replaces the information
window. When the help window is closed the information window is gone
too.
-------------------------------------------------------------------------
Maybe someone with the Zinc library can answer some of my questions.
In the mean time, I hope this helps.
- Jim Van Zandtjdm5548@diamond.tamu.edu (James Darrell McCauley) (11/08/90)
In article <125640@linus.mitre.org>, jrv@sdimax2.mitre.org (VanZandt) writes: |> The demo runs in graphics mode by default, but will also run in several |> text modes and the user can switch from one mode to another. You can specify what mode you want. The default in the demo is graphics (because Zinc linked in the BGI files). I've seen some pretty impressive graphics in an example contained in their latest release. Pie Charts, Bar Charts, Line Graphs. |> I found no way to pop up the generic window menu with keyboard |> commands. However, there are alt-function key combinations for those |> commands, plus exit and editing commands. try ALT-F6, W, 1 You can do all kinds of cut / paste / whatever without any extra programming effort (Zinc has some kind of a built-in global paste buffer). IMPORTANT POINT: Unless you start redefining stuff or getting overly sophisticated, MOST programs should work with or WITHOUT a mouse. (I couldn't get their paintbrush example to work with the cursor keys, but I didn't really expect to.) You're not stuck to just mice or keyboards, either. You can create your own input device objects using UI_DEVICE as a base class, just as long as it communicates with the event manager properly. |> Is the programmer responsible for restoring material covered by a |> window, or does the library code save and restore it for him? (This is |> a time+complexity vs. space tradeoff.) The window manager takes care of this for you. |> The text for windows (including the help windows) are in the separate |> file D_HELP.HLP. Only the help info. UIW_TEXT, a text window class, has the text in char *, an argument to the constructor, as does the other window objects. The special format for help files is a product of a utility called GENHELP, which comes with Zinc. The programmer doesn't have to worry about it. |> In text mode, or in graphics mode on a VGA, the current status is |> indicated by "square root" symbols to the left of the corresponding |> menu buttons. In graphics mode on a Paradise EGA, there was no |> indication. Whether or not to have check marks is a question answered by the programmer. Why you didn't have the checks using the Paradise card, I don't know. |> In graphics mode, window buttons for "close", "minimize", and |> "maximize" are displayed with a 3D effect as if they were lighted from |> the upper left. Menu buttons lack this. Menu buttons are called menu "items." If you want buttons in the menus, then you have to program it that way. These window buttons are added only if you want them (i.e., you have to code them in). |> In the sample pulldown menu, each pulldown menu is left-aligned with |> its button in the menu bar. Is this a requirement? No. Just a matter of style. Look at the code. They could have made them right justified, since strings are used: " Item ~1 " " ~Item 9999 " Look at the source! I really like Zinc, but I do have to give a word of caution. TC++ (1.01) RUNS OUT OF MEMORY while compiling (command line version) if you don't watch yourself. In their source for the demo, Zinc tends to add a lot of objects to the windows in one expression, sort of like "*window +a +b +c +d +e +f +g;" Don't get caught doing this: "*window +a +b + ... +z;" TCC chokes. This is fairly obvious, but I understand that Zinc has had quite a few questions about this. Also, large bitmaps are not good. I ran out of memory on a 4 MB machine while trying to compile a 400x450 bitmap. I guess 400x450 is a little big to be called an icon though (which is what I was trying to do). Later Daze, Darrell --jdm5548@diamond.tamu.edu
wallis@labc.enet.dec.com (Barry L. Wallis) (11/15/90)
There is also a review of the Zinc Interface Library in the new Dr. Dobb's Journal. --- Barry L. Wallis USENET: wallis@labc.dec.com Database Consultant Prodigy (don't laugh): DNMX41A U.S. DECtp Resource Center DECUServe: EISNER::WALLIS (not on the net yet) Los Angeles, CA "No one voted for me, I represent myself" ---