|
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?
|
|
|
|
|
I have looked and looked, but I can't find any code to eject a CD-ROM drive in Windows (9x or 2000). I have found a few programs that can do it, but I really need to implement the code inside my project myself. I noticed that the Windows Media Player SDK has some functionality that will do that, but I do not want to be dependent on those libraries to do this. Does anyone have some simple code to do this?
Thanks!
|
|
|
|
|
DeviceIoControl can be used to do this.
Ed
|
|
|
|
|
This was tested on Win2000 and WinNT. mciSendString is available on all 32-bit Windows versions, so you should have no problems on Win9X.
char buf[256];
mciSendString("open f: type cdaudio alias myAlias", buf, sizeof(buf), NULL);
mciSendString("set myAlias door open", buf, sizeof(buf), NULL);
mciSendString("set myAlias door closed", buf, sizeof(buf), NULL);
Tomasz Sowinski -- http://www.shooltz.com.pl
|
|
|
|
|
Works great (though for SOME reason I was getting really weird errors in the Mmsystem.h, had to redefine UINT, then it was missing Winmm.lib). One question: is there a way to do this without waiting? IE: The program sends the message to close the CD then quits immediately. Right now, as is, it waits for the drive to fully close, and read info about the CD before the last mciSendString executes.
|
|
|
|
|
If it's because you want your program to go on with it's business, instead of waiting, just do the open/close stuff in another thread...
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
Sure, I figured that was the easiest way to do it, I was just curious to know if there was a way to do it without waiting without relying on a separate thread. I will be opening and closing the drive several times during execution, but at the end of execution it ejects the CD for the user to remove and then quits. I would like to to eject, request that the user remove the CD, and then close the drive, but not wait for the drive after closing. Using a separate thread would still keep the program alive.
|
|
|
|
|
You have the mciSendCommand function.
With this function you can send command messages to MCI devices.
Carlos Antollini.
|
|
|
|
|
Hi
I have a function in my CView class, it takes a point, and returns the pixel intensity
when I compile it, there's no problem with it,, but there's no output file...
Can anyone help me out????
COLORREF CTestEdgeView::GetPoints( )
{
//this is the class which detects the firt point on the boarder
CClientDC dc(this);
test = dc.GetPixel(m_ptCenter.x +1 , m_ptCenter.y);
ofstream outfile ("ftest.out");
outfile <<"the intensity is: "<< test;
outfile.is_open();
return test;
}
Thanks
Ehsan Behboudi
|
|
|
|
|
Assuming the code works OK, I suspect "ftest.out" is being generated in the default directory (whatever that may be at run time). You might want to retry using a fully qualified filespec like "C:\\ftest.out".
/ravi
"There is always one more bug..."
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Is it possible to build a string with a class name and then create a C++ object of that type using some kind of rtti?
|
|
|
|
|
like this?
CBaseClass *pObj = NULL;
file.ReadString(className);
if (className == ClassA::SerializationName)
pObj = new ClassA;
else if (className == ClassB::SerializationName)
pObj = new ClassB;
-c
------------------------------
Smaller Animals Software, Inc.
http://www.smalleranimals.com
|
|
|
|
|
Make your objects COM objects. This way you can look them up based on the ProgID.
CLSIDFromProgID( L"ClassName", &clsid );
hr = CoCreateInstance( clsid, NULL, CLSCTX_ALL,
__uuidof(IClass), (void **) &pIClass );
This has the benefit of not needing to do some big if statement and adding a new string every time a new class is added.
Mike
|
|
|
|
|
You can pick some ideas from this article by Allen Holub:
http://msdn.microsoft.com/library/periodic/period96/S385.htm
Tomasz Sowinski -- http://www.shooltz.com.pl
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
