jnh@ecemwl.ncsu.edu (Joseph N. Hall) (09/06/89)
Ever tried printing a pane with subpanes that needed to be informed that printing was about to commence? It turns out that ONLY your document's "main pane" receives the AboutToPrint(), PrintPage(), and DonePrinting() messages. I think this is totally incorrect behavior. Your main pane AND ALL ITS SUBPANES should receive these messages during printing. After all, the main pane AND its subpanes (subviews) are ALL printed, since they output to the printer port through DrawAll(). I have a class, for example, that relies on subpanes for printing headers and footers, which remain invisible until printing commences. At print- time, I have to 1) make them visible, and 2) expand their frames to meet the page borders. Currently, the header and footer pane classes override AboutToPrint() etc., which I call explicitly from my main editing pane's AboutToPrint() etc. methods. But I think the best approach, by far, would be to revise CDocument (or whatever, I forget) to send these messages recursively to all of the main pane's subviews. I'm currently treating the Class Library as read-only, since I want to be able to distribute sources of my own as easily as possible. I hope that some of the minor glitches (like this) will be dealt with in future releases so that I'm not tempted to deal with them myself ... v v sssss|| joseph hall || 4116 Brewster Drive v v s s || jnh@ecemwl.ncsu.edu (Internet) || Raleigh, NC 27606 v sss || SP Software/CAD Tool Developer, Mac Hacker and Keyboardist -----------|| Disclaimer: NCSU may not share my views, but is welcome to.
fjlim@garnet.berkeley.edu (09/07/89)
In article <3874@ncsuvx.ncsu.edu> jnh@ecemwl.UUCP (Joseph N. Hall) writes: > [Discussion of problem that only the "main pane" receives an AboutToPrint() message before printing starts. Subpanes do NOT receive this message] Well, Joseph, you got me on this one. You are absolutely right. The main pane and all its subpanes should receive AboutToPrint() messages. Here are a few comments about some remarks you made in an earlier posting. I have paraphrased your original words. (sorry to have taken so long to respond) > SetFontName() and SetFontSize() should be overriden in CEditText.c so that the font and size menus are updated whenever the font name or size is changed. An interesting suggestion, although there are potential problems. The program would have to search the menus for the specified font name or number (converted to a string). It's possible to have a menu where item names are not unique. For example, a menu which has both line thicknesses and font sizes, differentiated by appropriate use of headings and dotted lines. > Panorama does not adjust itself if it is resized so that its frame is larger than its bounds. i.e., scrolling to the bottom right and then making it bigger. Although this behavior does cause the problem of a panorama being requested to draw an area outside its bounds (a situation which you must check for in your Draw() method), I think it is the best default approach. You point out that you have seen this behavior in other programs but you don't think it is correct. However, I think there are times when it is correct. Text editing is one example. I like to see white space added when I get to the end of a text document and make the window taller. This is what the THINK C editor does. On the other hand, graphics applications where there is the concept of a fixed document size should adjust so that you never see the undefined area which is off the page. > It's possible to process the click which activates a window. However, controls are not activated until after the window is actually activated, so it's not possible for controls to respond to such activating clicks. For example, you can't click on a button in an inactive window and have the program recognize that you clicked on the button. This is partly a user-interface issue. In the THINK Class Library (TCL), controls in inactive windows are deactivated (grayed out). Clicking on an inactive control should have no effect. If you want to allow the user to click on a control in an inactive window, you should not deactivate the control. You could create a subclass of CButton, for example, which overrides the Deactivate() method, or explicitly activate the button in the Deactivate() method of your CDocument subclass. > Active controls in a window are not deactivated when a new window is creat on top of that window. This is certainly not true in all cases. In the demo programs, the scroll bars of the formerly active window are deactivated (by hiding them) when a new window is created. It's handled as part of the normal deactivation process. If you have some code where controls aren't being properly deactivated, you may have found a bug. If so, send more info via e-mail to me. >I'm currently treating the Class Library as read-only, since I want to be >able to distribute sources of my own as easily as possible. This is the recommended approach. Gee, wouldn't it be nice if there were an "open read-only" feature in the editor so you couldn't accidently alter the code in the library files? >I hope that >some of the minor glitches (like this) will be dealt with in future releases >so that I'm not tempted to deal with them myself ... Based on my experiences in dealing with Symantec in developing the TCL, I know that they are strongly committed to supporting and improving their products. So keep reporting glitches and bugs here on UseNet or directly to Symantec tech support. Your efforts will not be in vain. --- Gregory Dow DISCLAIMER: I wrote the TCL but am not an employee of Symantec. I can say anything I want and not get fired.