|
Hi,
From VS2003 the MFC (or ATL) CString classes are specializations of CStringT : see http://msdn.microsoft.com/en-us/library/5bzxfsea(VS.71).aspx[^]
Explicitly use CStringW for your framework related code and CStringA for interaction with your DLL.
cheers,
AR
When the wise (person) points at the moon the fool looks at the finger (Chinese proverb)
|
|
|
|
|
Hi,
I am sure the "file.exe" is not running. But when I tried to re-build the exe file. VS 2008 gives this error.
Please help.
Thanks,
|
|
|
|
|
can you rename the file? if not, it is locked by some process.
can you delete the file? if so, doing that could solve it.
|
|
|
|
|
Yes, I can rename and delete it. But it is painful to delete the EXE file for every build.
Do you have any other solution?
I guess it is caused by the windows 7 security.
Thanks,
|
|
|
|
|
I haven't encountered such situation on Win7 yet. If you can delete it, the EXE isn't executing any more (as it would when you had some non-main thread that goes on while not being marked background).
Here is one work-around idea: add a pre-build step to your Visual project, deleting the EXE with a DOS-like command, which you enter somewhere in the project's settings dialog.
|
|
|
|
|
I'm now coding with VC++2008.
I wanna show 2 dialogs at the same time.
So how to achieve it?
Thanks in advance.
In fact I've tried the following:
BOOL CDlg1::OnInitDialog()
{
...
dlg2.Create(IDD_DIALOG2, this);
dlg2.ShowWindow(SW_SHOW);
...
}
But this doesn't work.
|
|
|
|
|
|
A dialog, i.e. a window shown as modal, by definition is unique within a process, as it grabs you, your mouse and keyboard until you dismiss it.
If you want two dialogs, you need two processes.
Or you switch to modeless windows, which aren't dialogs at all. But then other forms of the same process could also be brought to the foreground and operated on.
|
|
|
|
|
Luc Pattyn wrote: If you want two dialogs, you need two processes.
This isn't true. It's possible and quite common for a modal dialog to have a button (or some other mechanism) which brings up another "nested" (not nested in a parent-child sense) modal dialog. Both dialogs are modal and shown at the same time although while the nested one exists the parent one is disabled.
Steve
|
|
|
|
|
You're right of course, however that still leaves only one accessible dialog, not what the OP wants.
|
|
|
|
|
define dlg2 as a member varibale of CDlg1.
CDlg2 * m_pDlg2;
BOOL CDlg1::OnInitDialog()
{
m_pDlg2 = new CDlg2();
m_pDlg2->Create(IDD_DIALOG2, this);
m_pDlg2->ShowWindow(SW_SHOW);
}
void CDlg1::OnDestroy()
{
CDialog::OnDestroy();
if(m_pDlg2)
delete m_pDlg2;
m_pDlg2 = NULL;
}
modified on Thursday, October 28, 2010 4:17 AM
|
|
|
|
|
Why bother using new and delete and the pointer m_pDlg2 ? In general I'd lose the new and delete (and in this case the OnDestroy handler too) and embed CDlg2 directly:
class CDlg1 :
{
CDlg2 m_Dlg2;
};
BOOL CDlg1::OnShowOtherDialog()
{
m_Dlg2.Create(IDD_DIALOG2, this);
m_Dlg2.ShowWindow(SW_SHOW);
}
Steve
|
|
|
|
|
Good advice,
en,, I prefer to use pointer..
|
|
|
|
|
I prefer to avoid using the heap when it's not necessary: It's faster, safer and helps minimise heap fragmentation.
Steve
|
|
|
|
|
If you don't need 2 dialogs at the same time but you need
them both displayable, then you're speaking about something like
a tabbed dialog: each tab will show a dialog.
I've a sample of doing this at the demo app that is in the article A Standard Multithreaded Dynamic Queue.
Otherwise you want to investigate modeless dialogs.
|
|
|
|
|
Hi,
for those who know 'WinRar', when you select a file which has been compressed and right click and select Properties > Archive, you get a nice column showing the compression Ratio in %.
Can someone provide a URL to a sample that implements such a type of column bar? I need such column bar for a Ratio representation in an MFC-based app (aka. C++ based-app, NO .NET).
Thanks in advance for any hint.
Marc
|
|
|
|
|
I don't have WinRar installed but just an idea: use Spy++ to find out the class of that control and then try googling it up, maybe it turn up something usefull...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Leela: Fry, you're wasting your life sitting in front of that TV. You need to get out and see the real world.
Fry: But this is HDTV. It's got better resolution than the real world <
|
|
|
|
|
It shows in the property window of compressed files.
So it must be a shell extension.
You may not be able to get to pick only the control out with spy.
It may not even be a control.
It could be simply drawn.
You never know.
|
|
|
|
|
|
|
«_Superman_» wrote: You never know.
...unless you try. Was just an idea, maybe it works, maybe it does not.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Leela: Fry, you're wasting your life sitting in front of that TV. You need to get out and see the real world.
Fry: But this is HDTV. It's got better resolution than the real world <
|
|
|
|
|
very good idea. Thanks. I have tried with Spy++ and it is NOT an OCX control, it is pure drawing functions. This IS the kind of Drawing functions I am looking for!
modified on Thursday, October 28, 2010 1:44 AM
|
|
|
|
|
I have a button that I want an image in, a basic colour swatch. I liked the idea of having a partially transparent shadow around it, so in GIMP, I created a 32 bit BMP with the desired alpha shadow, and a white, totally non-transparent square in the middle. The intention was to fill the white area in with the colour that the user chooses. Sounds simple enough. So, the basic code is such:
HDC hDC;
HANDLE hOldBmp;
HBRUSH hBrush;
LOGBRUSH zLogBrush;
HBITMAP hColourShadowBmp_ = ::LoadBitmap( hInst, MAKEINTRESOURCE(IDB_COLOUR_SHADOW) );
zLogBrush.lbStyle = BS_SOLID;
zLogBrush.lbColor = RGB( m_Props.uiRed, m_Props.uiGreen, m_Props.uiBlue );
zLogBrush.lbHatch = NULL;
hBrush = ::CreateBrushIndirect( &zLogBrush );
CImage zFinalImage;
CImage zSwatchImage;
zFinalImage.Attach( hColourShadowBmp_ );
zSwatchImage.Create( 20, 20, 24 );
hDC = zSwatchImage.GetDC();
::SelectObject( hDC, hBrush );
::Rectangle( hDC, 0, 0, 20, 20 );
zSwatchImage.ReleaseDC();
hDC = zFinalImage.GetDC();
zSwatchImage.AlphaBlend( hDC, 2, 2, 255 );
zFinalImage.ReleaseDC();
hOldBmp = (HANDLE)
::SendMessage( ::GetDlgItem( m_hWnd, IDC_COLOUR ),
BM_SETIMAGE,
(WPARAM)IMAGE_BITMAP,
(LPARAM)zFinalImage.Detach() );
::DeleteObject( hBrush );
All I end up with is the source shadow image, with a lovely fully transparent square where the swatch should be. I know the swatch painting is working, as I can send that image and get the colour square I expect.
Yet nothing I do seems to be able to make the colours get transferred. Crazily enough, the alpha is, if I set the alpha in the AlphaBlend() call to 0, I get the original shadow image unchanged. So I know that it is modifying the alpha channel properly at least. The source is opaque, so no amount of pre-multiplying will help.
FWIW, I also tried making the zSwatchImage a 32 bit with alpha, but it made no difference.
The only solution I can see now is jumping into the bits for the shadow image and changing the RGB values to what I want.
But surely I'm doing something wrong? It's hard to believe that a simply blend like this fails.
Thanks,
CraigL
|
|
|
|
|
Don't be surprised, GDI drawing methods zero out the aplha channel. When you call Rectangle it "makes a hole" in your alpha channel. Use GDI+ or fill the pixels by writing memory directly.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Leela: Fry, you're wasting your life sitting in front of that TV. You need to get out and see the real world.
Fry: But this is HDTV. It's got better resolution than the real world <
|
|
|
|
|
I can see that being a problem if I had an alpha channel in the zSwatchImage . And at one point I did, so I guess I'd expect the behaviour I saw.
But it's absurd to me that an "alpha blend" function can't take a 24bit image and "do the right thing" by copying it will the alpha channel opaque. Especially when you TELL it what the alpha value to copy with should be. If it isn't there, you'd think it would use the alpha provided as the source alpha, not just the blend alpha. But to take a 24bit image and assume the alpha is zero?
And, I had thought that CImage did use GDI+, so the 24 -> 32 bpp copy would make sense.
I guess I just expect too much from CImage .
Course, now I'm having fun trying to get the bits directly from a BMP loaded via ::LoadBitmap ... I guess graphics never really was a win32 strong point.
Thanks for the reply. Normally, I totally exclude win32 APIs wrt image handling, just needed the BMP to use the easy way one can put it on a button. This exercise has just cinched that opinion even more =)
|
|
|
|