ssl@hpkslx.mayfield.HP.COM (SSL Guest User) (04/09/91)
Greetings. Anyone out there writing MDI applications? I would like to begin corresponding to someone working with MDI in order to exchange ideas, commiserate on problems, etc. I've been working on a fairly large MDI app for some time and could use the perspectives of another also living this nightmare. In the mean time, I am wondering how Microsoft Excel (tm) creates the row of push buttons directly below the Menu bar. These buttons are most certainly part of the Client area, but i'm wondering how to prevent the MDICREATE from taking over the entire client area, thereby slamming the buttons. Does this make any sense? I look forward to hearing from somebody out there. Best regards, Thomas Dayton thomas@hpssl40.mayfield.hp.com ssl@hpkslx.mayfield.hp.com
dsampson@x102a.harris-atd.com (sampson david 58163) (04/16/91)
In article <25920007@hpkslx.mayfield.HP.COM> ssl@hpkslx.mayfield.HP.COM (SSL Guest User) writes: In the mean time, I am wondering how Microsoft Excel (tm) creates the row of push buttons directly below the Menu bar. These buttons are most certainly part of the Client area, but i'm wondering how to prevent the MDICREATE from taking over the entire client area, thereby slamming the buttons. About a year ago I started fooling with trying to create a toolkit of sorts to handle some common things like a spreadsheet type of interface (the grid look, not necessarily the full functional capability). I ran into a problem that drove me nuts when it came to laying out the grid. If you look in the Petzold book to see how he does vertical line spacing, you'll see that he determines the height of a line by adding tmHeight + tmInternalLeading + tmExternalLeading => yLineHeight The thing that drove me nuts was trying to set up a loop to draw the horizontal lines of the grid so that they would be equi-distant between the top and bottom of rows of text, i.e. draw a perfectly semetrical line between two rows of text. To establish the line position (that can be multiplied by a for statement loop counter variable) I tried variations of tmHeight + tmInternalLeading or tmHeight + tmExternalLeading, etc. I could never get the thing right. It was further compounded by the particular mapping mode that was selected. MM_ANISOTROPIC was a particular pain. When world coordinates were scales, boy did that throw off the vertical line spacing. Everything would look OK on the first few lines, but as you drew more and more lines (about 100 should do it) the verticle "distortion" grew worse. If you look at Excel, you'll notice that the row buttons and the horizontal lines for the spreadsheet grid line up exactly, independent of the video mode (i.e. EGA, VGA, etc) and they are perfectly symetrical. Am I dumb or what??? Anybody know how they did this? -- A new world record in the javalin throw / / / I ------------------------------------------------- David Sampson Harris Corporation dsampson@x102a.ess.harris.com Gov't Aerospace Systems Divison uunet!x102a!dsampson Melbourne, Florida -------------------------------------------------------------------------------
bcw@rti.rti.org (Bruce Wright) (04/16/91)
In article <DSAMPSON.91Apr15130446@x102a.harris-atd.com>, dsampson@x102a.harris-atd.com (sampson david 58163) writes: > About a year ago I started fooling with trying to create a toolkit of > sorts to handle some common things like a spreadsheet type of > interface (the grid look, not necessarily the full functional > capability). I ran into a problem that drove me nuts when it came to > laying out the grid. > > The thing that drove me nuts was trying to set up a loop to draw the > horizontal lines of the grid so that they would be equi-distant > between the top and bottom of rows of text, i.e. draw a perfectly > semetrical line between two rows of text. > > It was further compounded by the particular mapping mode that was > selected. MM_ANISOTROPIC was a particular pain. When world > coordinates were scales, boy did that throw off the vertical line spacing. > > Everything would look OK on the first few lines, but as you drew more > and more lines (about 100 should do it) the verticle "distortion" grew worse. I'm not sure exactly what your problem is, but there are a couple of possibilities. You might have been seeing aliasing caused by having the mapping mode not match the display resolution. If you are setting the loop up properly the aliasing shouldn't be cumulative (as seems to have been the case with your problem from your description), but some lines would appear to be a pixel or two off. (Although this doesn't seem like a lot, for screens with a lot of horizontal or vertical lines the eye can often zero in on those that are a bit "off", even if the line isn't really very far off). You might also have managed to get some of the aliasing for one line added back into the next (not having seen your code I can't say ...), this could cause a cumulative effect. The usual way to deal with this is to run in MM_TEXT for placement of things like lines, so that you know exactly where things are going to end up. In general you can get better results with the MM_TEXT mode for most graphical operations, but at the cost of making your code more complex. Bruce C. Wright
gpsteffl@sunee.waterloo.edu (Glenn Steffler) (04/16/91)
In article <25920007@hpkslx.mayfield.HP.COM> ssl@hpkslx.mayfield.HP.COM (SSL Guest User) writes: >Anyone out there writing MDI applications? Just finished one for a school credit project. Pretty nice interface. 1/2 :-) Anyway on to door # 1 : >In the mean time, I am wondering how Microsoft Excel (tm) creates >the row of push buttons directly below the Menu bar. These buttons >are most certainly part of the Client area, but i'm wondering how >to prevent the MDICREATE from taking over the entire client area, >thereby slamming the buttons. Do you mean the FRAME area of the MDI client area? Affects my answer... The MDI client area does not prevent you from opening a child window on its premisis. Simply create a child window to hold the buttons, and another child to hold the rest of the area (or whatever). Look at multipad (SDK source example), it opens an edit control on the MDI child area...mabe I don't understand your question?!? >Does this make any sense? Huh? :-) >Best regards, >Thomas Dayton > >thomas@hpssl40.mayfield.hp.com >ssl@hpkslx.mayfield.hp.com By the way, Excel doesn't use MDI, it uses an internal substitute by the apps-tools group. Allows cross platform development etc to proceed much easier. -- Windows Sumo Wrestler "Bo doesn't know software" - George Brett --(Windows 3.0, a combination of modern moodring technology and voodoo)-- "I guess she had a way, of making every night seem bright as day" `I Don't Believe In Love` -Queensryche (Oper. Mindcrime) Glenn Steffler
dsampson@x102a.harris-atd.com (sampson david 58163) (04/16/91)
In article <1991Apr16.033639.11295@rti.rti.org> bcw@rti.rti.org (Bruce Wright) writes: You might have been seeing aliasing caused by having the mapping mode not match the display resolution. If you are setting the loop up properly the aliasing shouldn't be cumulative (as seems to have been the case with your problem from your description), but some lines would appear to be a pixel or two off. (Although this doesn't seem like a lot, for screens with a lot of horizontal or vertical lines the eye can often zero in on those that are a bit "off", even if the line isn't really very far off). The distortion from scaling from a mapping mode world coordinate system to the screen pixels was definitely a factor, but I don't think it was the major problem. If you look at the diagram in the Petzold book where he explains the tmHeight, tmInternalLeading, and tmExternalLeading, you can see that the area you have to play with in terms of drawing a line, is somewhere in the tmExternalLeading region. So as plan B, I tried to trigger the line drawing off of a fractional relationship like this: /* this is declared somewhere in the code */ yChar = tmHeight + tmInternalLeading + tmExternalLeading; /* now for the loop to draw the line between rows of text */ for (y = 1; y <= someMaxNum; y++) { /* location to draw line */ yLine = (yChar + .3 * tmExternalLeading) * y; /* then draw the line at yLine */ } This routine draws the line below the row of text. So to get the proper position, you have to go down the height of the character plus some fraction of the external leading. I choose 0.3 off the top of my head as I was typing this msg. The result of the multiplication will also have to be converted to an integer. What I could not home in on was the proper fraction. If you choose a mapping mode other than MM_TEXT, the coordinate conversion distortion you mention will rear its head and byte you :) This approach also leads to major verticle offset problems when you have lots of rows. Eventually the lines will overlap the text; once again, due to the fraction rounding error and the mapping mode coordinate distortion. Any thoughts on a better approach? -- A new world record in the javalin throw / / / I ------------------------------------------------- David Sampson Harris Corporation dsampson@x102a.ess.harris.com Gov't Aerospace Systems Divison uunet!x102a!dsampson Melbourne, Florida -------------------------------------------------------------------------------
bcw@rti.rti.org (Bruce Wright) (04/17/91)
In article <DSAMPSON.91Apr16105552@x102a.harris-atd.com>, dsampson@x102a.harris-atd.com (sampson david 58163) writes: > > [talking about writing text separated by horizontal lines, and > problems with rounding and aliasing effects] > > This routine draws the line below the row of text. So to get the > proper position, you have to go down the height of the character plus > some fraction of the external leading. I choose 0.3 off the top of my > head as I was typing this msg. The result of the multiplication will > also have to be converted to an integer. > > What I could not home in on was the proper fraction. If you choose a > mapping mode other than MM_TEXT, the coordinate conversion distortion > you mention will rear its head and byte you :) > > This approach also leads to major verticle offset problems when you > have lots of rows. Eventually the lines will overlap the text; once > again, due to the fraction rounding error and the mapping mode > coordinate distortion. OK, that gives me a better idea of what you were doing. I had similar problems with some other things I wrote, as long as I used floating point (the program wasn't drawing text, but the principles were the same). I finally gave up on using floating point for that purpose; things were always turning out to be a pixel off or something (and as I mentioned before, the eye can be drawn to that kind of error if it's part of a pattern). I finally started doing all of the computations manually, using integers. If the computations wouldn't fit in a short integer, I'd often have to convert to a long integer (usually just within the expression using the (long) type casting). It made for somewhat messier code, but most of the mess could be confined to a single scaling routine and a couple of macros. If you're careful on setting this up you can avoid the normal floating point rounding error. Plus, the program also was smaller and ran faster - no floating point runtime overhead. I'd also suggest positioning each text cell explicitly, and drawing the line associated with it based on the position you drew the text cell, not on where you compute the text cell ought to land. In my program, the scaling routine would compute how "high" every object ought to be, and saved this in global variables. Then I could find the start of the object with a simple, integer multiplication. It works better in MM_TEXT because you don't get the aliasing effects that you'd get in other modes, but even in something like MM_ANISOTROPIC you wouldn't get cumulative effects if both the text and the lines were drawn using the same scaling factor. Good luck - Bruce C. Wright
bcw@rti.rti.org (Bruce Wright) (04/17/91)
In article <DSAMPSON.91Apr16105552@x102a.harris-atd.com>, dsampson@x102a.harris-atd.com (sampson david 58163) writes: > > [Text, lines, and aliasing] > > If you look at the diagram in the Petzold book where he explains the > tmHeight, tmInternalLeading, and tmExternalLeading, you can see that > the area you have to play with in terms of drawing a line, is > somewhere in the tmExternalLeading region. So as plan B, I tried to > trigger the line drawing off of a fractional relationship like this: > > /* this is declared somewhere in the code */ > yChar = tmHeight + tmInternalLeading + tmExternalLeading; > > /* now for the loop to draw the line between rows of text */ > for (y = 1; y <= someMaxNum; y++) > { > /* location to draw line */ > yLine = (yChar + .3 * tmExternalLeading) * y; > > /* then draw the line at yLine */ > } One other thing - I don't know if this is just a typo when you typed in your article, or if it's actually in your program (in which case this could be most of your problem right there). Shouldn't the location to draw the line be computed as yLine = yChar * y + .3 * tmExternalLeading; Seems to me you have an extra factor of y * .3 * tmExternalLeading in your expression (since tmExternalLeading is also part of the computation of yChar). Good luck - Bruce C. Wright