Re: My continuing confusion
Ken Weinert wrote:
>
> I think I'm getting the separation of church and state confused.
>
> What I'm trying to do (in the real simple case right now) is to
> open an XML file and output the results of the parser in a text canvas.
>
> To my way of thinking, the cmdwin stuff is GUI, the XML stuff is
> app. But I just can't get it into my head how the app talks to the GUI.
> I've got the functions defined in the app.[cpp|h] for parsing the XML
> but can't figure out how to display it.
>
> The one thing that the tutorial stuff just doesn't show
> (or maybe in my confusion I've missed it :-) is how to interact with the
> existing canvas. Showing a dialog popping up is fine, but it isn't a
> very good tutorial on how to interact between an app and the GUI.
>
> Sorry for continuing to belabor the point, I appreciate the help
> I got earlier, but I still don't get it. I keep grinding the my mind's
> gears trying to do this paradigm shift.
>
> Thanks again for any clarification that someone (anyone!) can
> give me. I'm really not usually this dense, maybe it's all those years
> of C programming that are getting in the way :-)
>
> --
> Ken Weinert kweinert@earthlink.net 303-858-6956 (V) 978-336-5652 (F)
> PGP: DF 2B 6C 72 33 BE 06 D1 9D C4 ED 32 36 97 C0 6E
> If "Thou art God," then praising the Lord is an act of conceit. And praying
> is just talking to yourself - Solomon Short
>
> --
> To UNSUBSCRIBE, email to other-vgui-discuss-request@other.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@other.debian.org
The easiest way to get this, I think, is to look at one of the examples.
The very "best" example is VIDE, but that is really a bit big. The icon
editor is also a good real example.
But - I find I do most of my work in the command window class.
Note that you actually will create the canvas object in the
derived cmdWindow class. Thus, there is your handle to send
text and other stuff to the canvas. the cmdWindow class
also has the WindowCommand class, which is where most of your
commands are routed. (Keyboard input is sent to the canvas
directly, but your canvas will have a pointer to its
cmdWindow parent, too.) Thus, you will typically have
references like "myCanvas->doSomething()" in response
to a WindowCommand event.
Each canvas can also be thought of as a view. The view
then needs to be told where its data is (again, probably
using the pointer to the canvas object you created in
the command window). You then send appropriate messages
(calls) to the "view" to update it as needed. (There
is good support for this approach, called MVC, in V.)
The app class acutally is usually quite limited in what
it does. It typically serves as a startup, and perhaps
as a place to keep global information.
If you look at VIDE, for example, the data for the file
your are editing is actually kept in the canvas class,
which is derived from a text canvas. The command window
stuff sends file names to the canvas class to open,
save, etc. Actual editing commands are handled directly
in the canvas class, while more global commands (like
opening files) are handled in the command window.
VIDE is not MVC, but it could have been.
--
Bruce E. Wampler, Ph.D.
Author of the V C++ GUI Framework
e-mail: mailto:bruce@objectcentral.com
web: http://www.objectcentral.com
Reply to: