|
Try installing it. That installation is necessary if we want to run a VS 2005 exe in a OS where Visual studio 2005 is not installed.
Also confirm that you are trying to run the release version of the binaries.
|
|
|
|
|
Naveen wrote: That installation is necessary if we want to run a VS 2005 exe in a OS where Visual studio 2005 is not installed.
Isn't it sufficient to create an installation along with necessary dlls found in the Program Files\Microsoft Visual Studio 8\VC\redist\x86 folder?
Have you tried out this way? Just curious.
Nibu babu thomas
Microsoft MVP for VC++
Code must be written to be read, not by the compiler, but by another human being.
Programming Blog: http://nibuthomas.wordpress.com
|
|
|
|
|
I havent tried that way. Since those binaries are implemented as side-by-side assemblies, I guess it will be little difficult to include them in the installation.
|
|
|
|
|
I am making a chat application. I need to send & recieve emoticons/smileys. I am getting their codes. What to do to retireve the smileys properly
Thanks In advance
Dhiraj
|
|
|
|
|
What do you mean exactly ? Emoticons are just a specific combination of symbols (e.g. : and ) ). Those symbols are then interpreted by your application and replaced by a small image representing the emoticon. But you have to do that yourself.
|
|
|
|
|
Thanx! I will try to do it.
|
|
|
|
|
Hi all,
I have made a simple text file using CStdioFile object and writing and reading strings using that file and saved it using different file extension suppose .ehn. Now i want to hide this file i.e it must be shown when i click on folder option show hidden files and folder...
how can i do this......
thanks in advance
|
|
|
|
|
Use the api - SetFileAttributes() by passing FILE_ATTRIBUTE_HIDDEN as parameter.
Regards,
Jijo.
_____________________________________________________
http://weseetips.com[ ^] Visual C++ tips and tricks. Updated daily.
|
|
|
|
|
|
I have a dialog-based application that contains a combo box.
I've subclassed the combo box like this :
HBRUSH CSubClassedComboBox::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)
{
if (nCtlColor == CTLCOLOR_EDIT)
{
if (m_CmbEditBox.GetSafeHwnd() == NULL)
m_CmbEditBox.SubclassWindow(pWnd->GetSafeHwnd());
}
else if (nCtlColor == CTLCOLOR_LISTBOX)
{
if (m_CmbListBox == NULL)
{
m_CmbListBox = new CListBoxEx;
if (m_CmbListBox->GetSafeHwnd() == NULL)
{
m_CmbListBox->SubclassWindow(pWnd->GetSafeHwnd());
}
}
}
HBRUSH hbr = CComboBox::OnCtlColor(pDC, pWnd, nCtlColor);
return hbr;
}
m_CmbEditBox and m_CmbListBox are objects of CEdit and CListBoxEx(derived from CListBox) respectively
and declared in SubClassedComboBox.h as the class CSubClassedComboBox's members.
During run-time of my application, I pull down the list box and right-click on any of the
list box items. My control reaches here :
void CListBoxEx::OnContextMenu(CWnd* pWnd, CPoint point)
{
GetParent->TestFn();
}
Now, in CListBoxEx::OnContextMenu, I want to call a member function ( say TestFn() ) available in class CSubClassedComboBox.
Please see the following code :
void CListBoxEx::OnContextMenu(CWnd* pWnd, CPoint point)
{
((CSubClassedComboBox *)GetParent())->TestFn();
GetParent())->TestFn();
}
As in the comments, the second statement doesn't work. I don't want to cast the pointer returned
by GetParent() to CSubClassedComboBox * bcoz this wouldn't be in generic sense.
By this, I mean to say that GetParent() should be able to give the parent pointer which is
CSubClassedComboBox * in this case, but could be anything else (eg. another container window that contains
the CListBoxEx object).
In summary,
GetParent()->TestFn(); should call TestFn() of CSubClassedComboBox as per the requirement above.
But GetParent())->TestFn(); should be able to call TestFn() of say CSubClassedSomeContainerWindow
if m_ListBox is a member of CSubClassedSomeContainerWindow
So, I am looking for a solution that is generic, to find the parent.
Any help would be appreciated.
Thanks in advance.
|
|
|
|
|
SherTeks wrote: So, I am looking for a solution that is generic, to find the parent.
If I understood your question properly...
Define a message for your parent class, for e.g. WM_TEST_FN . So all the parent needs to do is define a handler for this message. So if the handler is there then the function will be called.
So then you can use SendMessage to send this message.
Nibu babu thomas
Microsoft MVP for VC++
Code must be written to be read, not by the compiler, but by another human being.
Programming Blog: http://nibuthomas.wordpress.com
|
|
|
|
|
ok. You won this time
|
|
|
|
|
Naveen wrote: ok. You won this time [Frown]
Nibu babu thomas
Microsoft MVP for VC++
Code must be written to be read, not by the compiler, but by another human being.
Programming Blog: http://nibuthomas.wordpress.com
|
|
|
|
|
Thanks for your reply.
May be I need to make my question a bit more clearer.
Just assume that my dialog application has 2 controls : 1) a Combo Box and 2) another container control similar to
combo box (but not exactly combo box).
The common trait between the two controls is that they both embed the list box object derived from CListBoxEx.
Now, I could right-click on any one list box at a particular point of time during run-time.
The right-click would bring the control to the OnContextMenu of CListBoxEx::OnContextMenu. In this place, I should be
able to identify the parent ie. either control 1) or 2) using GetParent(). But the only condition is that I shouldn't
cast the pointer returned by GetParent() to any of the parent control pointers ie. GetParent()->TestFn() must call
the TestFn() member function of the appropriate control of which the list box was right-clicked.
Thanks
|
|
|
|
|
SherTeks wrote: But the only condition is that I shouldn't
cast the pointer returned by GetParent() to any of the parent control pointers ie. GetParent()->TestFn() must call
the TestFn() member function of the appropriate control of which the list box was right-clicked.
Well you don't need any casting right if you are using messages. Take a look...
GetParent()->SendMessage( WM_TEST_FN, SomewParam, SomelParam );
Now all the parent class needs to do is add a message map entry to handle this event.
BEGIN_MESSAGE_MAP(...)
ON_MESSAGE( WM_TEST_FN, TestFn)
END_MESSAGE_MAP()
TestFn signature should look like this...
LRESULT TestFn( WPARAM wParam, LPARAM lParam );
Nibu babu thomas
Microsoft MVP for VC++
Code must be written to be read, not by the compiler, but by another human being.
Programming Blog: http://nibuthomas.wordpress.com
|
|
|
|
|
Correction : In my previous post, please consider m_CmbEditBox as of type
CEditEx and not of type CEdit.
My exact requirement is like this :
On right-clicking the list box item the control reaches
CListBoxEx::OnContextMenu. Please see the comment :
void CListBoxEx::OnContextMenu(CWnd* pWnd, CPoint point)
{
GetParent()->TestFn();
}
What am I doing wrong for list box bcoz the same mechanism for the child
edit box of the CSubClassedComboBox works fine ie.
void CEditEx::OnContextMenu(CWnd* pWnd, CPoint point)
{
GetParent()->TestFn();
}
Is there anything to do with the temporary creation of the list box which
is not the case with edit box ? If so, how could I acquire the desired result ?
Thanks
|
|
|
|
|
One method is to send a USER message to the parent window and you should write a ahndler for that message in the parent window instead of TestFn(). And offourse it is generic.
|
|
|
|
|
...at least it appears to be a problem with stack corruption.
Here's the problem. I'm attempted to use std::string in some existing code for an enhancement I'm doing and was getting in all sorts of trouble (mainly centring around the fact that my this pointer gets trampled on). At first I thought there was something in ATL which stopped it from playing nicely with STL, but a nice person on this forum assured me that this is not the case. After a bit of shadow chasing, I think I've narrowed down the cause of the problem: the stack gets corrupted if I attempt to use a std::string (since the use of a std::string from the ATL code would presumably require a casting-type operation) in a call level deeper than two functions. That last bit was probably unintelligible (since I made that phrase up) so I'll attempt to illustrate my point with some code:
STDMETHODIMP SomeClass::SomeFunction ()
{
std::string tmp = "This is a std::string";
AnotherFunction();
}
void SomeClass::AnotherFunction ()
{
std::string tmp = "This is a std::string";
}
So if I were to drop a break point at the two std::string declarations, we have no problems when it runs through the first one (in SomeFunction) but as soon as it passes the second (in AnotherFunction), the this pointer gets corrupted ... almost as if the stack pointer got lost whilst trying to deal with the std::string.
I should add that I'm doing this on VC6.0.
Anyone ever seen this before? Anyway to get around it? It sucks having to replicate my code rather than being able to write it in a function and simply call that function everywhere I need to...
cheers!
|
|
|
|
|
Are you debugging in Debug mode or Release mode? If you are debugging in Release mode, have you set the optmization option to "Disable" ? With out this option, the watch window may display incorrect value for variables.
|
|
|
|
|
Never has any trouble using std:string s. Can you give more details? There's nothing in the code you posted that would cause stack corruption.
Steve
|
|
|
|
|
Thanks for your responses.
This is not a display problem, the this pointer *really* gets corrupted (the program crashes after awhile...).
Not sure how many more details I can offer apart from the fact that I am attempting to do this in the implementation of a public interface of a COM component; and that the original code is in ATL but the stuff I've added makes use of std::string . Obviously it could be something in the project settings which is setting this off; I'm not a 100% on compile flags etc. but I wouldn't have thought so..
|
|
|
|
|
Are you sure the problem is actually related to std::string ? It sounds to me as if the client of the COM object is calling an interface method through a bad or NULL this pointer. What is the value of the this pointer when it's corrupted?
Steve
|
|
|
|
|
I'm not a 100% that it is related to std::string of course but the evidence that I've seen so far (through the debugger) appears to point to that. So these are a set of sample values of the this pointer before and after corruption:
Before the std::string declaration: 0x01779408 (debugger tells me that it's pointing to a valid object, it has valid members etc)
In the constructor of the string: 0x0012f174
After the string has been constructed: 0x0012f18c (i.e. not null but not our original this pointer either)
I should have mentioned earlier (it has just entered my mind) that the project that I am working on makes use of STLPort and so the std::string is the STLPort std::string. Possibly could be a bug in STLPort...just not sure why it's occuring now for this particular project and not for the many, MANY other times when I've used std::string without even having to think about it...
|
|
|
|
|
Make sure you're not violating the One Definition Rule[^]. I suspect this as you said you're using STLPort. My guess is that you may not be using it contently across translations units (ie. using the default STL in some file or lib and using STLPort in another file or lib).
Steve
|
|
|
|
|
Possibly. At least I have a starting point with which to start looking into this now. Thanks!
|
|
|
|