|
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?
|
|
|
|
|
no, no interrupts, it's a simple scheduler using while(1).
and one cycle is 10 ms , one cycle is 5 ms.
task A in 10 ms cycle, task B in 5 ms cycle.
|
|
|
|
|
But have you threads? Microcontrollers usually have not.
|
|
|
|
|
You called this thread but you describe these as tasks and I read your other responses ... so I am assuming this is a task switcher.
So I am guessing you are on a pre-emtive task switcher that is running multiple tasks.
If that is the case usually you synchronize by stopping the task switcher for switching for a short period as you have a critical section.
For example of a context switcher running off a timer interrupt, you just disable the interrupts which will stop the context switcher from switching your task out. On all context switchers there is a way to do this because at various points in the kernel they have to enter critical sections. You need to keep your time inside these sections as fast as you possibly can.
Now if it is going to take to long you need to use locks. They start simple and grow in complexity as you want different things.
Even on a basic task switcher it should have a semaphore because they are so easy to define or you can make one just using a volatile int.
typepdef volatile int semaphore;
The volatile is important because you are going to end up looping around reading the same address. You need to make sure the compiler doesn't optimize that to only reading it once and using the old value for each of the check loops. It must read the memory location each and every time.
To enter a semaphore locked area generally you will make a call to something called a name like semaphore_inc or semaphore_pend.
What that will do is make sure you have single aquire on the semaphore, if you don't it will sleep your task it will basically be doing this
void semaphore_inc (semaphore* sem)
{
disable context switcher;
while (*sem != 0)
{
enable context switcher;
sleep(1);
disable context switcher;
}
*sem++;
enable context switcher;
}
The disable and enable context switcher will be simple disable and enable interrupt opcodes on a simple timer interrupt system up to a small piece of code on more advanced switchers. What is important is do you get what happens with your task getting sleeped unless it has solo access to the semaphore. The 1 will be the minimum unit of time on the task switcher until your task can be woken up. It's non blocking because the sleep call will activate the next task to run (because you can't and so you give up your timeslice) and it will come back to you sometime later on another context switch. The moment you set the semaphore any other task trying to enter would have the same happen to it because they would ask for the aquire in the same way. You can see it is important the context switcher get turned off while various parts of the test are done, you don't want to be pre-emptively switched out while you are testing.
Now once you have finished you call something like semaphore_dec, or semaphore_release which will set the semaphore back to zero again turning off the context switcher where it needs. Once you exit other tasks may enter or they will wake from a sleep and find they can go in if they were trying to aquire lock. If you have to write the code for the release it is a really simple code
void semaphore_dec (semaphore* sem)
{
disable context switcher;
*sem--;
enable context switcher;
}
So it ends up like this taskACall and taskBCall can never run at same time but they are non blocking. A task waiting to aquire the lock gives up it's timeslice to other tasks which will include the task currently in the locked area. Eventually the task in the locked area will come out and the waiting task will be able to enter but will lock the original task from re-entering until it leaves.
semaphore sem = 0;
void taskACall (void)
{
semaphore_inc(&sem);
.... // do task A code
semaphore_dec(&sem);
}
void taskBCall (void)
{
semaphore_inc(&sem);
.... // do task B code
semaphore_dec(&sem);
}
Now some CPU's and some systems have semaphores inbuilt into the MMU and C11 added atomics as a standard #include <stdatomic.h>.
So on different systems if you have to add the behaviour yourself there is a standard way to do it.
Without knowing more specifics that is about all I can tell you.
In vino veritas
modified 11-Sep-18 5:03am.
|
|
|
|
|
Thank you very much for the answer.
But the C program is in an embedded device, it's not a pre-emptive task environment, just a forever loop cycle, in which, some functions be called in 10 ms cycle, some functions be called in 5 ms cycle.
each cycle I called it a task.
The structure like a simple scheduler using while(1) loop.
Task A (or Cycle A) is a 10 ms cycle, and Task B is a 5 ms cycle, just use a counter to implemented the 10 ms , 5 ms cycle, like
while(1)
{
count ++;
if (count == 5)
{
task B be called
}
if (count == 10)
{
count = 0;
task A be called.
}
}
Thanks
|
|
|
|
|
So the semaphore code is exactly the same except you can ignore all the switcher enable and disable all you do is if the semaphore is locked you immediately switch to the other code (which is your version of sleep) because you can't do anything on that task.
So basically if taskA has the semaphore, then whenever you call taskB code and you want to enter the semaphore lock area you just exit and call taskA because taskB can't run until taskA gets it's fat butt out of the lock area. So in your case you would actually get a slight processing boost on taskA because it would get called twice (minus the exit and switch time) for each count loop.
The same applies if taskB has the semaphore and taskA went to enter the semaphore lock area then it would simply exit and call taskA.
It's pretty straight forward the task that is waiting on the lock is dead in the water and you just need it to give all the processing power to the other task to get it out of the lock area.
As your setup is so simple you could also just setup a state machine to mirror a semaphore, you have 5 states
1.) Neither A,B in lock area, 2.) A in lock area B out, 3.) A in B waiting, 4,) B in A out, 5.) B in A waiting
The states are changed as A & B enter and leave the lock area ...see functions in code after the modified work loop
enum lock_state {ABoutofLockArea = 0, AinLockAreaBnormal, AinLockAreaBwaiting, BinLockAreaAnormal, BinLockAreaAwaiting};
enum lock_state state = 0;
/* MODIFIED WORK LOOP */
while (1){
if (count == 5)
{
if (state == AinLockAreaBwaiting) TaskA is called // no point calling taskB its waiting
else task B be called
}
if (count == 10)
{
count = 0;
if (state == BinLockAreaAwaiting) TaskB is called // no point calling taskA its waiting
else task A be called.
}
}
/* HERE ARE YOUR STATE CHANGE FUNCTIONS */
void taskA_EnterlockArea(void)
{
if (state == BinLockAreaAnormal) state = BinLockAreaAwaiting; // B already in there A must wait
else state = AinLockAreaBnormal // B is not there so A can enter
}
void taskA_LeavinglockArea(void)
{
if (state == AinLockAreaBwaiting) state = BinLockAreaAnormal; // B is waiting it can now enter, A goes back to normal
else state = ABoutofLockArea; // Otherwise no one is in the lock area
}
void taskB_EnterlockArea(void)
{
if (state == AinLockAreaBnormal) state = AinLockAreaBwaiting; // A already in there B must wait
else state = BinLockAreaAnormal // A is not there so B can enter
}
void taskB_LeavinglockArea(void)
{
if (state == BinLockAreaAwaiting) state = AinLockAreaBnormal; // A is waiting it can now enter, B will go back to normal
else state = ABoutofLockArea; // Otherwise no one is in the lock area
}
The advantage the semaphore has over the state machine, is you can add more and more semaphores with no complexity increase. As you try to lock more areas through a state machine it quickly becomes overly complex.
In vino veritas
modified 11-Sep-18 19:51pm.
|
|
|
|
|
In this case you don't need synchronization at all.
|
|
|
|
|
Thanks,
First I think I don't need a synchronization.
But when I code like:
if (rcvd == true)
{
read rcv_buffer
...
rcvd = false;
}
dataCB(int ch_id, char *buf, int len, char stat)
{
rcvd = true;
if((rcvd == false)
{
receivenotify(chid, rcv_buffer, sizeof(rcv_buffer), dataCB,0);
}
}
The program behavior is not correct
|
|
|
|
|
It isn't at all surprising it misbehaves you have >>>> SHARED DATA <<<<
You guys seem to think having a co-operative task switcher somehow makes you
immune to shared data issues ... well your wrong as you found out
lets give you the situation .. it may not be your case but follow what happens
task b picks up the count of the recieve buffer .. then yields to task a
task a changes the count value of the recieve buffer then yields back to task b
task b now wrongly writes the old count value back and your program now crashes
So the variable "count" is being accessed by both tasks it is shared, it is that simple
The same will be true of other variables you are accessing with both taskA and taskB
and if you drag all the stuff accessed by both tasks to an area they are called the
shared data and they are the problem.
Now what creates the problem above is yielding between the two tasks, while one task
is using the shared data.
Now on the code above it looks like taskB probably never yields while it is inside dataCB.
That is because it's a function and I doubt you can organize the yield.
However on your taskA code above which looks like it in a flat loop you also can not yield
to taskB anywhere in it not even in the "..." section. It must start and finish that entire
code without ever yielding to taskB or your code will crash. The hint to why it would crash
is the variable rcvd which is probably a bool and it's written to by both tasks a big no no
or danger Will Robinson, as per the example I gave at top.
If you understoof the issue you can refactor taskA code to make the problem less likely but
curing it if you want to yield in "..." needs definitive steps.
anyhow I will leave you with it.
In vino veritas
modified 13-Sep-18 1:03am.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
