|
A quick glance brings up a problem here:
Stack::Stack() {
auto *local_stack= m_memPool.Allocate();
}
Perhaps I misunderstand the intention, but shouldn't this be:
Stack::Stack()
: local_stack(m_memPool.Allocate())
{}
|
|
|
|
|
Good catch; I missed that completely.
|
|
|
|
|
|
Can anybody help me? I want to launch a word processor(MS Word) in an MS Visual C++ dialog based application. How this can be done exactly. Thanks in advance for your help.
|
|
|
|
|
Would you like to embed MS Word into your dialog or just spawn the MS Word application from your dialog?
|
|
|
|
|
open MS Word from the dialog
|
|
|
|
|
Then use ShellExecute(Ex).
|
|
|
|
|
|
Don't have much idea about it...
|
|
|
|
|
Have you considered ShellExecute() ?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Trying now...
Thanks for your help
|
|
|
|
|
I want to print a bitmap. To avoid printing small bitmap I set CScrollView mode as MM_LOMETRIC with sizes 3830x1995. I have created the bitmap and made the bitblt to the screen. There were everythig just like I want on the screen and on the print preview but when I printed the document I`ve got very bad result.
It seems to me that printer does not see a bitmap the same way as print preview does. Pay attantion that the first ractangle puts directly on the DC and memDC puts into it. Are there any ideas how to fix this mismatch between print previw and the real printing?
MFC_T_Print_1.zip[^]
void OnDraw()
{
CPen pen;
pen.CreatePen(PS_SOLID, 1, RGB(0, 0, 0));
CPen* OldPen = pDC->SelectObject(&pen);
CRect rcView;
GetClientRect(rcView);
int iClientWidth = rcView.right;
int iClientHeight = rcView.bottom;
int iMemWidth = 1900;
int iMemHeight = 950;
CDC memDC;
CBitmap memBitmap;
memDC.CreateCompatibleDC(pDC);
memBitmap.CreateCompatibleBitmap(pDC, iMemWidth, iMemHeight);
memDC.SelectObject(&memBitmap);
memDC.SetMapMode(MM_LOMETRIC);
CPen pen1;
pen1.CreatePen(PS_SOLID, 3, RGB(0, 0, 0));
memDC.SelectObject(&pen1);
CBrush brBK;
brBK.CreateSolidBrush(RGB(255, 255, 255));
memDC.SelectObject(&brBK);
RECT rc;
rc.left = 0;
rc.top = 0;
rc.right = iMemWidth;
rc.bottom = iMemHeight;
memDC.FillRect(&rc, &brBK);
memDC.Rectangle(rc.left, rc.top, rc.right, -rc.bottom);
memDC.MoveTo(0, 0);
memDC.LineTo(1900, -950);
memDC.MoveTo(0, -950);
memDC.LineTo(200, -750);
CFont font;
font.CreateFont(
50,
0,
0,
0,
FW_NORMAL,
FALSE,
FALSE,
0,
ANSI_CHARSET,
OUT_DEFAULT_PRECIS,
CLIP_DEFAULT_PRECIS,
DEFAULT_QUALITY,
DEFAULT_PITCH | FF_SWISS,
_T("Arial"));
memDC.SelectObject(&font);
memDC.TextOut(100, -100, _T("Hello"));
pDC->BitBlt(10, -10, iMemWidth, -iMemHeight, &memDC, 0, 0, SRCCOPY);
font.DeleteObject();
brBK.DeleteObject();
memDC.DeleteDC();
memBitmap.DeleteObject();
pen.DeleteObject();
pen1.DeleteObject();
}
void OnInitialUpdate()
{
CScrollView::OnInitialUpdate();
CSize sizeTotal;
sizeTotal.cx = 3830;
sizeTotal.cy = 1995;
SetScrollSizes(MM_LOMETRIC, sizeTotal);
}
MFC
|
|
|
|
|
You need to set the mapping mode in the actual device context where you are writing the data. In this case you need to set it into the PrinterDC to make it consistent with the screen settings, and the actual image. See Mapping Modes and Translations | Microsoft Docs[^].
|
|
|
|
|
Mapping mode (MM_LOMETRICETRIC) has been set both in OnPrepareDC() and in OnPrint(). The result is the same - we still have mismatch between print preview and the real printing.
|
|
|
|
|
The screen works on 96DPI unless you are in a DPI aware app which if you want to confirm
HDC screen = GetDC(0);
long hPixelsPerInch = GetDeviceCaps(screen,LOGPIXELSX);
long vPixelsPerInch = GetDeviceCaps(screen,LOGPIXELSY);
So it's setup that 96 pixels = 1 inch, not in the real world but that is what 96 pixel represents on screen
When you map it to 0.1mm per device space 25.4mm = 1 inch so 254 pixels now = 1 inch
Now the same works for the resolution of your printer depending on it's resolution
So lets say you are printing at 150dpi on the printer so when you set it to 0.1mm per device unit
1500 pixels = 1 inch on the printer
Normallly the printer select dialog goes close because it knows the screen is 96DPI and it knows what the
printer DPI is but you have messed about with the modes and thrown it out by a fair bit.
It's usually pretty close all by itself
Anyhow the scaling is easy .... correct size = size * effective Printer DPI / effective Screen DPI;
When you select the printer you can get it's DC and pass it into the code above and get it's hPixelsPerInch
and vPixelsPerInch just as you did the screen. Hence you can work out the scale.
In vino veritas
modified 12-Sep-18 13:16pm.
|
|
|
|
|
Thak you for the answer but there is a problem with the bitmap that is inscribed in the ractangle.
If you look at the print preview - you will see this bitmap well. But if you print the real page you will see that ractangle is printed perfectly but the bitmap (inscribed into ractangle) was cut from the right side and the bottom.
If there was a problem with dpi we would have problems both with the ractangle and with the bitmap.
Print preview: Preview[^]
Real print: Printed page[^]
|
|
|
|
|
And there is nothing surprising about that you only made your DC a fixed size based on screen,
Rough guess your printer is running at 300 DPI, confirm what resolution you have on printer?
let me jog your memory with your memory bitmap/DC (which matches the screen)
===> memBitmap.CreateCompatibleBitmap(pDC, iMemWidth, iMemHeight);
then you only transfer that screen size
====> pDC->BitBlt(10, -10, iMemWidth, -iMemHeight, &memDC, 0, 0, SRCCOPY);
Those sizes are in screen pixels the printer DC is different to iMemWidth, iMemHeight pixels,
It is hardly surprising you only get the top left corner, it is telling you the same thing
Remember the sizes on the transfer are in the DC pixels of the DC you use for the function.
You have pDC vs memDC and those are not the same DPI.
You would either need to StretchBlt or get the printer DC and work out the size to make the memory
bitmap that size because it has a different DPI.
If you can set the printer to 100 DPI which is as close to 96 DPI you will get close to what you want .
In vino veritas
modified 13-Sep-18 7:21am.
|
|
|
|
|
Nice idea but
I tried to make different Width and Height for display and printer. It broke Print Preview[^].
But when I`ve printed document the result was the same[^] .
int iMemWidth = 1900;
int iMemHeight = 950;
...
if (pDC->GetDeviceCaps(TECHNOLOGY) == DT_RASDISPLAY)
{
pDC->BitBlt(10, -10, iMemWidth, -iMemHeight, &memDC, 0, 0, SRCCOPY);
}
else if (pDC->GetDeviceCaps(TECHNOLOGY) == DT_RASPRINTER)
{
pDC->BitBlt(10, -10, 3830, -1950, &memDC, 0, 0, SRCCOPY);
}
Here is the source code:
MFC_T_Print_LOMETRIC.zip[^]
|
|
|
|
|
You aren't getting that memory DC's are basically free you aren't limited to just one and why they exist
Lets see if I can make you understand.
This stuff is only important for bitmaps you can print text all day and never need to know this stuff
1.) When you print bitmaps you make a new memory DC to match the printer not the screen!!!!
HDC SecondDC = CreateCompatibleDC( >>> PrinterDC <<<);
2.) Put your image on the memory DC and you use it to print .. just like you did the screen DC
3.) Now print it.
4.) Now you destroy the memory DC that matches the printer you are done with it.
At no point in that did I change or alter your screen bitmap/DC
What you aren't grasping is why you need a memory DC .. so lets deal with that because it is important.
So a true device DC may have a different planes and colour layout to your image and if that was done
at a driver level, every driver would have to know how to deal with every colour format. So they don't
do that the driver generally knows exactly one colour format usually RGB. The memory context is the
thing that knows all the different formats and is essentially device independent. So when you want to
print what a bitmap what you want is a memory context that matches the PRINTER DC not the screen.
That is all covered here .. I want you to carefully read the paragraph that starts with
"The original bitmap in a memory DC is simply a placeholder"
Memory Device Contexts | Microsoft Docs[^]
Now here is a tutorial on bitmap printing I want you to go to Part 9
https://www.dreamincode.net/forums/topic/261009-bitmap-printing-tutorial-in-c-win32/
I want you to take particular note of lines 9 to 13 which does this
prn = GetPrinterDC(hwnd);
cxpage = GetDeviceCaps (prn, HORZRES);
cypage = GetDeviceCaps (prn, VERTRES);
hdcMem = CreateCompatibleDC(prn);
HBITMAP hbmOld = (HBITMAP)SelectObject(hdcMem, hBitmap);
If you understood the above you will understand what they are doing but lets walk thru it
1.) They got the printer DC because that is our device NOT the screen
2.) They got the width and height of the printer from that DC.
3.) They made a memory DC to the printer DC to transfer the image onto (printer DC not screen DC)
4.) They selected the bitmap you want to print to the memory context so it initializes how
to convert the bitmap for the printer.
Then they will transfer all the image and stuff onto the memory DC, then they will copy it to
the printer and then they will throw the memory context away it isn't needed anymore.
The important part here is the memory context that matches the printer is the right scale
and it has the right colour plane organization and it has nothing to do with your display
memory context which is dangling around elsewhere in your code.
In vino veritas
modified 13-Sep-18 11:47am.
|
|
|
|
|
Hi, I met a thread synchronization scenario in a small code.
if (rcvd == true)
{
read rcv_buffer
...
rcvd = false;
}
dataCB(int ch_id, char *buf, int len, char stat)
{
rcvd = true;
receivenotify(chid, rcv_buffer, sizeof(rcv_buffer), dataCB,0);
}
here, rcvd = false in task A, can't stop task B produce data. how can I let task A, B synchronized.
add if (rcvd == false) in task B before receivenotify()? is that a dead lock ?
Thanks
|
|
|
|
|
That's not how to synchronize threads.
You should be using Events. See Using Event Objects | Microsoft Docs[^]
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
It's a rare C program, no Events
|
|
|
|
|
What is a "rare C program?"
Is this on Windows?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
No, its on a 32 bit micro controller, no OS.
|
|
|
|
|
Then you haven't threads, have you?
Are you talking about interrupts?
|
|
|
|
|