[comp.windows.ms.programmer] MDI devloper Pen Pal

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