 |
|
 |
Great class. Very easy to use. Article could use a bit more details such as explaining the actual IDs of the hidden labels and correcting what appear to be small errors in the examples.
|
|
|
|
 |
|
 |
To use vertical or horizontal (default) mode:
File "DialogExpander.h"
void Initialize(CWnd *pDialog, BOOL bInitiallyExpanded, int IdExpandButton, int IdCollapsedMark, int m_IdCollapsedText, BOOL horizontal=true) ;
void OnExpandButton(BOOL horizontal=true) ;
File "DialogExpander.cpp"
void ShrinkDialog(CWnd *pDlg, int idmark, BOOL horizontal=true)
{
....
if(horizontal)
offset = dlgrect.Height() - clientrect.bottom ;
else
offset = dlgrect.Width() - clientrect.right ;
....
if(horizontal)
dlgrect.bottom = dlgrect.top + markrect.bottom + offset;
else
dlgrect.right = dlgrect.left + markrect.left + offset;
....
}
void CExpandDialog::Initialize(CWnd *pDialog, BOOL bInitiallyExpanded,
int IdExpandButton, int IdCollapsedMark,
int IdCollapsedText, BOOL horizontal)
{
....
else
OnExpandButton(horizontal) ;
}
void CExpandDialog::OnExpandButton(BOOL horizontal)
{
....
else
ShrinkDialog(m_pDialog, m_IdCollapsedMark, horizontal ) ;
....
}
|
|
|
|
 |
|
 |
Use a disabled picture frame to surround the "less" area and then use GetWindowRect() in the OnInitDialog() function to get the bottom of the rectangle for SetWindowPos().
GetWindowRect(&m_rectDialogRect);
m_rectLessDialogRect = m_rectDialogRect;
CRect rect;
m_cLessFrame.GetWindowRect(&rect);
m_rectLessDialogRect.bottom = rect.bottom;
Steve
|
|
|
|
 |
|
 |
just class version.
class CExpander
{
public:
enum {
ShowBottom,
ShowRight
};
CExpander() { m_hWnd = NULL;}
BOOL Init(HWND hWnd, HWND hWndFirstRoll, int nMargin = 0, int nDir = ShowBottom)
{
ASSERT( ::IsWindow(hWnd) && ::IsWindow(hWndFirstRoll) );
m_hWnd = hWnd;
CRect rcFull;
::GetWindowRect(hWnd, &rcFull);
CRect rcCtrl;
::GetWindowRect(hWndFirstRoll, &rcCtrl);
m_cxFull.cx = rcFull.Width();
m_cxFull.cy = rcFull.Height();
if (nDir == ShowBottom)
rcFull.bottom = rcCtrl.top + nMargin;
else
rcFull.right = rcCtrl.left + nMargin;
m_cxLess.cx = rcFull.Width();
m_cxLess.cy = rcFull.Height();
return TRUE;
}
void Expand(BOOL bShow)
{
ASSERT(m_hWnd);
if (bShow)
::SetWindowPos(m_hWnd, NULL,
0,0,m_cxFull.cx, m_cxFull.cy,
SWP_NOMOVE|SWP_NOZORDER);
else
::SetWindowPos(m_hWnd, NULL,
0,0,m_cxLess.cx, m_cxLess.cy,
SWP_NOMOVE|SWP_NOZORDER);
}
protected:
SIZE m_cxFull;
SIZE m_cxLess;
HWND m_hWnd;
};
|
|
|
|
 |
|
 |
Do you or anyone else have an example of how to create an expandable property sheet?
Thanks in advance for the help!
Rick S.
|
|
|
|
 |
|
 |
This is a great class and simple to understand/use.
I modified the Initialize() function and the method in which this expanding/collapsing dialog can be used.
By changing the 3rd argument to CExpandDialog::Initialize() to recognize a NULL value (or any invalid resource value), you can make the expand/collapse happen programmatically rather than using a button.
You just need to check for a button in Initialize() and in OnExpandButton()
If (IdExpandButton == NULL)
{
// calling expand/collapse without use of "More/Less" button
// don't have to SetWindowText() for the button
}
Don't forget to address your controls that are hidden when in Collapsed Mode. Disabling the hidden button should preserve your TAB sequence.
Cheers!
Johnny
|
|
|
|
 |
