|
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"
|
|
|
|
|
Christian,
The CPrintDialog class contains a function to obtain the DC handle. Once you have the HDC, you can obtain the margins of the page.
In other words,
CPrintDialog dlg(TRUE); // or dlg(FALSE); gives you different Print Setup options
if (dlg.DoModal() == IDOK)
{
HDC hdc = dlg.GetPrinterDC();
long width = ::GetDeviceCaps(hdc, PHYSICALWIDTH)
- ::GetDeviceCaps(hdc, PHYSICALOFFSETX)*2;
long height = ::GetDeviceCaps(hdc, PHYSICALHEIGHT)
- ::GetDeviceCaps(hdc, PHYSICALOFFSETY)*2;
}
Keep in mind that you will probably have to add a little more margin than what the PHYSICALOFFSET constants return if you are printing on the edges. Many printers still cut off items that are printed on the edge of the margins. I usually just multiply the PHYSICALOFFSET by 3 instead of 2, and that takes care of the problem.
Mmm, chocolate.
|
|
|
|
|
I've been trying to use std::wifstream to read a unicode file, like so (in a project with UNICODE on):
std::wifstream wf;
wchar_t wch;
wf.open("unicode.txt");
while(wf.get(wch))
{
std::wcout << wch;
}
wf.close();
Funny thing is, this *still* reads the file byte by byte, NOT wchar_t by wchar_t. This means that if you had a 000D in the file, you'd get a 00 followed by a 0D, NOT a 0D as you'd expect. On the other hand, using the C style FILE* does work properly, as:
FILE* fp = _wfopen(L"unicode.txt", L"r+b");
wchar_t wch;
while(!feof(fp))
{
wch = fgetwc(fp);
std::wcout << wch;
}
fcloseall();
The above code accomplishes what I want. However, as I am not too keen on using just C or Win32 functions, can someone shed somelight on what's going on?
Thanks in advance,
Shanker.
|
|
|
|
|
i always use the CreatFile() ... ReadFile() ... stuff to read the file in as raw data and then convert to unicode (cast a pointer to it as a _TCHAR*)
works for me
---
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
Hey everyone!!!
I've been getting VERY STUPID DB exception raised by ODBC driver while trying to call CRecordset::Open(....) function.
The message says "Restricted data type attribute violation". Note that my data layer is SQL Server 2000.
If there is a POOR one who has suffered thru the same, please share your grief with me.
Big thanks ahead.
Kirill.
|
|
|
|
|
I've had the same error using SQL Server V7.0. It turned out that the order of the DoFieldExchange() member function of the recordset derived from CRecordset have to be in the same order as the table definition.
|
|
|
|
|
I am writing a program that has two windows in it (splitter). I want both sides to run a dialog. I have created the one for the right side, but when I try and run it I get a debug assertion error. Here is the code I am using:
In CMainFrame:
BOOL CMainFrame::OnCreateClient(LPCREATESTRUCT lpcs, CCreateContext* pContext)
{
if (!m_wndSplitter.CreateStatic(this, 1, 2, WS_CHILD) )
{
AfxMessageBox("Error Creating Splitter Window. [CSplitter::CreatStatic]", MB_OK);
AfxAbort();
//Failed To Create Splitter Window
}
SIZE wndSize;
wndSize.cx=300;
wndSize.cy=600;
if ( (!m_wndSplitter.CreateView(0,0, RUNTIME_CLASS(CTestView), wndSize, pContext)) ||
(!m_wndSplitter.CreateView(0,1, RUNTIME_CLASS(CTagDlg), wndSize, pContext)) )
{
AfxMessageBox("Error Creating Splitter Views. [CSplitter::CreateView]", MB_OK);
AfxAbort();
//Check both views
}
return TRUE;
}
The error seems to come from viewform.cpp, in CFormView::Create it call this function:
if (!_AfxCheckDialogTemplate(m_lpszTemplateName, TRUE))
{
ASSERT(FALSE); // invalid dialog template name
PostNcDestroy(); // cleanup if Create fails too soon
return FALSE;
}
And that is what is throwing the exception. Anyone know how I can fix this?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
