|
CodingLover wrote: But one thing I've confused, in windows API some cases it's use and some cases it's not.
You have to clarify that.
When referring to the "windows API", it usually means functions that resides in e.g. Kernel32.dll that can be called from any language such as C, C++, VB, C#, Java and so on.
The scope operator is C++ specific so as I understand it your question doesn't make sense.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
It prevents a same-name and same-signature class member from being called by accident.
For example, if you are working in a class that has a member SetWindowText( HWND, LPCTSTR ), but you want to call the Win32 (or global) version of it, you would use ::SetWindowText( hWnd, _T( "Your Text" );. Otherwise, you would call the class' version of the function.
Calling API functions like that also protects you from future changes - if you have code in a class that calls SetWindowText(...) and in the future someone adds a member function to the class (or its base) with the same signature and recompiles your code, your older code would start calling the newer method. This may or may not be what you want, so you can "future-proof" your code by using the global namespace operator.
Peace!
-=- James Please rate this message - let me know if I helped or not!<hr></hr>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
You're probably talking about MFC? For example, if you call MessageBox, that would call the MessageBox function provided by MFC, whereas ::MessageBox would call the global version (WIN API).
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
CodingLover wrote: Why is that?
no need to use it when there is no ambiguity. unless you want to make the code perfectly readable.
If the compiler has many definitions of the same identifier, then if you don't use the scope operator, the identifier in the current scope will be used. if not found there, then it will search in the namespaces declared to be currently in use (using namespace directive).
To tell the compiler that you want to use the global scope identifier, then you have to prepend it with ::...
|
|
|
|
|
CodingLover wrote: Can someone explain what's the difference between the followings.
int freeLib = FreeLibrary(m_hwnd_Lib);
int freeLib = ::FreeLibrary(m_hwnd_Lib);
Yes: I see two colons in the latter statement, missing in the former one. 
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
It's called the scope resolution operator.
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
It's usually useless. But you do need it when there happens to be another FreeLibrary function visible in the current scope that hides the ::FreeLibary API. This actually happens with CWindow API wrappers, which are named after the APIs being wrapped.
|
|
|
|
|
I am compliing the idl file with visual studion 2005 (c++), I am getting below error, Please advice
Please update.
7>IDL compiling...
7>idl: error: cmd line option not supported: -B
7>usage: "-flags" for details.
7> idl [-flags] [-?] [-Dname[=value]] [-Idir] [-N] [-Uname] [-3] [-V] [-u] [-v] [-w]
7> [-jbase] [-R] [-base] [-poa] [-xml] [-pss_r] [-wsdl] [-psdl] [-jpoa]
7> file [file]*
|
|
|
|
|
ptr_Electron wrote: I am getting below error, Please advice
....
idl: error: cmd line option not supported: -B
Ummm, I guess the command line option '-B' is not supported... 
More seriously, what does your complete command line look like?
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Thank you very much for your responce.
I am trying to compile an IDL file in Visual Studio 2005, I havn,t set any command line option, I just did rebuild all thats all, after installing Inoa ORBIX 6.3.
How to check it out and set the correct one, please advice.
Thanks
|
|
|
|
|
ptr_Electron wrote: I am trying to compile an IDL file in Visual Studio 2005, I havn,t set any command line option, I just did rebuild all thats all, after installing Inoa ORBIX 6.3.
The above doesn't provide me with any information that can be used to help you.
The fact that you have not changed any settings is irrelevant.
I specifically asked for a piece of information that might be relevant, but you failed to provide it.
This means that at least I cannot help you until you answer my question.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
I recall there's different versions of the IDL compiler out there.
I think there's a newer one in the windows SDK version 6.
Maybe you need that?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />
Peter Weyzen<br />
Staff Engineer<br />
<a href="http://www.soonr.com">SoonR Inc -- PC Power delivered to your phone</a>
|
|
|
|
|
Peter Weyzen wrote: I think there's a newer one in the windows SDK version 6.
Maybe you need that?
I guess you replied to the wrong post Peter...
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Good afternoon!
I'm trying to create a Dll file and i have a lot of .h and .c files to insert on it. I already saw MSDN article "how to create a dll file" but the sample presented is simple and only includes one source code file. How to create my Dll file? Anybody knows documentation about this subject with good samples?
Best Regards.
|
|
|
|
|
Are you using Visual Studio and its project/solution system or
building from the command line?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
I'm using Visual Studio 2005.
|
|
|
|
|
Walkthrough: Creating and Using a Dynamic Link Library[^]
The section "To add a class to the dynamic link library" explains adding a new source/header
file combination to the project. To add existing files to the project, choose "Add Existing Item…"
instead of "Add New Item…".
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
How about starting in the DLL section of CodeProject[^]?
At least so you can better explain what you want to do and more specifically what your problem is.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Essentialy, my problem is how to insert my .h and .c files in a project to build a .dll one.
|
|
|
|
|
ajorge2008 wrote: Essentialy, my problem is how to insert my .h and .c files in a project to build a .dll one.
In that aspect there's no difference between a DLL project and an ordinary project.
You add the files in the solution/project explorer.
One difference you will eventually come across is that a DLL exposes some kind of interface, a number of functions you can call from the client that loads the DLL.
Try to keep things as simple as possible and gather all the functions in the exposed DLL interface in one single source (.c / .cpp) file.
Since a DLL serves to perform operations that are logically connected in way or the other, it makes sense have the interface implemented in one single file. At least in the beginning.
Mark has provided you with another good starting point.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
I used Visual C++ 2005 to generate an MFC doc-view sample application. I got an strange error message when I try to open an previously save file in MFC in a static library. I have traced the problem and it was the codes in MFC provided docmgr.cpp below which caused the problem:
BOOL CDocManager::DoPromptFileName(CString& fileName, UINT nIDSTitle, DWORD lFlags, BOOL bOpenFileDialog, CDocTemplate* pTemplate)
{
CFileDialog dlgFile(bOpenFileDialog, NULL, NULL, OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT, NULL, NULL, 0);
CString title;
VERIFY(title.LoadString(nIDSTitle));
dlgFile.m_ofn.Flags |= lFlags;
...
}
The VERIFY(title.LoadString(nIDSTitle)) statement gives VERIFY's error.
However, if I compiled the application in "Use MFC in a shared DLL".
Then compile and build it, it can work without any problem!
Anyone know what the problem is?
|
|
|
|
|
looks like the string id isnt representing a string in your resource. Make a "Rebuild all" and look whether the id is a valid string.
Greetings from Germany
|
|
|
|
|
I have tried rebuild all and did not work...
|
|
|
|
|
yellowine wrote: Anyone know what the problem is?
Have you set a breakpoint on that statement to see what the value of nIDSTitle is, or how about stepping into the LoadString() method to see what it is returning?
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
Tried step into debug, nIDSTitle seems to be the standard AFX_IDS_OPENFILE (61440).
It seems the standard AFX_IDA_... are defined in afxres.rc, how how comes this file is not included in the project. Therefore it seems to be related to project setting to solve it. Just dunno.
Any idea?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
