|
i called function add and when i step in to add function
in watch window i see the above values against this pointer.
Regards,
Sandip.
|
|
|
|
|
Thanks Sandip,
You mean you step into the member function like foo and watch for "this" pointer?
regards,
George
|
|
|
|
|
George_George wrote: You mean you step into the member function like foo and watch for "this" pointer?
Yes..
Regards,
Sandip.
|
|
|
|
|
Hi Sandip,
I have tried but can not see the same thing.
Here is my situation. Do you know what is the problem?
when I watch this in function Foo::func, the Name/Value/Type in Watch window is
this 0x0012ff63 Foo * const
Here is the code I am using,
class Foo
{
public:
int func();
};
int Foo::func()
{
int a = 3;
return a;
}
class Goo
{
public:
int func();
};
int Goo::func()
{
int a = 3;
return a;
}
template < class T >
class Abc : public T
{
};
int main()
{
Abc < Foo > f;
Abc < Goo > g;
f.func();
g.func();
return 0;
}
regards,
George
|
|
|
|
|
Hi George,
That is because your class does not have RTTI.
That is the reason i derived my classes from CObject.
I hope it helps..
Regards,
Sandip.
|
|
|
|
|
Hi Sandip,
I think RTTI is the capability of runtime to discover the actual underlying type of variable pointed by some pointer. So, in short RTTI is some specific capability of runtime. What do you mean class does not have RTTI? Looks like you think RTTI is some capability of a class? Could you clarify please?
regards,
George
|
|
|
|
|
George_George wrote: So, in short RTTI is some specific capability of runtime.
and in MFC this is supported by CObject.
If you do not derive class using CObject it will not support RTTI.
In my application if i remove CObject it just gives me address just like you.
Does it help..
Regards,
Sandip.
modified on Monday, September 22, 2008 8:07 AM
|
|
|
|
|
Thanks Sandip!
I am not using MFC, any ways to display things like you showed below in a standard C++ project in VC?
this VFoo::?$abc
this VGoo::?$abc
regards,
George
|
|
|
|
|
Now I'm also pretty much sure (after having tested) that templates are name mangled. If you try to use extern 'c' for templates (class/functions), the compilier will flash an error saying 'error C2894: templates cannot be declared to have 'C' linkage'.
- Malli...!
|
|
|
|
|
Are there any ways to see the classes' after template instantiation/expansion, Malli_S?
regards,
George
|
|
|
|
|
I get this message when I run my application which is built on another computer:
This application failed to start because the application initializtion is incorrect.
?????
What?
|
|
|
|
|
Did you use VC2005 ? If yes, you have to download and install vcredist_x86.exe[^] on the target machine. This will install the MFC and C-runtime libraries. If you have installed the SP1 for VC, check at the bottom of the page for the SP1 version of VCredist_x86.
|
|
|
|
|
When right click my tray icon, show the menu, And there is a menu item "Restore window".
When click this menu item, it should restore window.
My code implement "Restore window" below:
void CWinSearchDlg::OnTrayRestoreWnd()
{
DestroyTray();
ShowWindow(SW_SHOW);
<font color="red">
::BringWindowToTop(this->GetSafeHwnd());
::SetForegroundWindow(this->GetSafeHwnd());
::SetActiveWindow(this->GetSafeHwnd());</font>
}
I've tried the code in red font, but when restore the window, It doesn't bring to the top.
Please give me a sign!
|
|
|
|
|
Try using CWnd::SetWindowPos
|
|
|
|
|
Thank for your reply first.
SetWindowPos Not Working too.
I even try to put them in different order.
Please do me a favor.
|
|
|
|
|
Did you check the return values for the above (Red colored) function calls ? The other possibility is that (if the functions return success), the window might have brought up to top, but your some other code might be changing the order again.
Or, calling SetForegroundWindow() before displaying your context menu might help you.
- Malli...!
|
|
|
|
|
I have a problem setting bg-text color of static control on one of my dialog
I try to set the bg-text color of every static control on my dialog by
overriding OnCtrlColor (ON_WM_CTLCOLOR) of that dilaog
HBRUSH CCAESDlg::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)
{
HBRUSH hbr = CDialog::OnCtlColor(pDC, pWnd, nCtlColor);
if(nCtlColor == CTLCOLOR_STATIC || nCtlColor == CTLCOLOR_DLG){
COLORREF color = RGB(255,225,255);
pDC->SetBkColor(color);
return (HBRUSH)GetStockObject(WHITE_BRUSH);
}
else{
return hbr;
}
}
this work fine for all of my dialog (10 of them).
But it doesn't work on one dialog,all the bg-text of every static control turn into pink.
even if i remove the if-else block from my code any force setting bg-text color of evey control on dialog to white color ,it still doesn't work.
declare & initialized the variable color as a class's member doesn't help either.
Does anyone know what the cause of this problem?
Thank in advance.
|
|
|
|
|
Did you make a Bursh and did you return it instead return hbr?
|
|
|
|
|
I return WHITE_BRUSH when the control is STATIC (as demonstrate in code)
Only the background part of the text which is setting
by calling pDC->SetBkColor doesn't work
I have those code in all of my dialog and it usually work,only one dialog that had the problem.
sorry for my bad english
|
|
|
|
|
Your code sets the background color to pink....
what color are you expecting?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
everyone, thank for your answer.
Actually,My code set the background color to white (color = RGB(255,255,255))
I managed to fixed the problem by changing the dialog's font in GUI editor from "Ms Dialog Shell" to "Microsoft San Serif".
This is very strange. I guess it somekind of very obscure bug.
|
|
|
|
|
Hi,
I'm trying to resolve a Manifest issue. Member 'enhzflep' suggested some time ago that mainifest XML Code does not have to be included in the exe, but that it can be added as a separate XML file (MyProg.exe.Manifest) as an afterthought, rather than compiling it into the code.
I Proposed the following for an exe called Softguard Utility Program.
As soon as the Windows Loader sees this Manifest, it balks with Win32 error 140001. If I rename the exe file, it runs.
I'm doing at least something right in that the Windows Loader responds. The question is, What's wrong with the XML Code that makes the loader
balk. Better, How do I debug this issue. The Loader fails before the Debugger Starts.
Contents of MyProg.Exe.manifest
<pre><code><?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity version="1.0.0.0"
processorArchitecture="X86"
name="SgBackup"
type="win32"/>
<description>Softguard Utility Program</description>
<!-- Softguard Utility Program -->
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2>
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="requireAdministrator"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly></code></pre>
thanks
Bram van Kampen
|
|
|
|
|
Hi Bram. Sorry to hear this is still giving you trouble.
I also just tried that manifest file with an app of mine and received an error on loading.
Here's one that I use, as generated by the ANSI version of ResEdit. ResEdit home[^]
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="X86"
name="CompanyName.ProductName.YourApp"
type="win32"
/>
<description>Your application description here.</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
</assembly>
Another useful utility for manifests is: XP Style Hacker: http://www.snapfiles.com/get/xpstylehack.html[^]
|
|
|
|
|
Taking all this on board.
BTW Could there be restrictions on the loader to stop inappropriate behaviour e.g. hacking, if the manifest asks for elevated status on a further non specified program module ?
Bram van Kampen
|
|
|
|
|
Pleasure.
Not really too sure what the problem is with that XML file, though on looking at this one I have here, I notice that you only have 1 pair of assemblyIdentity tags - I'm leaning away from it being a privilege escalation problem, but more towards the manifest being improperly formed.
Just found a blog that discusses manifests a little. I've tried the first one fro the page and it works fine. I then changed the requestedExecutionLevel to level="requireAdministrator", it still seems fine. Though I can run it with a guest account on xp - I don't know if this is the expected behaviour or not.
Here's the blog I mentioned:
http://blogs.msdn.com/cjacks/archive/2006/09/08/745729.aspx[^]
Here's the 1st manifest from that page:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity type="win32" processorArchitecture="*" version="1.0.0.0" name="MyApplication.exe"/>
<description>My totally awesome application</description>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" language="*" processorArchitecture="*" publicKeyToken="6595b64144ccf1df" />
</dependentAssembly>
</dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
Good luck.
|
|
|
|