|
I sent you an email reply, but I'll summarize what I said in the email.
Create a struct containing the data you want to send to the other application, and put a (void) pointer to that struct into the lpData field of the COPYDATASTRUCT variable. You can actually send any pointer you want as long as the app know how to handle the pointer. I use the dwData field to indicate what type of struct/pointer I'm sending, and the receiving app traverses a switch statement to determine what to do with the pointer.
|
|
|
|
|
Hi John, I haven't receive your email. Can you send it again or directly go to sly@hkid.com. Thanks so much.
|
|
|
|
|
I've tried to generate a SplitterBar
under the following preconditions: SDI without Document/View Architecture
It didn't work
I used VC++ 6.0, ServicePack5
MFC Wizard
Splitter: Menu Project; Add To Project ; Components..;Visual C++; SplitterBar
Does it work on your PC?
Have you an idea why it doesen't work?
Is there any other Idea how to do it manually?
Greetings
Andrew
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
