|
Hello Everybody,
abc.emf file has some lines and text inside it stored in vector form.
Have tried various way of drawing this emf file on Bitmap as follows:
Metafile metafile("abc.emf");
height = metafile.GetHeight();
width = metafile.GetWidth();
Rect rcdst(0, 0, width, height);
Bitmap bmp(width, height, PixelFormat32bppARGB)
Graphics gr(&bmp);
[1]
gr.DrawImage(&metafile, rcdst, 0, 0, width, height, UnitPixel);
[2]
gr.EnumerateMetafile(&metafile, Point(0, 0), metaCallback, &metafile);
metaCallback was defined appropriately and inside that used Metafile::PlayRecord() for drawing.
Now, when i save this bmp in uncompressed format like tif then the quality of text is
not coming properly.
When i display the same emf file on CDC then the quality of text is proper, means antialised.
Please suggest how the quality of emf can be maintained while drawing it on bitmap.
Also, highlight any other method through which this can be done.
Thanks.
|
|
|
|
|
My applications uses many dll libs.
I suspecting these dlls may has the memory leaks.
All dll uses "#define new DEBUG_NEW" for memory allocation.
when my application ends, the dll's teriminated before reporting memory leaks.
because of that i can't find the leaks of dll(I think).
ListBoxs.DLL Terminating!
EVENTS.DLL Terminating!
Detected memory leaks!
Dumping objects ->
{174217} normal block at 0x04545900, 1024 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{174216} normal block at 0x044E8A20, 36 bytes long.
Data: <HG YT YT > 48 47 97 01 A2 CD CD CD 00 59 54 04 00 59 54 04
{174215} normal block at 0x045454B8, 1024 bytes long.
I need to get the memory leak info of ListBoxs.DLL & EVENTS.DLL
how to get those dll leak details?
|
|
|
|
|
If your are OK in your LIBs and their clients code,
you could control (for example by tracing) the symmetry
of new/delete and constructor/destructor calls...
...or use a tool (for example Bounce Checker)
At the Debugging print all addresses of used modules (Break->Debug->Views->Modules)
to compare the ending output with them
and know the module(s) of the leak(s).
virtual void BeHappy() = 0;
|
|
|
|
|
You can start by using google[^]. This question has been asked and answered a few times.
|
|
|
|
|
Bound Checker!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
|
Hi all
How can i get blackberry IMEI Number?
Please help me.
|
|
|
|
|
Google!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
i use google but there havn't found any API and example then i ask here.
|
|
|
|
|
i guess on your BlackBerry u need to type this key combination
*#06#
this works on all branded ones - Nokia,LG,Samsung,Motorola,Siemens
|
|
|
|
|
Thanks but how can i retrieve through programing?
|
|
|
|
|
By picking one of the links and following directions?
I just hit google with this text: "c++ retrieve blackberry imei[^]"
Heavens knows what you'll find...
|
|
|
|
|
Hello everyone,
I would like to hook OleGetClipboard to return a custom IDataObject.
Injecting my code in the target application and hooking the function is quite easy and works pretty well. However, things get messy after the code of the function has been executed (app crash after a few seconds).
Here is the code of the MyOleGetClipboard function:
HRESULT MyOleGetClipboard(LPDATAOBJECT *ppDataObj)
{
FORMATETC f = { CF_HDROP, 0, DVASPECT_CONTENT, -1, TYMED_HGLOBAL };
STGMEDIUM s = { TYMED_HGLOBAL, { 0 }, 0 };
s.hGlobal = GetFileToPaste(); // Returns the handle to the DROPFILES structure (memory allocated with GlobalAlloc)
*ppDataObj = new MyDataObject(&f, &s, 1);
return (*ppDataObject) ? S_OK : E_OUTOFMEMORY;
}
The target application calls the methods from the returned object successfully, but I suspect some memory-related problem. For instance, the following code will also lead to a crash after a few seconds:
struct CFoo
{
CFoo()
{
m_i = new int[512];
}
~CFoo()
{
delete [] m_i;
}
int *m_i;
};
HRESULT MyOleGetClipboard(LPDATAOBJECT *ppDataObj)
{
CFoo *f = new CFoo();
delete f;
return fpOleGetClipboard(ppDataObj); // Call the original implementation
}
Do you have any idea on how I should deal with this?
Any help or hint would be greatly appreciated.
Thank you!
|
|
|
|
|
Does it happen also if you do a small test app of your own and invoke your hooked procedure from that?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
No, it works fine when called from a test app of my own
|
|
|
|
|
I'm just guessing here too but try allocating/freeing memory differently, like using CoTaskMemAlloc[^] and CoTaskMemFree[^], or using the IMalloc[^]. IF you need constructors to run, then use placement new after allocating the memory, however, if your object also allocates things dynamically along the way, like your CFoo constructor does, you might need to modify that also. As said, i might be completely off the track here...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
I overloaded the new and delete operators to use the functions you mentioned, but it does not solve the problem unfortunately.
void * MyDataObject::operator new(size_t n)
{
return CoTaskMemAlloc(n);
}
void MyDataObject::operator delete(void *p)
{
CoTaskMemFree(p);
}
I'm getting really puzzled.
|
|
|
|
|
And in your CFoo example, if you don't perform any new-delete, just call the original method, does it work?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
Yes it does. It also works with MyDataObject as long as I do not return the pointer to the caller.
I've done some more tests and I'm completely lost:
// Works fine
HRESULT MyOleGetClipboard(LPDATAOBJECT *ppDataObj)
{
return fpOleGetClipboard(ppDataObj); // Call the original function
}
// Will lead to a crash after a few seconds
HRESULT MyOleGetClipboard(LPDATAOBJECT *ppDataObj)
{
*ppDataObj = NULL;
return fpOleGetClipboard(ppDataObj);
}
// Will lead to a crash after a few seconds
HRESULT MyOleGetClipboard(LPDATAOBJECT *ppDataObj)
{
HRESULT hr = fpOleGetClipboard(ppDataObj);
OutputDebugString(L"After fpOleGetClipboard");
return hr;
}
|
|
|
|
|
Might be a calling-convention problem, try adding __stdcall or somesuch, am not sure by heart, like this:
HRESULT __stdcall MyOleGetClipboard(LPDATAOBJECT *ppDataObj)
{
...
} and see if it changes anything. Might try with __cdecl too if the __stdcall doesn't work.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
It's working! You're a genius.
The function declaration on MSDN is actually different from the declaration in the header files, calling convention has to be __stdcall (which makes sense as this is some COM related stuff)!
Thanks so much for your help!
|
|
|
|
|
Yourwelcome, i'm glad it worked out!
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
Hi everyone, I would like to know if the header file <process.h> is a Windows header file or part of the ANSI standard. If it is Windows specific header, then how will I write an application that will create threads when portability is of much concern. Thanks in advance.
|
|
|
|
|
|
«_Superman_» wrote: It is a standard C header file
I guess you completely missed the following part of the Wikipedia article: "Neither the header file nor the functions are defined by either the ANSI/ISO C standard or by POSIX"
|
|
|
|