|
Hi,
I am having trouble keeping a child window maximized within its parent while the parent is resizing.
The child window is a class derived from cwnd and is a member variable of its parent.
The child is created with the dwStyle WS_MAXIMIZE and so starts off maximized. However when the parent is resized the child remains the same.
Is there a way of locking the child in the maximised position?
Or is there a way to direct the WM_SIZE message from the parent to the child?
I would be grateful for any help.
|
|
|
|
|
In WM_SIZE handler of the parent, use child->MoveWindow(0, 0, cx, cy). cx and cy are client size width/height passed to OnSize.
Tomasz Sowinski -- http://www.shooltz.com.pl
|
|
|
|
|
Thank you, but there is a slight problem with this.
When the Child is initially created maximized it's border or frame is not shown.
However when the resizing begins, it's frame appears just inside it's parents.
Any Ideas?
|
|
|
|
|
Do you need the caption and frame for the child? If yes, use SetWindowPlacement instead of MoveWindow.
If no, just remove WS_MAXIMIZE and other caption/frame styles. WM_SIZE will work with MoveWindow.
Tomasz Sowinski -- http://www.shooltz.com.pl
|
|
|
|
|
I can't to access to global variables in my dialog project from all the classes.
If I define them in header file and call this file from all the dialogs of the project -the compailer cry that it is already defined,
So,The same,if I define it in some source files(cpp).
and if I define it only in the main source it shout that there ara undeclared variables
when I use in this global variables ???
WHAT HE WANT THAT I WILL DOING ?????????????????????????????
miki
|
|
|
|
|
when you want to use global variable from other file
you must declare with extern atribute:
main.cpp:
CMainApp theApp;
.
.
.
---------------------------------------------------------
other.cpp:
#include "where is class declared.h"
extern CMainApp theApp;
.
.
.
now you can use theApp variable in other.cpp
|
|
|
|
|
you need to redeclare them in each class with an extern in front of them.
ie. extern int i;
Scott Croston
|
|
|
|
|
Global variables tend to be considered bad programming....and, they can be hard to keep up with.
If you need something to store temporary data, say the state of a dialog or something and you want to be able to access it anywhere (Views, threads, etc.)
You might simply consider storing it in the MainFrame class. It is easy to get a pointer to the Mainframe from pretty much anywhere.
Example:
CMainFrame *pMF = (CMainFrame*)AfxGetApp()->m_pMainWnd;
BOOL bDialogState = pMF->bDlState;
Hope this helps........
|
|
|
|
|
 the solution of decalring the variable in CMainFrame class is fine but what if ur application is thread oriented whaer u dont need any GUI hence one need not use the Frame class so how can one access to a global variable.
