|
|
i just found its already installed in my system but i never used it, i think iti'll solve my problem, thank you 
V
|
|
|
|
|
Vivekuniq wrote:
i think iti'll solve my problem
But only for implicitly loaded libraries.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
Hello,
I'm building a Windows Explorer-like application that displays files and folders. For my particular app, however, the files and folders being displayed may not exist on the computer the app is running on.
I'm using SHGetFileInfo with the flag SHGFI_USEFILEATTRIBUTES to get the icon for the file whether it exists on the computer or not.
Is there a similar way to get a folder icon for a path that doesn't exist? If the path I'm displaying in the folder tree doesn't exist, I want to get the default folder icon index (I'm using SHGetFileInfo to get the system image list).
Any ideas?
Thanks,
Ian
|
|
|
|
|
Why not just pick a folder you *know* exists (like the system folder, or temp - both paths can be retrieved using API functions) and retrieve the icon index for that?
|
|
|
|
|
That's currently my fall-back position. The only problem is, if someone (for some reason) setup a custom icon for the folder i'm using, then I get the custom icon for all the folders I'm displaying in the tree, instead of the default folder icon.
What I really want, is an index to an icon that is guaranteed to be the default folder icon.
Thanks for the good idea, but I'm hoping to find something a bit more robust.
Thanks for your reply!
-Ian
|
|
|
|
|
You can always create your own folder, if it comes down to that. Good luck, regardless - post what you come up with!
|
|
|
|
|
I am trying to pass the path the application was installed at to a custom action. But I can't seem to find anywhere what if any thing to put in [] to make it happen. Does anyone happen to know what will achieve this?
See what I am trying to do is write an install application that places a command line tool on the target machine. I would ideally like this to run from its own directory. But for this to be useful this needs to be part of the path on the machine. Following my previous questions I have a small program that modifies the path in the register that is run as a custom action but I need to pass it the install path as a parameter incase the user changes it during install.
Thanks in advance,
Charles
|
|
|
|
|
Im creating a GUI which has multiply pages of info, each of which has dialog boxes that display information ( simple cstring ), and from coding it seems apparent you cant update a dialog box when its not the current window, so I've created a way to hold all the info in the page (.cpp file) and now i wondering if its possible to add a calling method when the tab is clicked for that page. That way, when you click the tab for the page, it will call this method and pull all the latest data from my struct. Is this possible or is there a better way to do all of this? Im kinda new to .NET and C++
|
|
|
|
|
Does anyboday know any C++ function which can create an instance
by given a class name? In C#, we know that the function
Activator.CreateInstance(string className, BOOL ) does this job.
In C++, it is hard to find.
Any clue, hint and helpful resource link are very welcomed!
Thanks!!!
|
|
|
|
|
A thing like that is rarely used in C++! Can you describe why you need such things (give as many details as possible)? I'm almost sure this is a flaw in your design and that it can be done in another way.
|
|
|
|
|
No such thing in C++, unless you are using some plug-in framework.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
what you need is a "class factory". there are many ways to do it, one of the simplest is this:
CBaseClass * MakeObject(CString & className)
{
if (className == "CObject1") return new CObject1;
else if (className == "CObject2") return new CObject2;
else if (className == "CObject3") return new CObject3;
else return NULL;
}
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
ling_shen2002 wrote:
In C++, it is hard to find.
That's because it doesn't exist. You can write something similar for your own purposes, but there really isn't anything in C++ that works like the reflection support in .NET.
As cedric moonen wrote, you may want to reconsider your design.
|
|
|
|
|
I often use the inline keyword for simple functions (i.e. get/set members). e.g.
class CFoo
{
...
inline std::string GetString(void) const { return m_str; }
};
However, I have noticed that MS tends to use a special .INL file for in-lined code. For example:
class CFoo
{
...
std::string GetString(void) const;
};
inline std::string GetString(void) const
{
return m_str;
}
My question is ... why? Is there anything inherently wrong with inlining code directly in the class header? Are there compiler compatibility or performance reasons for splitting inline code out of the body of the class definition?
Just curious. Thanks in advance.
The Rob Blog
Google Talk: robert.caldecott
|
|
|
|
|
I don't know the response to your question but I just wanted to make a remark: when you define a function in your header file, it is always considered as an inline function.
From MSDN website:
A class's member functions can be declared inline either by using the inline keyword or by placing the function definition within the class definition.
Example 2
#include <iostream><br />
using namespace std;<br />
<br />
class MyClass<br />
{<br />
public:<br />
void print() { cout << i << ' '; }
private:<br />
int i;<br />
};<br />
<br />
int main()<br />
{<br />
}
|
|
|
|
|
Agreed. I like to include it for completeness/readability.
The Rob Blog
Google Talk: robert.caldecott
|
|
|
|
|
I think in some cases, especially with some MFC code, I see the functions inline at release build, but regular functions when building as debug. You would not have that option when declaring them in the header file.
|
|
|
|
|
Robert Edward Caldecott wrote:
My question is ... why?
Can't talk about MS, but at my work we have the same standard. Apparently, this is to better separate interface from implementation (personaly, I don't like it that much, but stick to the standard anyway).
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
I've never heard or read about a MSFT policy regarding how inline member functions should be declared, but I suspect that it's due to readability reasons. Like Nemanja said "separating the interface from the implementation" in order not to clutter the interface and make it hard to read.
Regarding the syntax of the language there is nothing wrong with defining the member function in the class definition. It would make the function inline implicitly as Blake said.
In order for clients to use the inline function, the definition has to be included to make it possible for the compiler to extract the body in place. The most straight forward way to accomplish this is by have the definition in the header file. As I understand it the compiler does the same thing regardless of whether the function was defined inside the class definition or not.
Sometimes in MFC code, e.g. CDocument::GetDocument, the debug version of the function is not inline in order to step into the function. Otherwise one has to step through the assembler code to know what happens.
To write the preprocessor directive (#ifdef _DEBUG) inside the class definition wouldn't be a very beautiful code to look at for my eyes. 
But that's a matter of taste and the compiler doesn't seems to have any.
--
Roger
|
|
|
|
|
Robert Edward Caldecott wrote:
My question is ... why?
Portability.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
Could you elaborate? Portability is potentially a big-deal for me at the moment...
|
|
|
|
|
I simply read it near the bottom of this.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
Do you mean this sentence:
Furthermore you can declare it in the header (with inline keyword) and seperate easally from them (with .inl files). Microsoft often use the same technique because it's better compatible with many compilers.
This make sense only if the poster was referring to poor support for member template functions in VC6, but templates are a separate issue when it comes to source code organization anyway.
Otherwise, this has nothing to do with portability.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Nemanja Trifunovic wrote:
Otherwise, this has nothing to do with portability.
Being able to move code and/or files over to another compiler has nothing to do with being portable?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