|
 |
i just want to express my appreciation...
the beauty of this code lies in its simplicity, ease of use and modality.
two thumbs up.
did you backup? why, is it gonna blow?
|
|
|
|
 |
|
 |
Good job!
I think that your idea to set the expand and collapse boundaries of the dialog is clever and I like it.
There is one problem that I see though, when the dialog is collapsed, it is still possible to tab to the items that are out of view. In your demonstration app it is a little hard to tell this becuase there is only one tab point that is hidden (the radio buttons).
|
|
|
|
 |
|
 |
You could change a little the sources and provide a (pure) virtual function in CExpandDialog you can override to fit your dialog needs. Your problem could be solved by disabling all hidden controls and then re-enabling them when expanding.;)
e.g.
class CExpandDialog
{
...
protected:
virtual void OnExpandCollapse(BOOL bExpanded)
{
//Enable / Disable all controls shown / hidden
}
...
}
you also need to change CExpandDialog::OnExpandButton() to also call OnExpandCollapse. Something like:
void CExpandDialog::OnExpandButton()
{
...
m_bIsExpanded = !m_bIsExpanded ;
OnExpandCollapse(m_bIsExpanded);
...
}
|
|
|
|
 |
|
 |
I've implemented the expand/collapse class example and like it very much. There is one question and problem I have.
Can this work for "any" control that is positioned in the expand/collapse area of the dialog? I tried a RichEdit control in the area that would be hidden when collapsed and the dialog doesn't appear - some buried error that halts creation of the dialog.
When I replace my RichEdit control with an edit control (or another control), the dialog is created, appears, and the expand/collapse operation works as expected.
I would like to use a RichEdit control but may work around this in other ways.
Thanks.
Johnny
|
|
|
|
 |
|
 |
You must initialize rich edit control before using it.
A good place for initializing it is in InitInstance method. Just call AfxInitRichEdit() function.
|
|
|
|
 |
|
 |
A more efficient way...with "MoveWindow" :
////////////////////////////////
// CMyDialog message handlers
void CMyDialog::OnExpandButton()
{
RECT rect ;
GetWindowRect( &rect ) ;
if ( m_bExpandWnd == true )
{
rect.right -= 170 ; //necessary value
MoveWindow( &rect ) ;
m_ExpandButton.SetWindowText( ">>" ) ;
m_bExpandWnd = false ;
}
else
{
rect.right += 170 ;
MoveWindow( &rect ) ;
m_ExpandButton.SetWindowText( "<<" ) ;
m_bExpandWnd = true ;
}
}
///////////////////////////////////////////
LX :-
|
|
|
|
 |
|
 |
No! This is a much simpler way, but an efficient one? Why hard-code window height, when you can calculate it? If you add N more controls (static controls to make it simple) you want hidden / shown, or resize the existing ones, are you willing to play with pixels every time to get the exact size added / removed?
|
|
|
|
 |
|
 |
And the pixel size of a dialog varies depending on the version of windows and the font size.
Matt
|
|
|
|
 |
|
 |
When shrinking the dialog box, you would probably want to disable all of the child window that are outside of the visible client area. And enable them when expanding the dialog. Otherwise if you use the Tab key, the focus may be hidden at some point.
for (all the child)
{
Get the window rect
Calculates the intersection of the visible dlg rect & child
Enable/disable the child
}
|
|
|
|
 |
|
 |
But then you also would have to remember the enabled/disabled state.
Since some items could be disabled even when visible, due to the program-context in which the dialog is used.
--
See me: www.magerquark.de
|
|
|
|
 |
|
 |
I don't think this is a problem. You would have to remember the states eitherway, even if you didn't use the expand/collapse effect.;)
|
|
|
|
 |
|
 |
I don't think that this is a problem either. I have a similar dialog and when it is collapsed tab does not set focus onto the hidden controls even though I have not explicitly disabled them.
Matt
|
|
|
|
 |