|
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
|
|
|
|
|
Hi, I'm searchig for a routine for Authenticating users that dial to a NT4/2000 server, using RADIUS protocol, because users passe through a router that server is connected to it.
Please help me.
Regards,
HAMED.
|
|
|
|
|
Hello!
The fact: I created a program with mfc the access an .mdb database through a Regular MFC DLL
statically linked (i must do that). I add th DLL to my core program, i execute all the function,
like insertion of record, etc through the dialogs in DLL and the db in the DLL.
When i close the app i always get an error cause "the memory could not be read". All works fine
but this message box.
This, only when i use CDaoRecordset (that i must use instead of CRecordset), cause when i call a
function that show ie a message box, the memory error dont appear.. sigh
Anyone has an idea on how to kill this problem?
|
|
|
|
|
Have you tried rebuilding the entire project? ( i.e. Clean / Rebuild all )
If putting a MessageBox in will make the problem go away, then it is quite likely that the program's stack is corrupted. You also need to make sure that the .lib file you are statically linking with is up to date. i.e. build the dll first, then use the up to date .lib file to build the executable. The joys of statically linking.
"Harland Pepper, would you stop naming nuts" - Harland Pepper
|
|
|
|
|