Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!helios!diamond!jdm5548 From: jdm5548@diamond.tamu.edu (James Darrell McCauley) Newsgroups: comp.lang.c++ Subject: Re: Turbo C++ and Zinc Interface Library, Recommendations? Message-ID: <9912@helios.TAMU.EDU> Date: 8 Nov 90 04:25:03 GMT References: <1990Nov2.015742.19381@murdoch.acc.Virginia.EDU> <125640@linus.mitre.org> Sender: usenet@helios.TAMU.EDU Reply-To: jdm5548@diamond.tamu.edu (James Darrell McCauley) Followup-To: comp.lang.c++ Organization: Texas A&M University Agricultural Engineering Dept Lines: 77 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