>>Hi. I have a form with a small grid space. I want my end-user to click on a "grow grid" button to make the grid full page. I cut & pasted my grid (class) onto a container and stretched the grid to fill the page. I use AddObject to activate the container.
My question: is there anything special that I have to do to the grid on the form when I activate the "big grid" with the same exact data (ie: hide, deactivate)?
Is there a better way to do this?>>

Hoo boy. God forbid you should ask a complex question.

Doing this right is way beyond the scope of a newsgroup, but I can give you a couple of pointers.

If the grid's going to take up the entire screen you need to give the user a way of sizing the grid back to its original size.
A successful technique is to build a grid container that houses the grid, a header and small command buttons.
The header and command buttons emulate the standard windows minimize/maximize/resize buttons and header.
This works well because it's a design paradign thats already recognized by the user.

What I've done in the past is create:

1) Grid container
2) "Header" container (in the grid container, at the top, full width)
3) Min/Resize/Max buttons (in the header container, off to the right)
4) Header label, good place to put descriptive information about the grid (in the header container, off to the left)
5) The grid (in the grid container, taking up what space is not consumed by the header container)

The largest issue is controlling the resizing of the components. Its going to be very tempting to write lots of code that tries to do everything in one shot. If you do that, you're sunk. The path to success resides in rigid enforcement of modularity.

Each component should be responsible for repositioning and resizing itself.
One exception: Because this class will be essentially self-contained, you can get away with making certain assumptions. For example, when resizing the master container's width, the header's components (min/resize/max buttons, etc.) need to know about each other and I've never had a problem with coordinating their repositioning in one piece of code.

*** code in the custom resize of the master container

WITH .conHeader
	*** put the header at the top, left corner of conGridWin,
	*** offset by the requirement to show the special effect
	.Left = m.lnInset
	.Top = m.lnInset
	*** expand the header's width to fill conGridWin
	.Width = THIS.Width - (m.lnInset * 2)
	
	m.lnConHWidth = .Width

	*** move the resize buttons to the right side of conHeader
	WITH .cmdMax
		.Left = m.lnConHWidth - .Width - 2
		m.lnCmdMinLeft = .Left - (.Width + 1)
		.REFRESH()
	ENDWITH
	
	WITH .cmdResize
		.Left = m.lnCmdMinLeft
		m.lnCmdMinLeft = .Left - (.Width + 1)
		.REFRESH()
	ENDWITH
	
	WITH .cmdMin
		.Left = m.lnCmdMinLeft
		.REFRESH()
	ENDWITH
	
	*** resize the label to fill the header, but not cover resize buttons
	WITH .lblHeader
		.Width = m.lnCmdMinLeft - (.Left + 10)
	ENDWITH
ENDWITH

*** grid takes the space remaining
.grdGrid.conResize()

Aside from this exception, your code will come together faster and run cleaner if you follow the general guideline that each component is responsible for itself.

*** code in the conResize() of the grid.

WITH THIS.PARENT
	THIS.LEFT = .conHeader.LEFT
	THIS.TOP = .Top + .conHeader.HEIGHT
	THIS.WIDTH = .conHeader.Width
	THIS.HEIGHT = .HEIGHT - .conHeader.HEIGHT
ENDWITH

Another temptation is going to be putting all of this resizing stuff in the Refresh event(s). Bad idea. Refresh() is called by all kinds of things and your code will be firing all the time. While tracing through legacy code, I've seen the same Refresh() code called as many as six times for one resize trigger. You may even get into situations where there are recursive calls, causing a tight loop effect. Instead, create a new method that's used explicitly to resize the container and its components. Then you can call the VFP default Refresh() within your custom (container) refresh, which allows the VFP base class events to do their stuff.

Hope this helps.

Good luck,
Thom C.