i have a appilcation consists of thousands lines of code. when i do some specific operation, i.e. open a very large document, the app almost eats up my memory. but after a while, the memory is given back. i have tested the codes and found no memory leak.
so, my problem is how to find the codes who eat up my memory.
any one can help me?
First, when you do a malloc or new, you extend the heap. For optimization reasons, the memory manager may not return the heap back to the OS immediately. When needing to allocate especially large chunks of memory, you can use a low level API directly or, with some compilers/CRTs, a different heap (for Windows, here's an article discussion various options: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366533%28v=vs.85%29.aspx[^].)
Also note that if you allocate memory and sit around, the OS may page it out. To understand the difference in Windows, look into "private bytes" and "working set".
I want to ask you something: what would you use for image processing and more important, convert images from an format to other ? I am using MFC, and I was thinking of GDI+, but I didn't find so many examples to how to convert images ...
I see here so interesting controls, CBitmapEx, CxImage, CImageStone, but I don't know what is proper to do the job ... I will appreciate any hint.
No, I didn't look over by now ... Thank you for your interest, so you suggest to use GDI+ ... I didn't try to load some not common image file, .raw, .tiff multipage, etc. ... I don't know if does function ...
No, I just asked if you had looked at that function and if it solved your problem. Your question is not particularly clear, i.e. what do you want to convert from, and what do you want to convert to? I am sure that Google could find you lots of information if you were more specific about your requirements.
One of these days I'm going to think of a really clever signature.
The Win32 API offers very limited image conversion. There are many third party libraries, some free, others not. I'm currently looking at CxImage to replace Leadtools, which is now even more expensive than before and isn't royalty free. If you are willing to pay more, one royalty free library I've used is http://www.gdpicture.com/[^]. The ActiveX part always annoyed me, but it had a good PDF viewer component, so I lived with it. I'm also going to evaluate http://www.data-tech.com/products/imaging/imageman-dll.aspx[^]. (I work for none of these companies.)
If you are interested in audio development, I made a simple SDK to tag audio libraries patches. There is ton of things people are waiting for on this topic:
- analyze a WAV file and extract tagging informations (Percussive, Smooth ...)
- extract informations from REX files and convert them in tags
Plug-ins can be .NET assemblies or native DLL
as Universal Patch Finder is free,
the idea is to let all of this entirely free.
Where would I specify this directory in Visual C++ 6.0
Are you working in MFC, if yes then you can use the class wizard to generate the class based from OCX,TLB or DLL
"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
<pre lang="text"> What is the basic difference in processing system messages in MFC? Should I use message map or WindowProc? In my included sample the WindowProc get executed first ( as expected ) , but I really do not do any message processing in this case. So my secondary question would be - what is considered by OS as processed message? </pre>
Never. MFC has an inbuilt message pump and MessageProc() handler which distributes the messages according to your MESSAGE_MAP entries. If you add your own MessageProc() then you break the connection between those entries and your message handlers.
One of these days I'm going to think of a really clever signature.
I would agree with NEVER... use message maps in MFC. If you find it doesn't do something specific that you needs, that's when you go around the framework, other than that... it's best to try to use the framework that's there.
Messages use WindowProcs, but MFC handles that for you. There's really very few cases where you'd have to go around what MFC already does. Only reason to code your own WindowProcs would really be if you're doing native Win32 coding.
Because WINVER is used in Windows.h and many other header files, it is set to the smallest supported value in Windows.h if not already defined.
It is a definition that decides which API functions and structures can be used. Which compiler is used does not care. But to use features introduced with newer Windows versions, you must use newer include files from a newer Windows SDK.
Jochen, thanks again for your input. I was just puzzled that the WINVER is defined in Windows.h only if it is not already defined elsewhere. But there is nothing wrong with that and it was a good learning experience for me. I think the main "problem" is that I get involved with coding and assume that the supporting headers are there or are OK. With all the new IDE's I wish the people who post code here would point out which OS / SP / SDK is required for the code to even compile. But than one would not learn anything from "mistakes", tough call. Vaclav
The problem is that you are using an ancient development environment. I have not used VC 6 since many years. At work I'm still using the also outdated Visual Studio 2003 because we need to support Win98 and 2K for some machine control systems.
In 2012 there is no more support for Windows 9x, NT4, and 2000. So there is no need to use old dev software and most here assume that you are using a newer version (VS 2008 or later). In fact you should use a newer version when writing programs for actual Windows versions. Especially VC 6 is too old. With VS 2003 and updated SDKs, I'm at least able to write code for Windows 7.
It is common practice that the actually oldest supported Windows versions is the min. requirement. With your VC 6 version that was Windows 95. For Microsoft and the people here it is actually Windows XP. When reading articles here, just have a look at the publishing date to guess what is supported. Many articles also have a note about the requirements.
I know now that you are using VC 6. For future questions, it may be helpful to add a note that you are using VC 6 so that others are prepared.
"I know now that you are using VC 6. For future questions, it may be helpful to add a note that you are using VC 6 so that others are prepared."
I have stopped telling people that I am using VC6.0 because they would limit their replies / help to "upgrade to xxxxx". This is my hobbby now and as retired OF I am reluctant to spent $ every year ( it seems that way) on NEW VS 20xx. ( MFC is not free with VS !) Most of the time I can accomplish what I want with VC6.0, but as you noted not always, and than I look prety stupid with my basic questions. Personally , I do not care if MS stops supporting their stuff right know. I get very uncomfortable when my XP gets automatically patched without any explanations why!) Even when I was programming proffesionaly I have NEVER used MS support and do not care for it, as you can see I rather look foolish here with my basic questions than pay MS.
Last Visit: 31-Dec-99 18:00 Last Update: 23-Jul-16 14:23