|
|
|
|
|
|
It is essentially the Dlg class, the main dialog box, which will be the parent of any other dialog you create. I'd suggest putting a global in the CWinApp derived class though, assuming that is what you want to do. Actually, I'd suggest *not* using a global, but ( not having read the thread ), I'd assume it's already been established that you have no choice ??
Christian
#include "std_disclaimer.h"
|
|
|
|
|
Well, that has to be my *most* stupid post ever. Talk about thick. I need more sleep, and less children in my bedroom.
Obviously, if a variable is in your CWinApp derived class, it is not a global at all. So that is what I would recommend. Globals are the work of Satan, and should be avoided where-ever possible.
Christian
#include "std_disclaimer.h"
|
|
|
|
|
Thank you , But when I define my variables in CWinApp all the other classes
do not identify them.
What can I do ???
|
|
|
|
|
From any other class
#include "CMyApp.h";
...
CMyApp * pApp = (CMyApp*) AfxGetApp();
pApp->m_MyVariable = 6; // Actually, Get/Set methods would be better, but for the sake of simple illustration....
Christian
#include "std_disclaimer.h"
|
|
|
|
|
If you're going to use global variables, do it this way (some of this code assumes you're using Visual C++ and MFC):
Create a header file with allof your variables defines as "extern", like so:
1) Create a file called "Globals.h", that contains these lines:
#ifndef __GLOBALS_H
#define __GLOBALS_H
#endif
2) Type in your variable declarations under the comment line, like so (the ones I'm showing here are merely for example):
extern int g_nMyInt;
extern CString g_sMyString;
3) Create a file called Globals.cpp, that contains these lines:
#include "stdafx.h"
#include "Globals.h"
#ifdef _DEBUG
#undef THIS_FILE
static char THIS_FILE[]=__FILE__;
#define new DEBUG_NEW
#endif
#endif
4) Under the comment line that reads "// insert your variables here", add the following lines:
int g_nMyInt;
CString g_sMyString;
All you then have to do to use these global variables is add the Globals.h and Globals.cpp files to your project, and add the following line at the top of any CPP file that uses one of your global variables:
#include "Globals.h"
|
|
|
|
|
I use CInternetSession to communication, and my PC is under a firewall, so I should use CInternetSession::SetOption to pass the firewall. But whatever I SetOption with the flags- INTERNET_OPTION_USERANAME and INTERNET-OPTION_PASSWORD, it return a error number with 6.
My code are listed below:
CHAR szUser[50]="mm";
CHAR szPass[50]="love";
b = m_pRobotSession->SetOption(INTERNET_OPTION_USERNAME, szUser, lstrlen(szUser));
b = m_pRobotSession->SetOption(INTERNET_OPTION_PASSWORD, szPass, lstrlen(szPass));
These questions bother me for several days. Can you help me? Thanks a lot.
|
|
|
|
|
I have display a bitmap in the client area,if i want to erase it and blacken the background,how can i?
Thanks in advance for anyone's help.
julia
|
|
|
|
|
How did you draw it ? If you drew it in OnPaint directly to the client area, just Invalidate(false) to force a redraw, and have a flag set so it doesn't draw again. This will not erase the bitmap, because the (false) means no erase ( to stop flicker), but as you want a black box instead, you use dc.FillSolidRect to draw over the same area in black (RGB(0,0,0)). If it's drawn in a control, you'll call ShowWindow(SW_HIDE) on the control in your paint code, and draw the box, still calling OnPaint by the Invalidate call ( don't ever call OnPaint() directly ).
Christian
#include "std_disclaimer.h"
|
|
|
|
|
One of our projects is getting so large that development has become quite cumbersome due to the time it takes to link it. The project is an ocx that statically links MFC, CRT and a few other large libraries. Linking often takes a minimum of 45 seconds on my workstation (Dual P3-733, 384M ram, 10K rpm disks). I have tried everything and can't find anyway of reduceing the link times. The OCX is 20 megs in debug, 5 megs in release. Does anyone have any suggestions, or am is this typical for a project of this size?
Chris Hafey
PS - We have incremental linking turned on and using a dynamically linked version is not an option
|
|
|
|
|
One thing that really reduces compile/link times is multible disks and a RAID.
I have 3 SCSI disks, with 2 of them in a Win2k software RAID 0 (Stripe Set), and it goes like 75% faster 
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
If you are using large number of dlls you can use the delayload feature in VC6++.
Dll rebasing can also help performance.
When linking, it helps if ALL the files are on the same local drive...
Also, I noticed in my include/lib paths, I had a large number of redundant paths, taking these out, helped greatly.
Just things that helped me.
Gerry.
|
|
|
|
|
I doubt that delay load will speed up link times.
Delayload speeds up 'apparent' load times. It does this because the linker inserts
extra code into the DLL to handle delay loading. The fact that the linker has more to
do when delay loading makes me think this option will not decrease link time. The linker
still has to resolve the same number of symbols as with the non delay-loaded case, but
also has to write the delay load stubs (one per function per delay loaded DLL) and the
delay load handler (one per delay loaded DLL).
Stephen Kellett
Since I can't post on the forums, for the guy that was interested in UK developer magazines, I can't offer any help, but contact Parkway Gordon (not sure of web address
but try the obvious... and try google). Parkway Gordon are based in the UK and handle
magazine subs for most of the better American mags, and the service is superb. Not
connected in anyway except as a very happy customer.
|
|
|
|
|
I'm setting up printing in my program, and the idea is that we present a dialog that allows the user to format the page, then we print it. I bring up the dialog in OnPreparePrinting, and pass in the pInfo item. The problem is, I want to know my printable area so I can allow the user to set the page up, taking into allowance the set margins of the printer ( i.e. the printable area, as opposed to the page area ). My problem is the pInfo struct has a perfect data member for this, call m_rectDraw, but it contains garbage until OnPrint. I can stretch my bitmap perfectly over the page in OnPrint, but I need to know those values in OnPreparePrinting AND see them change when I flick between Portrait/Landscape or set a new paper size. Can this be done ? I even toyed with setting up a function that runs through the print sequence, but I am already in the middle of it AND I'm not sure I can do it without something printing - I tried setting the bContine flag to false in OnPrint to no avail.
This is all too convoluted and I am sure I am missing something, but I can't see it in the MSDN. Any help will result in instant good karma, plus some of my wife's famous chocolate cake the next time you're in Hobart...
Christian
#include <std_disclaimer.h>
|
|
|
|
|
hey christian
check out CWinApp::SelectPrinter()
it might have some stuff you need
---
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
Thanks. I am determined this time to use the MFC architecture, and it seems like a round robin race through different View functions, via the App class. I could have dropped it and done it the way I did before (Win32) , but there is no way this damn machine will get the better of *me*.
Christian
#include "std_disclaimer.h"
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
