|
What happens if you change two lines of your code to this:
dcMem.CreateCompatibleDC(GetDC())
bmpMem.CreateCompatibleBitmap(GetDC(), rect.Width(), rect.Height()))
|
|
|
|
|
But GetDC() returns a HWND parameter where as CreateCompabileDC expect CDC* value
|
|
|
|
|
 Are you sure? GetDC()//it returns CDC*
|
|
|
|
|
No GetDC returns HDC whereas createcompatable takes CDC pointer
|
|
|
|
|
No its not ture.
CDC dc*;
dc=GetDC();
HDC hdc;
hdc=::GetDC(HWND);
|
|
|
|
|
I made small modifications to your code and passed my window hwnd but the result is same. one of the parameter is incorrect
|
|
|
|
|
Can you tell me what do you want to do?
|
|
|
|
|
I know this is not the forum. I am printing activex controls. I was not able to print them. Last week i posted the problem in com forum. I found the solution. we have 4 legacy activex controls. out of them i am able to print two of them. One is raising one of the parameter is incorrect and another is printing with black background image. This is my problem.
|
|
|
|
|
Is it possible for you to print your bitmaps without any activex controls?
|
|
|
|
|
i found in the msdn GetDIBits returns zero if the header information is incorrect
BITMAPINFO *bmi = (BITMAPINFO *) _alloca(sizeof(BITMAPINFOHEADER) + 256 * sizeof(RGBQUAD));
memset(&bmi->bmiHeader, 0, sizeof(BITMAPINFOHEADER));
bmi->bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
int scanLineCount = GetDIBits(dcMem, bmpMem, 0, rect.Height(), NULL, bmi, DIB_RGB_COLORS);
the value of bmi->bmiHeader.biSize is 40 while debugging.
what i have to do to pass the correct header information
|
|
|
|
|
|
Thanks for the article. But that didn't help. My code is working well for two activex controls but for another it is returning invalid argument(GetDIBits). I am assuming that i have to do something in the activex control. What i have to do in that. That i don't know. If any one knows please help me.
|
|
|
|
|
Hi,
I have vector<string>
and I want to have char**.
Is there any elegant way?
|
|
|
|
|
a vector of what is it ?
and why do you want to regress back to char** ?
|
|
|
|
|
Oh, Sorry for incomplete information.
I have a vector of strings
e.q. vector<<string>>
|
|
|
|
|
you didn't replied the second part of my question :
"and why do you want to regress back to char** ?"
BTW, you could do something like this, but I seriously doubt about the need of this:
std::vector<std::string> v;
size_t n = v.size();
char** str_arr = ::new char*[n];
int i = 0;
for (vector<string>::iterator it = v.begin(); it != v.end(); it++, i++) {
str_arr[i] = ::new char[(it->length())+1];
::strcpy(str_arr[i], it->c_str());
}
of course, don't forget to free all that memory allocated, otherwise, you're leading into memory leaks...
modified on Thursday, May 22, 2008 9:30 AM
|
|
|
|
|
I am using a legacy API which needs char** as [in] parameter.
Thanks for suggesting this solution.
I guess there is one typo
<br />
char** str_arr = new char*[n];<br />
Is there any other quick soln exists?
|
|
|
|
|
vikrams wrote: I guess there is one typo
you're totally right, I fixed it in my previous post.
vikrams wrote: Is there any other quick soln exists?
I sorted this one from the top of my head, but i doubt you'll find better/shorter solutions for this.
BTW, check that you're API needs or not a trailing nul ('\0') character at the end of the char* array (the one called str_arr). if so, you'll have to change my code. if not, it's probably expecting an integer with the array size; that's what n is storing.
|
|
|
|
|
Thanks for quick response. I have working implementation of this type. But I was curious if any other soln exists.
|
|
|
|
|
Well, if the legaci API uses strings strictly as IN parameters then you have to option to drop the string copy operations.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
CPallini wrote: Well, if the legaci API uses strings strictly as IN parameters then you have to option to drop the string copy operations.
hu, what ???
|
|
|
|
|
exactly.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
man, I wasn't joking.
I really asking what you said, because I don't understand what you mean !
|
|
|
|
|
Well, it was not a difficult concept: if the legacy code function access just read-only the passed string, there's no need to copy memory buffers. Often happens that legacy code declares a function such
void printlog( char * buf);
where instead wuold be more appropriate
void printlog (const char * buffer);
When dealing with such code, you can safely cast the const char * pointer to a char * one.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
ah, yes.
but as the API needs an array of strings, we have to copy the std::string objects into the char** memory allocated anyway to be able to pass it forward...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
