|
How can I get the text to a CString from a list box
with out select anything?
\Larsson
|
|
|
|
|
I think CListBox::GetText should work.
|
|
|
|
|
Well Sorry!,
I don't get the text from the Listbox.
And if i do how can a get al that is listed in the listbox?
|
|
|
|
|
Here's an example how to get all items' text:
CListBox lb;
...
CString str;
int n;
for ( int i = 0; i < lb.GetCount(); i++ )
{
n = lb.GetTextLen( i );
lb.GetText( i, str.GetBuffer(n) );
str.ReleaseBuffer();
}
or
CListBox lb;
...
CString str;
for ( int i = 0; i < lb.GetCount(); i++ )
{
lb.GetText( i, str );
}
should work, too. In both cases str holds the current item's text.
|
|
|
|
|
Thank's you are a star.
\Larsson
|
|
|
|
|
Hi,
in the past, when our application were pure C based, we had our own malloc and free routines. These were called by simply re-#defining malloc and free as C-macro's and 'route' them to our own PrivateMalloc and PrivateFree routines.
Now, in C++, we want of course to reuse our memory manager (which has some peculiar advantages for us), however, we see some problems:
- In our old software, the memory pools were initialized when the application started up (as first action). Now, in C++, new can already be executed before the main is actually called (e.g. in the constructor of a global variable). However, we think we can solve this by performing the initialisation of the memory pools in the first call to 'new'.
- In our old software, leaked memory was reported at the end. Since global variables' destructors are executed after the application has finished, we cannot report memory leaks at the end of the application, since the list will always contain memory that still needs to be deleted by the global variables' destructors.
- MFC seems to have their own new and delete implementation. We aren't sure that MFC doesn't rely on some specific part of their implementation. Can we simply ignore the MFC new/delete and use our own implementation?
I don't know how other memory managers solve that problem.
Maybe anyone of you have already written their own new/delete implementation; then, how have you done that? And did you encounter any problems with MFC?
Thanks in advance.
Patje.
Enjoy life, this is not a rehearsal !!!
My Articles:
- Implementing a Subject/Observer pattern with templates
|
|
|
|
|
1. The approach you are suggesting is just right.
2. Use atexit .
3. In release mode, MFC uses the same new as everybody. In debug mode, new is a macro that resolves to an overload of new specifying the file and the line where the call occurs. Don't know how this can be ridden of.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Thanks for your answer Joaquin.
When I saw "atexit", I thought "yes, that's it". Unfortunately, my colleague saw the following in the MSDN documentation:
Using atexit
With theatexit function, you can specify an exit-processing function that executes prior to program termination. No global static objects initialized prior to the call to atexit are destroyed prior to execution of the exit-processing function.
As I understand it, it seems like the global variables are only destroyed after the atexit execution. So this doesn't seem to solve my problem.
I verified this with the following test program:
<br />
#include <stdlib.h><br />
#include <iostream><br />
<br />
class MyClass<br />
{<br />
public:<br />
MyClass() {printf ("Constructor\n");}<br />
~MyClass() {printf ("Destructor\n");}<br />
};<br />
<br />
MyClass myVariable;<br />
<br />
void __cdecl AtExitFunction (void)<br />
{<br />
printf ("AtExit\n");<br />
}<br />
<br />
void main ()<br />
{<br />
atexit (AtExitFunction);<br />
}<br />
(I had to use printf, because std::cout wasn't available anymore in my destructor).
And indeed, the following is printed:
Constructor
AtExit
Destructor
Other suggestion???
Enjoy life, this is not a rehearsal !!!
My Articles:
- Implementing a Subject/Observer pattern with templates
|
|
|
|
|
Well, the following technique has some defficiencies, but it can serve: assume your new override is defined in say "mynew.h" : then, as every .cpp using the overriden new has to include implicitly or explicitly "mynew.h" , you can take advantage of this by forcing the construction of a "sentinel" object which, under normal conditions, is constructed before anything else:
class leak_sentinel
{
static unsigned& count(){static unsigned count_=0;return count_;}
public:
leak_sentinel(){++count();}
~leak_sentinel()
{
if(--count()==0){
}
}
};
static leak_sentinel lks;
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I posted a similar solution below, but I like your idea of a count function much better. You learn something new every day.
By the way, your count function doesn't need to be static, as far as I can tell.
Regards,
Alvaro
All you need in this life is ignorance and confidence, and then success is sure. -- Mark Twain
|
|
|
|
|
By the way, your count function doesn't need to be static, as far as I can tell.
You're right. It's just a matter of style: count is static as there's no need for it not to be.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Joaquín M López Muñoz wrote:
count is static as there's no need for it not to be.
Yes, this is actually the same approach I usually take. If a function can be static -- it doesn't access any non-static members -- then it should be static. This allows it to be used with or without an instance of the class.
The only conflict I have with this approach is that it makes little sense when the function is private or protected. At that point it's like, "Why bother typing the static keyword when it's just an internal function? And if I ever decide to let it access non-static members, then I have to go and remove the static from it." So... I'm not convinced one way or the other when it comes to non-public functions of this type.
Regards,
Alvaro
All you need in this life is ignorance and confidence, and then success is sure. -- Mark Twain
|
|
|
|
|
If you have implemented PrivateMalloc and PrivateFree, implementing new for your classes is a matter of overwriting new for each of them, or casting the memory in case of build-ins. I am just curios what does make your memory allocation superior to standard Windows algorithms? What is it you are gaining with custom memory management?
|
|
|
|
|
I don't want to add a new and delete to every class (although we could do this with a simple define and inline new/delete methods).
Our memory allocator (written about 12 years ago) is maybe not as advanced as some commercial memory allocators, but it does the following:
- handling memory pools in discrete sizes to prevent memory fragmentation
- showing memory leaks at the end of the application
- showing the stack of the malloc-location of leaks
- detecting memory overwrites
Especially the last 3 things are interesting, because we have the most interesting functionality of e.g. Rational Purify, but without the huge overhead (in cpu-time and in cost) of it.
Thanks for your answer anyway.
Enjoy life, this is not a rehearsal !!!
My Articles:
- Implementing a Subject/Observer pattern with templates
|
|
|
|
|
this is pretty much what MFC does in debug. You can try to adapt their approach.
1. Overload global new operator with some custom parameter
2. redefine new (see how MFC does it "#define DEBUG_NEW new(THIS_FILE, __LINE__)") to be redirected to your new
do not forget array new()[]. do the same for delete.
P.S. I would question the performance lose in your approach, but I guess it is worth it for you.
|
|
|
|
|
For your first and second points, I think I have the solution:
-- MemoryManager.h
#ifndef __MEMORYMANAGER_H__
#define __MEMORYMANAGER_H__
class MemoryManager
{
public:
MemoryManager()
{
if (m_uCount++ == 0)
{
}
}
~MemoryManager()
{
if (--m_uCount == 0)
{
}
}
private:
static UINT m_uCount;
};
static MemoryManager s_mm;
#endif
-- MemoryManager.cpp
#include "stdafx.h"
#include "MemoryManager.h"
UINT MemoryManager::m_uCount = 0;
Add your pool init/cleanup code inside MemoryManager's constructor/destructor and include MemoryManager.h inside all your CPPs. The static s_mm inside the header file ensures that your code is not called before or after it's appropriate.
Another approach to take is to look at the source code for MFC's memory tracking logic. If you purposely add a leak to your program, run it, and exit, it will report the leak at the end. You may want to take a look at files such as dbgheap.c to see how they accomplish this.
Regards,
Alvaro
All you need in this life is ignorance and confidence, and then success is sure. -- Mark Twain
|
|
|
|
|
Hello,
I got Platform SDK February 2001 edition from one of my friends.
I know it's older version now, i heard platform sdk 2003 is release now.
Anyway, i've problem in using platform sdk !
I've installed it in my system without any problem.
As i can see, platform sdk made some directories, for example Include - Lib - Src in installation directory.
How can i use them in my programs ?
Simply, by using Directories in Tools->Options ?
I'm scary about Confilcting files in vc directories ...
Any idea ?
Regards,
My month article: Game programming by DirectX by Lan Mader.
Please visit in: www.geocities.com/hadi_rezaie/index.html
Hadi Rezaie
|
|
|
|
|
Hadi Rezaee wrote:
I'm scary about Confilcting files in vc directories ...
Well, you simply need the D:\PlatFormSDK\include to be before (on top of) the MSVC++ ones. You do not delete them but keep them as a fallback.
And remember - they are from 1998 - extremely outdated. They only suppoert Win98, not even 98SE.
My opinions may have changed, but not the fact that I am right.
|
|
|
|
|
1- Add include, src, lib directories to VC directories (Tools, Options, Directories)
2- VC searches header files and their implementations from that list. In other hand it searches first directory then seconde one and so on. When find desired file, using it for compiling. Because of this no conflicting will occured.
3- Find the latest PSDK from Microsoft.com
A. Riazi
|
|
|
|
|
I recently installed the May 2002 SDK just to have a look around and compare headers, test the tools, etc. It's a monster for a novice (as I am), but the Help documentation alone make the lengthy install worth it. Like the two previous posters, it's simple to set the directory paths in Visual C++ to the SDK include and library folders. There is a help page in the documentation that instructs you, in simple understandable language.
I tried it on a couple of simple programs that I'd put together for Windows 98, and usually it compiles correctly (as there are no significant changes in the headers). Then I tried it on a more complex programs written for Windows 2000, and I got (predictably) numerous error messages or, when it compiled, message boxes with error messages when launched. The new functions or altered parameters for old functions will operate incorrectly with the older Windows 98 Systems calls, and you will get those annoying message boxes with mysterious IDs and obscure functions.
However, it's worth the time to familiarize yourself with the process, and when you upgrade to a newer Windows version, the virtual chaos will not cause you undue mental distress and anguish.
|
|
|
|
|
Is it possible to create a file >2GB under NT/2K/XP
with normal Admin permisions.
I have tried:
CreateFile(...)
SetFilePointer(...)
but this fails with something like "permissions not correct"
please point me in the right direction
|
|
|
|
|
i dont think this is possible becz they allow a max partition of 2 gb and so i think that it is not possible to make a file size greater than that..anyway keep searching mayb u find a way thru..
cheers
himanshu
|
|
|
|
|
Did you use GENERAL_WRITE?
A. Riazi
|
|
|
|
|
'fraid so, did everything the online help system told me
code is below:
ULARGE_INTEGER i64FreeBytesToCallerC;
ULARGE_INTEGER i64TotalBytesC;
ULARGE_INTEGER i64FreeBytesC;
ULARGE_INTEGER i64FreeBytesToCallerD;
ULARGE_INTEGER i64TotalBytesD;
ULARGE_INTEGER i64FreeBytesD;
BOOL bSuccess = GetDiskFreeSpaceEx("C:\\",
(PULARGE_INTEGER)&i64FreeBytesToCallerC,
(PULARGE_INTEGER)&i64TotalBytesC,
(PULARGE_INTEGER)&i64FreeBytesC);
bSuccess = GetDiskFreeSpaceEx("D:\\",
(PULARGE_INTEGER)&i64FreeBytesToCallerD,
(PULARGE_INTEGER)&i64TotalBytesD,
(PULARGE_INTEGER)&i64FreeBytesD);
HANDLE hFile = ::CreateFile("C:\\File",GENERIC_WRITE|GENERIC_READ,
GENERIC_ALL,
NULL,
CREATE_ALWAYS,
FILE_ATTRIBUTE_NORMAL,
NULL
);
long dwHighPart = i64FreeBytesC.u.HighPart ;
DWORD result = ::SetFilePointer(hFile, i64FreeBytesC.u.LowPart, &dwHighPart, FILE_BEGIN);
|
|
|
|
|
You must (at least) take into account that creating a new file will probably allocate at least one cluster, and as the file grows it would probably need several more runs/clusters just to describe the layout of the file on disk.
Try reducing the size of the file you want to create, one page at a time, and I'm sure you'll see that sooner or later the SetFilePointer call will succeed.
Oh, another thing, be prepared that the process can, or more likely will hang for the duration of time needed to actually write NULL's to the filesize you requested (and it can't be terminated, not even by trying to kill it by Task Manager, since it's "hanging" in kernel-mode), why your machine could become "less useful" for other work in the time needed to zero-fill this file.
++luck;
|
|
|
|
|