|
I use GDI+ Graphic::DrawImage to display and print a bitmap;
for display and print preview it works fine. But when printing, the bitmap is stretched or compressed on paper, depending of the printer resolution. To correct this problem, I applied a correcting factor :
long dpiPrinter = pDC->GetDeviceCaps(LOGPIXELSX);
long dpiScreen = 96; // returned by pDC->GetDeviceCaps(LOGPIXELSX)
// when displaying
double ratio = (double)dpiPrinter/dpiScreen;
destPoints[0].X /= ratio;
destPoints[0].Y /= ratio;
...
// destPoints[0...2] are the corners of the rectangle
// delimiting the zone on which the bitmap is to be printed
graphics.DrawImage(pData->pBitmap, destPoints, 3,
0, 0, bitmap.GetWidth(), bitmap.GetHeight(),
UnitPixel);
Bitmap size is now almost correct but still a bit too large.
And I don't see any reason why I have to modify the code for
printing : MFC show the correct image in print preview, so I
assumed I would get the same result on paper.
|
|
|
|
|
You have to modify the code for the reason you said - MFC showed you how it looks on the screen, but it's up to you to match that in terms of the DPI of your printer.
Have you tried using UnitInch to draw to the printer ? Just curious, I've not tried printing in GDI+ myself but it seems like it could be promising.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm thinking of getting married for companionship and so I have someone to cook and clean." - Martin Marvinski, 6/3/2002
|
|
|
|
|
After many trials it works, and here are my conclusions, or rather my observations, because I don't have a clear understanding of what's happening.
I use the MM_LOMETRIC mapmode : logical units are 0.1 mm. The coordinates of the rectangle on which the bitmap is to be drawed are initially exprimed in these logical units. When I discovered that the size and position of the bitmap on paper were depending of the resolution of the printer, I thought of applying a correcting factor :
factor = dpiPrinter/dpiScreen
X1 /= factor
...
I get these dpi with pDC->GetDeviceCaps(LOGPIXELSX); for the printer it can be
75 ... 1200 dpi, and for screen it is 96.
On paper there was still a error of about 4 %; for example when I printed a bitmap whose
width was expected to be 50 mm, I got 48 mm on paper.
I have tested many hypotheses, including playing with Graphics.SetPageUnit(), Graphics.SetPageScale(), ... And finally an intuition, nothing rational but after all I was ready for black magic : an error of 4 %, OK let's say my dpiScreen is 100 and not 96... size and position are now perfect, for any printer resolution.
I assume that the LOMETRIC mapmode is in cause; as the logical units are not pixels, the screen resolution returned by GetDeviceCaps() is not relevant anymore; but then how do work the factor dpiPrinter/100 ? I have not tested yet with another mapmode, for example HIMETRIC (.01 mm). I guess (?) that my 100 would have to be replaced by 1000.
I can survive without understand that, but if someone has explanation...
|
|
|
|
|
hi guys(and gals),
I have this 2 port nic installed. Bridging the 2 nic ports I have a crossover cable. What i'm looking to do is be able to send data out on one port and have it read in by the other. However on this basic app I wrote it will connect(bind is a better term) to each static ip on the nic; one to send, the other to receive. I chose to use port 3344(no specific reason). Once I connect i send a simple 2 mb file. The transfer works just fine. The problem I encounter is that the transfer is not going thru the crossover cable but somehow routed internally; telling me the os(nt4 server) knows the ip's are internal and not to send the data out across the crossover cable. What i'm looking to do is force the data out across the crossover cable.
if it helps these are the ip's assigned:
192.168.0.1
192.168.0.2
thanks
|
|
|
|
|
I don't think its the O/S that is doing it to you. More likely its the nic card itself (or maybe its driver). You can test this by installing a second nic.
|
|
|
|
|
Thanks for the tip. I just installed a second nic and still get the same results. file transfer between the 2 ports still goes smooth even without the crossover attached
Eric
|
|
|
|
|
Wow, that is surprising. Fraid that's all I had to offer.
Good Luck
|
|
|
|
|
Thank you for your help nonetheless.
|
|
|
|
|
I know there exists a function in C++ which you pass a filename. The function then uses the program defined in Windows for that type of file to open the file.
I don't know if this is the right place to ask, but I try anyway. So if you understand the above and know which function I mean or where to find it, please mail me. Thanks a lot.
|
|
|
|
|
|
Have you made some experience with Active Directory ?
If you do so, then please let me know because i have some problems with ADSI!
|
|
|
|
|
Hi,
My dialog app contains several buttons which are enabled and disabled at various times.
I am trying to add tool tips for these buttons.
The tooltips appear when the buttons are enabled, but disabled buttons do not show the tool tips
When I create the tooltip control I use
myTooltip->Create(this,TTS_ALWAYSTIP);
Any ideas?
Thanks in advance,
Pete
|
|
|
|
|
TTS_ALWAYSTIP does something different - it will display tooltip when your dialog isn't active. Disabled buttons are probably ignored by design.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Thanks Tomasz - the TTS_ALWAYSTIP was a red herring. I will have to rethink my tooltip strategy now!
Pete.
|
|
|
|
|
some how my project has gotten crazy , every time i complie it says that certain files need to be rebuild even if i have made no changes in the code , it is driving me carzy please help
|
|
|
|
|
Delete the ncb,opt & plg files & rebuild , mybe this will help ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
|
|
|
|
|
MailMonty wrote:
it says that certain files need to be rebuild even if i have made no changes in the code
Check the date of modification of these files. Build system uses date/time stamp to determine what has changed.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
i used crystal reports ver 6.0
i used an OCX control of Crystal reports to display various reports but when i make a SETUP through InstallSheild it says that the DLL for the OCX was added but
when i run the setup the OCX cannot be registered i added all the dll's from crstal but still it does not register
please HELP ???
thanks in advance
|
|
|
|
|
Use the DEPENDS.exe program that ships with visual studio to get a complete list of the dlls used by the OCX.
|
|
|
|
|
i did and added all those files too but it still won't register
what if these fiels are yet to be copied and the setup tries to register the control or the setup copies all the files and then tries to register
??
|
|
|
|
|
What is the error code returned by regsvr32?
Isuppose its possible to get InstallShield to screw up the installation order, but its probably not easy. Are there any dlls that cannot be copied until the system reboots? Does InstallSheield automatically reboot your system? If not, does it need to? If you manually restart the system, can you register the control?
|
|
|
|
|
how do i copy contents of one DC to another
i tried BitBLit but it does't work
here is the sample code
OnDraw(CDC *pDC)
{
CDC memDC;
memDC.CreateCompatibleDC(pDC);
DrawStuff(&memDC); //Draw in mem dc
pDC->bitblit(0,0,width,height,&memDC,0,0,SRCCOPY);
}
but nothing happens if i don't use memDC then Drawing is done
please help
|
|
|
|
|
You need a bitmap associated with memory DC. Search CodeProject for CMemDC class - it'll do the boring stuff for you.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
I have a weird little problem, and I think it's associated with DirectShow.
I have an app that creates a CView-based window, and passes the hwnd to a DLL. The hwnd allows me to "attach" (don't know a better word at the moment) a live video preview to the window that was created in the app.
When I move the child window/view around in the app's window, everything is fine - the window always repaints itself. However, if I move the window so that a portion of the client rect is clipped by the app window, when I move the child completely back onto the app window, the portion that *was* clipped does not repaint itself.
I tried various API calls (MoveWindow, SetWindowPos, UpdateWindow, InvalidateRect, and RedrawWindow), but to no avail.
Thinking the problem might be one of timing (a message was getting lost/ignored somehow), I put Sleep(1000); in the code just before my rectangle update. This caused the window to repaint itself correctly at first, but then after the one-second delay, *my* repaint occurred, and the portion that was previously out of view repainted as black.
As an afterthought, I decided to just comment out the contents of my dll window repainting function, and exactly the same thing happens, so I know it's not my code that's causing this.
Does anyone have any words of wisdom?
PS. Both the app and the DLL use MFC, and I cannot add additional parameters that can be passed to the DLL from the app (architectural restriction, not mine).
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
