|
if you want a 2k looks you can do it somewhere in display properties.
-prakash
|
|
|
|
|
I think 
you can change Theames 
-----------------------------
"I Think this Will Help"
-----------------------------
Alok Gupta
visit me at http://www.thisisalok.tk
|
|
|
|
|
just like in subject... i need some method for determining full path of application. what i want to achieve is to create ini file in the same folder as application but method which creates file requires full path.
thx in advance
|
|
|
|
|
Take a look at
GetModuleFileName()
Hope that helps
Karl - WK5M
PP-ASEL-IA (N43CS)
<kmedcalf@ev1.net>
PGP Key: 0xDB02E193
PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193
|
|
|
|
|
Remember to strip-off the filename from the end of the string returned from GetModuleFileName()
Ant.
I'm hard, yet soft.
I'm coloured, yet clear.
I'm fruity and sweet.
I'm jelly, what am I? Muse on it further, I shall return! - David Walliams (Little Britain)
|
|
|
|
|
perhaps i should have added a word "simple" to word "method"  .
GetModuleFileName returns DWORD, requires some strange parameters . i'll try to figure something out but i was looking for something analogical to AfxGetAppName() which returns LPCTSTR and is easy in use (doesn't need any parameters)
|
|
|
|
|
OK, just to help you out as it is my last day at work for the year!
Here is a function that will do the job for you. Yea, I know it is global but you can take the contents and wrap them in a class function if you like! 
inline CString GetModuleLoadPath()
{
int Idx;
TCHAR ModName[_MAX_PATH];
if( !::GetModuleFileName(NULL,ModName,sizeof(ModName)) )
{
ASSERT(false);
return CString(_T(""));
}
CString LoadPath(ModName);
Idx = LoadPath.ReverseFind(_T('\\'));
if( Idx == -1 )
{
ASSERT(false);
return CString(_T(""));
}
LoadPath = LoadPath.Mid(0,Idx+1);
return LoadPath;
}
Ant.
I'm hard, yet soft.
I'm coloured, yet clear.
I'm fruity and sweet.
I'm jelly, what am I? Muse on it further, I shall return! - David Walliams (Little Britain)
|
|
|
|
|
thanks a lot. it'd take me 2 hours to figure it out :].
if it's your last day... merry christmas and a happy new year ![Beer | [beer]](https://codeproject.freetls.fastly.net/script/Forums/Images/beer.gif)
|
|
|
|
|
You could also use PathRemoveFileSpec() after a call to GetModuleFileName(). This will remove the filename from the path.
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
can anyone cite me the differnces between a dll and a lib file??
|
|
|
|
|
The code inside the lib file is loaded during compile time and is 'added' inside your executable so, after compilation, you don't need to send the lib file with your executable.
With a dll, the code is loaded at run-time from the dll so you need to send the dll also with your executable.
[edit] Sorry: lib files are loaded at linkage, not at compile time of course... (writing too fast  ) [\edit]
|
|
|
|
|
DLL can be loaded and used in program at run time ....
LIB is used while linking; linker will add used parts of LIB into your exe file statically
rrrado
|
|
|
|
|
Every one is correct!
What they did not say is important:
In the passed if you linked in a normal .LIB file, then you had linked in every function that was contained in that file, whether you used them are not. I do not know if that is still the case, but it resulted in programs that where much larger than required to do the job, since most of the function linked in where not used. Plus the fact that every program had there own version of the same function code.
If the same functions from the same library are used in several programs, then you should use a .DLL. That way all the programs can share the same code: This reduce the size of the individule programs and reduces the amount of disk space require to store the programs and libraries they depend on. It also reduces the amount of memory required to load your program.
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
John R. Shaw wrote:
In the passed if you linked in a normal .LIB file, then you had linked in every function that was contained in that file, whether you used them are not. I do not know if that is still the case, but it resulted in programs that where much larger than required
you know, if you have a good compiler, it conserves only the functions that are actually called. that is the same case when you make much #includes, with many functions included that you will never use...
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
Note: "In the passed..."
Note: "I do not know if that is still the case...", because I have not checked.
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
Visual C++ 6.0 seems to have the boundary at the OBJ level.
One OBJ is made for each C or C++ file.
If you make a LIB file from one source file and it has dozens of functions in it, anything linking with the LIB gets all the functions. If you put all those functions into separate source files, you end up with many OBJ files, and link them into a single LIB. Only the functions directly called and their dependcencies are embedded within the resulting EXE file.
A classic 'library' will be designed so that functional dependencies are grouped by source file so your EXE size would be reduced. With the larger memory (virtual or not) footprints available on PC today, this does not seem to be such an issue any more.
I am not sure what the consequence of inlined functions in a header file are, probably only included as used, but EVERY one of them is repeated each time it is used, such is the reasoning for 'inline' - you are avoiding the function call!
|
|
|
|
|
My VC++6.0 project can be compiled in debug mode (MFC in shared DLL) without problems. But I have a problem to compile in Release mode (MFC linked statically). When I build the project after the Clean, there is no problem. But when I hit compile or execute button again, it shows the dialog with all the project's files saying they were changed and it must be rebuilt again.
When I confirm this, all files will show me this error:
fatal error C1852: 'Release/aaa.pch' is not a valid precompiled header file
in the #include "stdafx.h" line.
I've added some files to project manually, but I've turned off precompiled headers for these files individually.
What can be the problem ? Again debug build is running without problems ...
Thank you !
rrrado
|
|
|
|
|
Have you tried a clean release build, i.e. clean the project and rebuild all.
Ant.
I'm hard, yet soft.
I'm coloured, yet clear.
I'm fruity and sweet.
I'm jelly, what am I? Muse on it further, I shall return! - David Walliams (Little Britain)
|
|
|
|
|
Yes, when I clean the project, first build is done without problems.
But the next build is giving me the errors.
I must always clean whole project when I want to build it and it takes a long time since it's quite big project 
rrrado
|
|
|
|
|
I've tried to set my PCH option for release mode to "Automatic use of precompiled headers" instead of "Use Precompiled headers" and it's working now...
rrrado
|
|
|
|
|
Hi all,
For one application I have to design, I need to know what is connected on the usb plugs (mouse, camera, webcam, adsl modem ...)!
Does anyone has an idea ??
Thanks a lot !
Etienne
|
|
|
|
|
How can we handle the Mouse wheel in a Dialog based application. On the Dialog controls are more in number and the Dialog is having the vertical scroll.
Can you help?
Thanks.
|
|
|
|
|
|
While running debug mode on an application written by me, the debug would complain that it has memory leak:
Detected memory leaks!
Dumping objects ->
{118957} normal block at 0x04D89230, 22960 bytes long.
Data: < > 00 00 00 00 CD CD CD CD 00 00 00 00 00 00 00 00
...
Is there any tool to trace the memory usage? It may be hard to find where the error is by simply trace the code( too long to examine  ) Thanks!
|
|
|
|
|
VS has the ability to help you with that. What you have to do is add the following lines, which should be there by default, to the beginning of every cpp file in your project
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif If you have these lines in your code, then the debugger will give you the file name and line number of where the leaked memory was allocated, making it easier for you to figure out where you forgot to add the delete.
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
"Obviously ??? You're definitely a superstar!!!" mYkel - 21 Jun '04
Within you lies the power for good - Use it!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
