badges
asked on
Scaling CFormView
I have written an order enty program that uses a CFormView dialog resource as the main screen. The PC I used to develop the code was in 800 X 600 mode. Now that other users are using the program, they are getting annoying scroll bars even when in 800 X 600 and without any other desktop interference (Office Bar, Start Bar, etc)
My ultimate goal is to resize the CFormView to fit at either 640 X 480, 800 X 600, and 1024X768. How do programmers usually deal with different display settings? Also, why are there scroll bars on every other system at 800 X 600 but not on mine? I have tried using various combinations of SetScaleToFitSize() and GetParentFrame()->RecalcLa
My ultimate goal is to resize the CFormView to fit at either 640 X 480, 800 X 600, and 1024X768. How do programmers usually deal with different display settings? Also, why are there scroll bars on every other system at 800 X 600 but not on mine? I have tried using various combinations of SetScaleToFitSize() and GetParentFrame()->RecalcLa
ASKER
VC++ 5 Win95
How should the controls on the form do after you resize it ? Should they change their sizes accordingly / move around ? Or do you want them to stick in upper left area of the resized dialog window ?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
The Contradiction Between Flexibility and Rapid Development
-The condition of Dialog-based Windows and Size-Position Adaptation
Alesa Tang
Shanghai Bell SNA
98.6
Many programmer suffer pains when image to exploit the CFormView, CRecordView or CDialogBar to implement a Interface Rapidly and precisely. Because if the window*s size and position change, the dialog*s appearance will always be out of control. This kind difficulties are not only in VC, but also other tools like VB or Delphi.
Yes, its is easy to use dialog editor to locate the controls* position, size. But the dialog template has fixed physical location. The alternative is create the control dynamically as a child window in a view or controlbar. But these processes seem to be a little more laborious So a developer should make compromization when choose Rapid Develop or Flexibility.
Before make decision, the analysis should be taken carefully. There is two category of interface controls:
--Flexible Controls: CEdit, CTreeCtrl, CListCtrl,
--Not so flexible: Buttons, Radios, Checkboxes.
Which category is dominate in a interface? If the Flexible controls is major part, like the ClassView of the Visual Studio, a dynamic strategy should be selected. If you want outstanding effect, the labor is valuable. Other wise, the dialog template path might be better.
There is some factors shoul be take into consideration when create dynamic control:
1. The parent window*s OnSize should adjust the these child controls size and Position, like:
void COutputWnd::OnSize(UINT nType, int cx, int cy)
{
CControlBar::OnSize(nType,
if(cx>0)
{
RECT rc;
GetClientRect(&rc);
m_TabCtrl.MoveWindow(&rc);
rc.left+=5;rc.right-=5;
rc.top+=28;rc.bottom-=5;
m_Terminal.MoveWindow(&rc)
m_Terminal.RedrawWindow();
m_AlarmHisList.MoveWindow(
}
}
2. In dynamic controls case, if the 3D effect is wanted, you should draw some border lines manually.
Ref.
The Dockable PropertySheet in C++ topic group
-The condition of Dialog-based Windows and Size-Position Adaptation
Alesa Tang
Shanghai Bell SNA
98.6
Many programmer suffer pains when image to exploit the CFormView, CRecordView or CDialogBar to implement a Interface Rapidly and precisely. Because if the window*s size and position change, the dialog*s appearance will always be out of control. This kind difficulties are not only in VC, but also other tools like VB or Delphi.
Yes, its is easy to use dialog editor to locate the controls* position, size. But the dialog template has fixed physical location. The alternative is create the control dynamically as a child window in a view or controlbar. But these processes seem to be a little more laborious So a developer should make compromization when choose Rapid Develop or Flexibility.
Before make decision, the analysis should be taken carefully. There is two category of interface controls:
--Flexible Controls: CEdit, CTreeCtrl, CListCtrl,
--Not so flexible: Buttons, Radios, Checkboxes.
Which category is dominate in a interface? If the Flexible controls is major part, like the ClassView of the Visual Studio, a dynamic strategy should be selected. If you want outstanding effect, the labor is valuable. Other wise, the dialog template path might be better.
There is some factors shoul be take into consideration when create dynamic control:
1. The parent window*s OnSize should adjust the these child controls size and Position, like:
void COutputWnd::OnSize(UINT nType, int cx, int cy)
{
CControlBar::OnSize(nType,
if(cx>0)
{
RECT rc;
GetClientRect(&rc);
m_TabCtrl.MoveWindow(&rc);
rc.left+=5;rc.right-=5;
rc.top+=28;rc.bottom-=5;
m_Terminal.MoveWindow(&rc)
m_Terminal.RedrawWindow();
m_AlarmHisList.MoveWindow(
}
}
2. In dynamic controls case, if the 3D effect is wanted, you should draw some border lines manually.
Ref.
The Dockable PropertySheet in C++ topic group
ASKER