|
I ended up that the RichEditCtrl version 2 causes this problem.
Using RichEditCtrl version 1 it works fine.
Any solution ?
I am attaching the source code. Please check that the lTextPrinted is always lesser than lTextLength.
https://rapidshare.com/files/2018160716/RichEditDlg.zip[^]
sdancer75
modified 5-Oct-12 10:20am.
|
|
|
|
|
Here is the code that prints very well:
void CSpscRichEditCtrl::Print(bool bShowPrintDialog, CWnd* pParent )
{
CPrintDialog printDialog(false, PD_ALLPAGES | PD_USEDEVMODECOPIES | PD_NOPAGENUMS
| PD_HIDEPRINTTOFILE | PD_NOSELECTION, pParent);
if (bShowPrintDialog)
{
int r = printDialog.DoModal();
if (r == IDCANCEL)
return; }
else
{
printDialog.GetDefaults();
}
HDC hPrinterDC = printDialog.GetPrinterDC();
FORMATRANGE fr;
int nHorizRes = GetDeviceCaps(hPrinterDC, HORZRES);
int nVertRes = GetDeviceCaps(hPrinterDC, VERTRES);
int nLogPixelsX = GetDeviceCaps(hPrinterDC, LOGPIXELSX);
int nLogPixelsY = GetDeviceCaps(hPrinterDC, LOGPIXELSY);
LONG lTextLength; LONG lTextPrinted;
SetMapMode ( hPrinterDC, MM_TEXT );
FormatRange(NULL,false);
ZeroMemory(&fr, sizeof(fr));
fr.hdc = fr.hdcTarget = hPrinterDC;
fr.rcPage.left = fr.rcPage.top = 0;
fr.rcPage.right = (nHorizRes/nLogPixelsX) * 1440;
fr.rcPage.bottom = (nVertRes/nLogPixelsY) * 1440;
fr.rc.left = fr.rcPage.left ; fr.rc.top = fr.rcPage.top ; fr.rc.right = fr.rcPage.right ; fr.rc.bottom = fr.rcPage.bottom ;
fr.chrg.cpMin = 0;
fr.chrg.cpMax = -1;
DOCINFO di;
ZeroMemory(&di, sizeof(di));
di.cbSize = sizeof(DOCINFO);
di.lpszDocName = _T("eClinic Pharmacy SMS Authorisation Form");
di.lpszOutput = NULL;
StartDoc(hPrinterDC, &di);
lTextLength = GetTextLengthEx(GTL_PRECISE | GTL_NUMCHARS);
do
{
StartPage(hPrinterDC);
lTextPrinted =FormatRange(&fr,true);
DisplayBand(&fr.rc );
EndPage(hPrinterDC);
if (lTextPrinted < lTextLength)
{
fr.chrg.cpMin = lTextPrinted;
fr.chrg.cpMax = -1;
}
}
while (lTextPrinted < lTextLength);
FormatRange(NULL,false);
EndDoc (hPrinterDC);
DeleteDC(hPrinterDC);
}
|
|
|
|
|
Thank you Andrew,
The offending code was the
GetTextLength()
that it should be changed the way you showed me in your example with :
lTextLength = GetTextLengthEx(GTL_PRECISE | GTL_NUMCHARS);
I didn't bothered until now, with the GetTextLengthEx and I had a really hard time with this functionality. Now it works that way it should be.
MSDN reports :
GetTextLengthEx provides additional ways of determining the length of the text. It supports the Rich Edit 2.0 functionality. For more information, see About Rich Edit Controls in the Platform SDK.
My very best regards for your help,
George
sdancer75
|
|
|
|
|
Hi,
I am using H.264 codec to create MP4 file from images. IMFSinkWriter is used for encoding purpose.
While encoding, I need to control the quality of the encoded video by adjusting the average bit rate parameter value. But I could not get any equation for calculating this.
I tried several equations, but the video behavior is different for different type(resolution) of images.
One of the equation used is Frame width * Frame height * frame rate * Image quality parameter * some constant.
But this is not working for all types of resolutions.
My image quality parameter will be varied from 1 to 100.(Low to High)
Could you please provide an equation to calculate the average bit rate for controlling the image quality from Frame width, Frame height and frame rate?
I tried the VBR encoding but it does not work for the encoding using Sink writer.
|
|
|
|
|
I have a buffer which contains BitmapInfo + pixel data. this pixel data is in the palette format. Bitmapinfo structure contains color table. This can be solved by using LockBits method but I don't know how to use LockBits method for converting buffer to buffer. I found a lot of such conversions, but they are mainly processed one input file.
|
|
|
|
|
Here[^] you find how to reach the color table.
Pixel info follow the color table itself.
Veni, vidi, vici.
|
|
|
|
|
Hi have a good day,
Does any body manage to Build application using Dialog Resource for windows 64 bit ?
It Didn't Work for me , I get this error :
error C2664: 'DialogBoxParamW' : cannot convert parameter 4 from 'BOOL (__cdecl *)(HWND,UINT,WPARAM,LPARAM)' to 'DLGPROC'
I try to change
BOOL CALLBACK DialogProc to
INT_PTR CALLBACK DialogProc
But I still get ,
conversion from 'INT_PTR' to 'int', possible loss of data.
I also try to edit , winuser.h , From
typedef INT_PTR (CALLBACK* DLGPROC)(HWND, UINT, WPARAM, LPARAM);
To
typedef BOOL (CALLBACK* DLGPROC)(HWND, UINT, WPARAM, LPARAM);
But the Application Exit with out showing the dialog box ,
BOOL CALLBACK DialogProc(HWND hwndDlg, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
.
.
.
return true;
}
int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd)
{
hInst = hInstance;
return DialogBox(hInstance, MAKEINTRESOURCE(DLG_MAIN), NULL, DialogProc);
}
P.S:
the code work perfectly when building for Win32.
Thank you.
|
|
|
|
|
Smart Arab wrote: I also try to edit , winuser.h , From That is a really bad idea. The windows API libraries have been tested extensively, and if you start changing them then you are likely to create far more problems than you will solve. The include file clearly shows you the format of your DLGPROC function, so it is up to you to create it to match that function definition; it returns an INT_PTR not a BOOL . You can also add a cast in your DialogBox() call to help the compiler along.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Smart Arab wrote: conversion from 'INT_PTR' to 'int', possible loss of data.
You should work on this, I suppose. Which line is giving you this message?
Veni, vidi, vici.
|
|
|
|
|
CPallini wrote: You should work on this, I suppose. Which line is giving you this message?
The WinMain Function return.
int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd)
{
hInst = hInstance;
return DialogBox(hInstance, MAKEINTRESOURCE(DLG_MAIN), NULL, DialogProc);
}
|
|
|
|
|
As I explained above, it is because your DialogProc() does not match the definition required by Windows. Check the documentation[^] and make sure that your declaration matches in every respect.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
You are right. But the conflict is :
DialogProc function Return INT_PTR while the WinMain which return the DialogProc "must return int."
I think I must find a way to convert from IntPtr to int safely ...
Thank you.
|
|
|
|
|
In the special case of WinMain you may use a static cast for the return value without running into any problems:
return static_cast<int>(DialogProc());
Or just assign the return value to a variable and set the value returned by WinMain (usually a non-zero value if the program terminates due to errors):
INT_PTR nRet = DialogProc();
return nRet != ID_OK ? 1 : 0;
|
|
|
|
|
Thank you,I will try all the solutions here.
|
|
|
|
|
Smart Arab wrote: DialogProc function Return INT_PTR while the WinMain which return the DialogProc "must return int." What do you mean, these are two different functions?
Smart Arab wrote: I think I must find a way to convert from IntPtr to int safely .. No, you just need to follow the information provided by the documentation, as I suggested before, and use a cast to satisfy the compiler thus:
return DialogBox(hInstance, MAKEINTRESOURCE(DLG_MAIN), NULL, (DLGPROC)DialogProc);
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Thank you,I will try all the solutions here.
|
|
|
|
|
That is not a big deal.
As already suggested, you don't need to return directly the DialogBox call result, quite the opposite, is better break it into a two stage approach:
- Assign the
DialogBox return value to an (INT_PTR ) variable (say result ). - Based on
result value, return an appropriate (int ) number from the WinMain function.
This is convenient, since DialogBox and WinMain use different conventions for they return values (see DialogBox[^] and WinMain[^] at MSDN).
Veni, vidi, vici.
|
|
|
|
|
Thank you,I will try all the solutions here.
|
|
|
|
|
You are welcome.
Veni, vidi, vici.
|
|
|
|
|
Hi,
I have a slider control on a dialog box in mfc. When user clicks on the slider bar, the thumb moves by the ticks. I want to place the slider thumb directly at the place where user clicked the mouse on the slider bar.
Any sample code for the above scenario.?
Anybody have any idea.?
Regards,
Mbatra
|
|
|
|
|
Hi!
I've to select a number radomly from 1 t0 6. What is the C++ code for this?
|
|
|
|
|
pix_programmer wrote: I've to select a number radomly from 1 t0 6. What is the C++ code for this?
int number;
srand ( time(NULL) );
number = rand() % 6 + 1;
------------------------------
Author of Primary ROleplaying SysTem
How do I take my coffee? Black as midnight on a moonless night.
War doesn't determine who's right. War determines who's left.
|
|
|
|
|
Since (from rand() as cplusplus.com[^]):
Notice though that this modulo operation does not generate a truly uniformly distributed random number in the span (since in most cases lower numbers are slightly more likely), but it is generally a good approximation for short spans.
An alternative is:
int n = 1 + 6.0 * rand() / (RAND_MAX + 1.0);
Veni, vidi, vici.
|
|
|
|
|
CPallini wrote: Notice though that this modulo operation does not generate a truly uniformly distributed random number in the span (since in most cases lower numbers are slightly more likely), but it is generally a good approximation for short spans.
That's wrong.
I startet a small programm generating one billion random number for each of the two solutions repeatly.
The are no difference and the reason is obvious.
Of course smaller numbers are more likely, but it doesn't matter how big a number is when you use modulo as it depends on divisibility. And there is no difference for small or large numbers.
------------------------------
Author of Primary ROleplaying SysTem
How do I take my coffee? Black as midnight on a moonless night.
War doesn't determine who's right. War determines who's left.
|
|
|
|
|
It depends on the goodness of the pseudo random generator , of course (hint: it is not the reminder function that is 'broken').
The test depends also on the periodicity of the random generator.
How did you perform the test?
Veni, vidi, vici.
|
|
|
|