I have what seems like a simple task. I wrote a Windows application using C++. Now I need to add to it a capability to print forms -- nothing fancy, just plain text, with lines, tables, and simple graphics. Besides printing, a user needs to be able to preview on the screen all forms being printed.
Previously I was able to get away with this task by using an embedded Internet Explorer control and design all forms in HTML (which I like -- the HTML part.) But the problem comes with IE... hmm... I wish I had a nickel every time I heard that phrase :) Anyway, IE can print an HTML page but it does not provide any easy way for users of my software to customize page size, page margins, etc.
I spent a good deal of the last week trying to make IE Print Templates work with what I need ... but eventually failed. That stuff is very poorly documented and what I was able to do seems to randomly crash on me. So at this point I gave up on IE...
So my question to you -- is there a way to incorporate printing into my C++ program for the purposes like I described above?
If I remember correctly, printers have their own HDC, and you can draw on it. That'll work if have something simple. If you want to render HTML page using pure WinAPI, you're in big trouble.
I'd advise to abandon winapi and try GUI framework instead.
Qt 4(and 5, most likely) has text editor that can display rich text, layout engine for rich text, component that can display web pages. Read documentation a bit, and you will most likely find a way to render web page onto printer instead of screen. So far it looks like exactly what you would need.
Using Qt will add dependencies (20+ MB of DLLs for your project), but, IMO< it is a better idea than trying to use IE COM interfaces.
If you don't want to use Qt, you could try something like WebKIT, but I had some bad experiences with it, plus Qt might be just easier to use.
Additional info on printing: Printing with Qt.
Try searching for GDI, if you want to use win32 builtins.
Or use another toolkit like wxWidgets. Or consider writing to PDF with some library. Or let LaTeX do the heavy lifting - writing text files is easy. The LaTeX-way works as long as you don't want to modify your output depending on the layout (one Use-Case that doesn't work with LaTeX is the "balance" at the top/bottom of each page.)
Consider having your program generate XML files and using XSLT to render them into HTML.
By attaching stylesheets you will make it much easier to customize the presentation.
Every time I try to use the D Forms Library, I run across the fact that it has no TableLayoutPanel -- which makes it practically impossible for me to make a good GUI.
Is there any TableLayoutPanel implementation out there for DFL?
How do people usually use this library without it?
Edit:
A link to another program that uses DFL would be a great bonus for an answer. :)
Posting as an answer because length exceeds comment length limit.
I downvoted your question because it is formulated with elements of flamebait. I would guess that your previous experience with GUI libraries was mostly with libraries supporting box layouts, such as Qt. The Win32 GUI API itself does not provide any primitives for creating box layouts - it uses absolute coordinates through and through. This remains unchanged in many OO libraries that build on top of the API, such as MFC. Some libraries, like VCL, have optional primitives for creating box layouts (panels with alignment and auto-size) - but in the end, all control repositioning has to be done by the application or the GUI framework, so something like this would need to be implemented in DFL from scratch.
So, to answer your questions:
Is there any TableLayoutPanel implementation out there for DFL?
Probably not.
How do people usually use this library without it?
They draw the controls on the form with a mouse, using Entice Designer. (The same is true for MFC/Visual Studio, VCL/Delphi IDE, etc.)
Reply to comment:
how do I put things in a table layout (e.g. two side-by-side, and one below)?
I understand that you'd like to have a fixed-height panel at the bottom, and split the remaining space into two areas which both remain half the form's width when the form is resized.
In Entice Designer, place a Panel, set its dock to BOTTOM. Set its height appropriately.
Place a second panel, set its dock to RIGHT.
In your form's code, add the following method:
protected override void onResize(EventArgs ea)
{
super.onResize(ea);
panel2.width = this.clientRectangle.width / 2;
}
As you can see, it can quickly get messy to get a more complicated "rubber table". I wouldn't bother, or if I really needed complex dynamic layouts, would look for another library.
Or are you saying that's a bad idea in the first place?
Definitely not my point - the advantages of semantic layouts that don't require using an IDE to build are clearly visible. It's just that due to their Win32 API roots, Windows GUI libraries rarely provide good means to build them. Of course, their absence doesn't make building GUIs impossible or even hard - people simply usually go with fixed-size forms, etc. (This is clearly visible to end users switching from Windows to KDE - most KDE dialogs are resizable, while Windows' aren't.)
in lack of a table layout you can use the location and size properties to position stuff on the board (and maybe even implement your own table layout)
you can use the entice designer to make the gui and build further on the generated source
Now that I'm near my code, there are two ways to manage layout. As mentioned by ratchet there is absolute positions and also docking. Docking places the item in 5 possible locations. The Top, Bottom, Left, Right, or Center (fill). You can then place a panel in one of these which can itself contain elements that are docked within it. You assign the docking value to the dock property.
Entice Designer is written with DFL.
OK, so my Windows application involves a window that, among other things, has a list of objects in a pane. Each object has 8 boolean values that need to be determined — so I'd like a list of the objects, with eight columns of checkboxes after. I'm not using MFC, should that be relevant.
ListView looks the way I want it to, but apparently it doesn't accept checkboxes in SubItems (the LVS_EX_CHECKBOXES style only gives each row a checkbox on the left).
So what I need is some kind of alternative to ListView that does allow this. I've been looking, but nothing I've found seems to work.
I have seen reference to some DataGridView control, but I don't see that as an option in my Visual Studio 2010 "toolbox" — how does one access it, is it even available for non-MFC C++ projects? Most references to it seem to be for VB or C#.
Another thing I found is is this custom ListView, but it, again, seems to be for C# and not C++. I'd certainly accept suggestions on how to use this resource in my code, if there's a simple way to interface with the C# dialogue (I'm completely unfamiliar with C#).
Anyway, any thoughts, suggestions, or tips anyone has, would be most appreciated!
EDIT: This should maybe go in a new question, but it doesn't really seem deserving an entire question on its own: MFC seems to have more support for this kind of thing (insofar as most of the custom controls I can find to download are for MFC). My project does not actually require being non-MFC, it just is, at the moment. How much work am I looking at to convert it?
Well, I've taken the plunge and started using MFC; the CGridCtrl I downloaded seems to be working pretty well, though I still have a lot of work on it. I'm going to call this the answer, then, since there doesn't seem to be another forthcoming.
When I began programming (some 10+ years ago), three things amazed me:
Compilers/interpreters (back then I knew them as "programs that make my programs work", often followed by the qualifier "whatever they are")
Code editors
Form designers
Back then, I accepted all of them as facts of life. I was able to make my own special-purpose programs, but "programs that made my programs work", code editors and form editors were made by the Gods and there was no way I could mess with them.
Then I went to university, and took a course on formal language processing. After learning formal grammars, parsers, abstract syntax trees, etc.; all the magic about compilers, interpreters and code editors was soon gone. Compilers and interpreters could be written in sane and simple ways, and the only non-sane thing a syntax highlighting code editor could require were Windows API hacks.
However, to this day, form editors remain a mystery to me. Either I lack the technical knowledge required to make a form designer, or I have such knowledge, but cannot find a way to use it to implement a form designer.
Using Visual C++ and the MFC, I would like to implement a form designer inspired by the best form designer ever:
In particular, I would like to imitate its two features that I like the most:
The form being designed is inside a container. Thus, an arbitrarily large form may be designed without wasting too much screen real estate, by simply resizing the container to an appropriate size.
The "Align to Grid" option makes designing professional-looking user interfaces a lot less
frustrating. In fact, I would go as far as saying creating professional-looking user interfaces using Visual Basic's form designer is actually easy, fun and enjoyable. Even for left-brained programmers like me.
So, I have the following questions:
How do I make a form designer, in which the form being designed is inside a container? Is the form being designed an actual window contained inside another window? Or is it just a mockup "manually" painted by the form designer?
Do the Windows API and/or the MFC contain functions, classes, whatever that make it easy to create "selectable" items (surrounded by little white or blue boxes when they are selected, resizable when they are "grabbed" by one of these "edges")?
How do I implement the "Align to Grid" functionality?
Both the answers here are good, but left out what I consider to be the really interesting bits (including a couple that you didn't ask directly, but you might find of interest anyhow), so here's my 2c:
Drawing the controls
Ideally, you just go ahead and create a regular instance of the control. You want something that looks like a button? Create a real button. The tricky thing is stopping it from behaving like a button: you want clicks to activate it for moving, not actually 'click' it.
One way of dealing with this - assuming that the controls in question are 'HWND-based' (eg. the standard windows set of button, edit, static, listbox, treeview, etc.) - is to create the control, and then subclass it - ie. override the wndproc with SetWindowLongPtr(GWLP_WNDPROC, ...), so that the designer code can intercept mouse and keyboard input and use it to initiate a move, for example, instead of having the mouse input go through to the actual button code, which would instead interpret it as a 'click' event.
An alternative approach to subclassing is to place an invisible window above the button to capture the input. Same idea of intercepting input, just different implementation.
The above applies to both managed (VB.Net, C#) and unmanaged (C/C++) controls; they're both essentially stock windows HWNDs; the managed versions just have a managed wrapper code handing off to the underlying unmanaged control.
The old (pre-managed code) ActiveX controls, as used in pre-.Net VB, were a whole different ball game. There's a fairly complex relationship between an ActiveX container and the ActiveX controls within it, with many COM interfaces handling things like negotiation of properties, events, painting, and so on. (There's event a set of interfaces that allows an ActiveX control to receive input and draw itself without having its own HWND.) One benefit you get from this complexity, however, is that ActiveX controls have an explicit 'design mode'; so a control knows to respond appropriately in that case and can cooperate with the whole procedure.
The Form Itself...
So basically the controls are just regular controls. So you'd expect the form itself to be a regular form? - Almost. As far as I know, its just another HWND-based window, that's a child of the designer (so it gets clipped, and can be scrolled within it); but I think the designer is doing a bit of 'cheating' here, because usually Windows only draws frames like - with titlebar and min/max buttons that for actual top-level windows. I don't know offhand the exact technique that they're using here, but some options could include: painting it manually to mimic the Windows look; using the Windows "theme" APIs, which allow you to access the graphic elements used for the bits and pieces of titlebars and paint them wherever you want to; or, perhaps less likely, setting the window up as a "MDI Child window" - this is one exception case where windows will draw a frame around a nested window.
Draggable Handles
Simplest approach here is for the designer to create eight small square title-bar-less popup windows that sit above all the other elements - which initiate the appropriate resize code when they are clicked. As the user clicks from control to control, just move the drag handle windows to the currently active control. (Note that in all the above, Windows itself is figuring out who's been clicked, you never have to actually compare mouse coords against element rectangle coordinates and work it out yourself.)
Saving & Recreating
For plain windows system controls that are used by unmanaged C/C++, it's relatively easy: there's a well-known text-based file format - .rc - that describes the controls and locations. Have the designer spit out that (and likely a resource.h file also) and you're done: any C/C++ project can pick up those files and compile them in. Managed code (C#, VB.Net) has a somewhat more complex scheme, but it's still the same basic idea: write out a description in the style that the managed tools expect, and they'll happily compile it and use it.
(ActiveX controls are - you've guessed it - a whole 'nother story. There isn't a standard format that I'm aware of, so the form editor and runtime that consumes the data would be closely tied together - eg. the form editor from pre-.Net VB6 produces forms that only VB can use. - I think. It's been some time ago...)
As for recreating the form: if you have a .rc file, it gets compiled into a dialog resource, Windows has built in support to recreate those. Likewise, the managed code support libraries know how to recreate a form from its particular format. Both basically parse the description, and for each item, create elements of the appropriate classes, and set the appropriate style, text, and other properties as specified. It's not doing anything you can't do yourself, its just helper utility code.
Handling Focus
For a collection of HWNDs in any container, whether in 'test' mode or actually running in the real app, and regardless of whether you let Windows or Winforms handle the form creation or whether you created each HWNDs yourself, you can add tabbing support by calling IsDialogMessage in your message loop: see the MSDN page remarks section for details. (While WinForms could do this, I think it actually does its own focus handling, so that it can have tab order independent from visual stacking Z-Order.)
Other Things To Explore...
Make friends with the Spy++ app (part of the SDK, installs with Visual Studio). If you're going to do anything with HWNDs, managed or unmanaged, it's a real good idea to know how to use this tool: you can point it at any piece of UI on Windows, and see how it's constructed out of a tree of different types of HWNDs. Point it at the VB designer and see what's really happening for yourself. (Click the 'binoculars' icon on the toolbar, then drag the crosshairs the the window you're interested in.)
Also take a look at the resource files that the designer spits out. Everything that you can tweak or move or edit in the forms designer corresponds to some item somewhere in one of those resource files. Make a copy of them, tweak some settings, and then file-compare the two sets, and see what's changed. Try changing some things in the files by hand (I think they're nearly all text), reload, and see if the designer picked up your changes.
Other Things To Note...
Much of the above is specific to Windows - notably the fact that since we're using Window's own building blocks - HWNDs - we can get Windows itself to do some of the hard work for us: it gives us the facilities to reuse the controls themselves at design time so we don't have to draw mock-ups; to intercept input on other controls so we can make a click into a move or whatever other action we want, or figure out which control is clicked without having to do the location math ourselves. If this was a designer for some other UI framework - say Flash - which doesn't use HWNDs internally, it would likely instead use that framework's own internal facilities to do similar work.
Also, it's far easier if you limit the number of controls in the palette to a small finite set, at least at first. If you want to allow any control at all to be dragged in - eg. a 3rd party one, or one you've used in another project; you typically first need some way for that control to be 'registered' so that the designer knows that it's available in the first place. And you may also need some way to discover what icon it uses in the toolbar, what its name is, what properties it supports - and so on.
Have fun exploring!
You implement a form designer almost like a normal GUI. You have stuff you can drag (your widgets), you have stuff you can click (your buttons) and you have stuff you can select (your placed widgets) and that's really about it.
Q: Now, how do you display a window in a GUI?
A: You paint it, simple as that.
Q: And how do you keep stuff inside that window?
A: You check against the bounds of the "parent" object. You could almost say that a form designer is like a little game and you have a scene graph holding all your widgets, connected by parent-child-relations.
Q: Then, how do you select stuff in a GUI?
A: Check the current mouse position on-click against the bounds of all (near) widgets (a scene graph only helps here, like a quadtree).
Q: How do you align widgets on a grid?
A: For the grid alignment, let's have a simple example: Say your real resolution is 100px on the x-axis, but you want your grid to only have a resolution of 10px on x. Now say you move your widget by 28px in real resolution. To get the grid resolution, you simply divide by 10, get 2.8, round that, and finally move the widget 3 tiles on x. The rounding is the key here. only if the grid movement is >= ?.5, you snap to the next tile. Otherwise you simple stay at the old one.
Hope this can give you a general hint on how to start a form designer. Have fun. :)
(PS: Don't know about any specific WinAPI/MFC functions/class to help you along, sorry.)
Just to add a point or two to what #Xeo has already said:
First of all, no, you don't always draw all the content yourself. During normal design phase you're basically just drawing something that looks like the control, but (at least IIRC) it also lets you "run" a form in test mode (certainly the VC++ dialog designer does, and even though VB's was more primitive, I think it did have that particular capability as well). Test mode was when you can "run" a form before you've (necessarily) attached any code to it -- even though clicking a button (for example) doesn't do anything in the surrounding program, the control itself works as normal -- a button clicks normally, an edit control will let you edit, etc.
That is done by actually instantiating a control, telling it the correct position, size, and properties. ActiveX controls do quite a bit to support this, and the previous "Windows custom controls" did as well, though with considerably less sophistication. From the viewpoint of the control, it's working just about exactly like it normally would, receiving input, sending notification to its parent, etc. The only thing that's changed is that the parent most ignores most of the notifications it receives, but the control doesn't really know that.
There are two basic ways to do this. One is to create a collection of controls yourself, along with their positions, sizes, etc., and use CreateWindow (or CreateWindowEx, etc.) to create window of the correct class. While relatively easy to handle, this has the disadvantage that it leaves all the tab-handling to you.
The other possibility is to create a DLGTEMPLATE structure to hold data about the dialog box, and a some DLGITEMTEMPLATES for the individual controls, and finally use CreateDialogIndirect to create a dialog box with those specs, holding those controls. It's tedious, but it works, and when you're done it handles tabbing between controls automatically (and works the same as any other dialog, since it's the same Windows code creating it either way).
Second, since you've tagged this C++, you might want to take a look at some code on CodeProject that actually implements a dialog editor. Although it isn't quite as sophisticated as some of the commercial ones, this is a reasonably complete form/dialog editor, complete with most of what you've asked about.
Is it possible to create table(mathematical table not kitchen table) by using glui? Please specify the function, if possible.
Thanks in advance.
From my experience with glui, and looking over the docs again, there doesn't seem to be a way to create a table.
One option is to just pack read only text boxes in a regular grid.. That would sort of poorly mimic a table.
Another option if you are getting to a point where glui simply isn't powerful enough is to switch to something like gtk or gtkmm. It would still allow you to render opengl (through gtkglext), but it would also enable you to use all of the gtk widgets (here's a gallery: http://library.gnome.org/devel/gtk/2.21/ch02.html -- not that I see a table there either).
Again from my experience, gtk is quite a bit harder to start using as compared to glui, but i think it's worth the effort for an involved gui.