boost looks VERY interesting, i think ill go with it. Thanks!

another way to get the file size (and it's portable too) is to use the ftell function: FILE *f = fopen("foo.dat","rb"); long lFileSize = 0; if (f != NULL) { fseek(f,0,SEEK_END); lFileSize = ftell(f); fclose(f); }

Thanks :)

In some, if not most cases, I have found that the PHYSICALOFFSETX and PHYSICALOFFSETY would apply to BOTH edges of the page, so you might want to do your math like this: // now take off the non printable area pagesize.cx-= (2 * dc.GetDeviceCaps(PHYSICALOFFSETX)); pagesize.cy-= (2 * dc.GetDeviceCaps(PHYSICALOFFSETY)); I also don't think this accounts for any of the margins the user might have set for the printing area. You might want to also obtain the printer device context (CreateDC) and examine the DEVMODE fields: dmYResolution - Specifies the y-resolution, in dots per inch, of the printer. If the printer initializes this member, the dmPrintQuality member specifies the x-resolution, in dots per inch, of the printer. Or you can get the from associated with a print job and check these fields: Size - Specifies the width and height, in thousandths of millimeters, of the form. ImageableArea - Specifies the width and height, in thousandths of millimeters, of the form.

Thanks, ibe found what the problem is, check out the implementation of the CSimpleArray class template included in VC6: BOOL RemoveAt(int nIndex) { if(nIndex != (m_nSize - 1)) { m_aT[nIndex].~T(); memmove((void*)&m_aT[nIndex], (void*)&m_aT[nIndex + 1], (m_nSize - (nIndex + 1)) * sizeof(T)); } m_nSize--; return TRUE; } as you can notice, if you remove the last element, the element is NOT destroyed. ibe been told however, that this "small glitch" is fixed in .NET, i guess the rest of us "mortals" using VC6 are stuck with it.

As much as I hate quoting Joan Rivers, oh grow up. Software Zen: delete this;

That looks simple enough, Thanks!

Thanks Mike :)

Be aware that const may allocate memory. To say #define is obsolete is idiotic. It's a tool that is extremely useful. I prefer it not be used for strings, but on occasion it's the best solution for a problem. Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke

I set the font to Tahoma in resource editor and the problem dissapeared Thanks guys!

and then you can call the function you make GetFileCount(LPCSTR path) and then post it here on codeproject :)

Thank you all for your answers, i think ill go with the id3lib. Thanks!

You're thinking of stacks. Each thread has its own stack, and its own copy of local variables in the function. Aside from that, you're on target :) --Mike-- Ericahist | CP SearchBar v2.0.2 | Homepage | 1ClickPicGrabber | RightClick-Encrypt You cannot stop me with paramecium alone!

This is weird!, i just created a new project, imported the exact same icon & bitmap and got no warnings at all, i compared every project setting (twice) and they are excacly the same!, yet i still get the same warnings on the original app! as a side note, the original app works just fine (even with the warnings) weird isnt it??

Multithreading isn't something you just flip a switch and now your application is multithreaded. If you haven't laid the groundwork for resource locking, it would be a VERY bad idea to try to make an application multithreaded when a message pump is such a simple and functional alternative. Tim Smith I'm going to patent thought. I have yet to see any prior art.

hi, thanks for your reply. when i ran that code in debug mode on my XP machine, it just caused a "first chance exception" shown in the output window of vc, (i dint even noticed it the first time) later i compiled the release version and it worked OK on windows XP, but when i tried it on NT4 server, then the exception became a "memory cant be read" error message, and the program crashed. heres the code in "do stuff": // checkout the command line for passed arguments int nargs=0; LPWSTR* cmdargs=CommandLineToArgvW(GetCommandLine(), &nargs); LPWSTR argument=NULL; for(int i=1; i<nargs; i++) { argument=cmdargs[i]; switch(i) { case 1: // 1st arg is times to do the test { int tests=_wtoi(argument); tests=tests>=0? tests : 0; if(!tests) { if(wcscmp(argument, L"0")!=0) // atoi failed or really zero? days=DEFAULT_TEST_TIMES; // invalid argument! } mttimes=tests; break; } case 2: // 2nd is "F" or "f" for File, (writte a log file) if(wcsicmp(argument, L"F")==0) dolog=TRUE; break; default: break; } } // release the memory if(cmdargs) GlobalFree((HGLOBAL)cmdargs); the first chance exception occurs in the GlobalFree() line, if i remove it, then it runs fine on both XP and NT4 and both release and debug versions.

Try Q155698, howto: retrieve current user and domain names on Windows 95 and 98. However, it requires use of 16-bit code, so you need to use thunks. The article points you at other articles, explaining how this can be done. Steve S

Aha!, now i see the trouble(s). 1.- i DO have to define both _UNICODE and UNICODE (bummer) 2.- im using the char versions of the standard string functions (strlen, strcat, etc), instead of the TCHAR versions of them (_tcscat, _ftprintf, etc.) 3.- i forgot to UN-define _MBCS (dough!) just one more question. reading MSDN, i noticed 2 versions of winmain, one for mbcs and one for unicode, so, is there a tchar version of it too? and, i havent changed the winmain to _twinmain or whatever and still the app compiles fine with unicode defined. so, do i have to change the entry point of the app to point to it? (ok its 2 questions). thanks very much for your answers! ps. Michael, your article on strings RULES! (as usual) :)

Falch.NET is a better IDE than Code Warrior because it is cheaper, and looks like VC6. Code Warrior is annoying to use, although it may be just that it was unfamiliar. As Michael said, try searching first, there's a whole section here on Palm articles. Christian I have drunk the cool-aid and found it wan and bitter. - Chris Maunder

Thanks for your answer James, ibe just read Mr J. Newcomer´s article on hooks, and for what i understood, the whole "dll calls back the app by a function pointer" idea wont work, so i went for PostMessage() instead, the app passes its HWND to the dll in the call to set the hook, wich is stored in the dll´s shared section, and in the hook proc, the dll Posts a custom message to the app using this HWND. Worked like a charm! Thanks for reading