|
 after I finished a dialogue template ,I want to build the class "CMyDlg" of the dialogue template ,but the problem arised: Unable to open the files (D:\ly\CMyDlg.h,D:\ly\CMyDlg.cpp)for class "CMyDlg" . Who can tell me why? thanks!
|
|
|
|
|
This is not an uncommon message from ClassWizard. I get it about 30% of the time when creating a new class. To ensure that your class gets properly added to the project, exit the IDE, delete the temporary files (e.g., .opt, .ncb, .aps, .clw) , and re-open the project. The next time you invoke ClassWizard (Ctrl+W), all should be well.
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
thank you, I get it. but why ? Is that vc's bug?
|
|
|
|
|
Yes, it is a bug. I see the same thing happen on all my systems (about 5 current - many in the past). Does not seem to matter what OS or if virus scanner, spybot scanner, firewall, etc. are installed and running or not.
|
|
|
|
|
I really need the email address of Allan Nielsen who is the author of the article "SuperGrid"
|
|
|
|
|
|
Hi, I am having a strange issue with StretchDIBits on Win2000 Server and multi-monitor. If the primary monitor is smaller then the secondary, and it is at the bottom.
When using StretchDIBits and goto PrintPreview I initially get a large white unpainted area in the preview window. The non-white part appears to be the same depth as the primary monitors height. Now if I invalidate the white parts, drag some other app over it, it now paints the invalidated white part with the correct bit of the image. Minimise then Restore the white part is back.
If I try using SetDIBitsToDevice this works without any white bits. But I must use StretchDIBits.
I have tried a number of other apps and if they use StretchDIBits, they also have issues.
Anyone got any thoughts
Cheers
Jason Carter
|
|
|
|
|
Just an idea here...
Perhaps the StrechDIBits is internally limiting itself to the coordinates of the initial device resolution?
Instead, maybe you can try this...
Create a memory DC the size of the combined monitors.
Perform the StrechDIBits into the memory DC
Copy the memoy DC image to the 'virtual' DC of the combined monitors.
|
|
|
|
|
Great idea, we already do this code for double buffered screen drawing code. I have already tried to modify this. But we still get the same problem. I am also trying to use the good old MFC Sample DIBLook and this also suffers the same problem.
"Create a memory DC the size of the combined monitors"
Do you mean a CreateCompatibleDC(pDC)?
|
|
|
|
|
Yes, and I reiterate this is what I would 'try' since I have not solved this problem before either.. 
A memory DC exists only in memory. When the memory DC is created, its display surface is exactly one monochrome pixel wide and one monochrome pixel high. Before an application can use a memory DC for drawing operations, it must select a bitmap of the correct width and height into the DC. To select a bitmap into a DC, use the CreateCompatibleBitmap function, specifying the height, width, and color organization required.
You might need to CreateCompatibleDC() then CreateCompatibleBitmap() (this bitmap is just to force the compatible DC into the correct color depth and dimensions). Then perform your StretchDIBits into the 'compatible' DC. If you are lucky follow all that with a single copy operation of this compatible DC to one representing the entire 'screen' (across the two monitors), otherwise, you will need two copy operations, one targeting the DC of each monitor.
|
|
|
|
|
We already use this method for flicker free screen rendering (double buffering). We did not use the double buffering for printer DC. I have now tried this double buffering for a print preview DC and the problem still exists.
Looks like a Microsoft bug report time.
Thanks for you thoughts
|
|
|
|
|
How can i change the color of the title bar of my dialog/sdi/mdi. I dont want to use a seperate class for this purpose.
|
|
|
|
|
Hello Wasif
As far as i know color of the title bar of any window is decided by the currently applied theme or selected color in the "Appearence" Tab of "Display properties" System dialog.
i guess by some way or other if you could get that system Dialog and change these settings programatically but doing this will change title color of all windows. or you could also try to search about HTHEME in MSDN
any ways i hope u will get some clue from this message and will start thinking in a different direction.
All the best
Muhammad Azam
1st Semester M.Engg
NED UET
|
|
|
|
|
As mentioned by Muhammed, the Title bar colour is determined by
your current colour scheme. If you want to create your own unique title bar window, you probably have to handle the drawing yourself.
This would probably involve handing
the WM_NCPAINT message. I don't think there is any lightweight solution to your request, but if you still want to pursue that idea, there are a few articles on CP about creating custom windows title bars.
I Dream of Absolute Zero
|
|
|
|
|
|
Hi, all
I'm adding items to the list control:
for (i = 0; i < pDoc->GetSize(); i++)
{
LV_ITEM lvi;
CMovieData* pMovie = pDoc->GetMovie (i);
lvi.mask = LVIF_TEXT | LVIF_PARAM;
lvi.iItem = i;
lvi.iSubItem = 0;
lvi.pszText = new TCHAR[]; // this line is 63
_tcscpy (lvi.pszText, pMovie->Name);
movList.InsertItem (&lvi);
lvi.mask = LVIF_TEXT;
lvi.iImage = i;
lvi.iSubItem = 1;
_tcscpy (lvi.pszText, pMovie->GetGenre());
movList.SetItem (&lvi);
}
After program stopping I get a message:
Detected memory leaks!
Dumping objects ->
d:\temp\projects\movies\moviesview.cpp(63) : {334} normal block at 0x00376190, 0 bytes long.
Data: <>
d:\temp\projects\movies\moviesview.cpp(63) : {333} normal block at 0x00379DD0, 0 bytes long.
Data: <>
{90} normal block at 0x00372D10, 24 bytes long.
Data: < 2| > D8 9C 32 7C 07 00 00 00 07 00 00 00 01 00 00 00
d:\temp\projects\movies\moviesdoc.cpp(44) : {87} normal block at 0x00372848, 4 bytes long.
Data: < -7 > 20 2D 37 00
Object dump complete.
The 63 line I've marked. Is it possible to delete in some way the strings? Thanks.
|
|
|
|
|
The pszText variable only requires the pointer to your displayed string. Because you are already storing the textual information in your document, you only need to set this variable to your string array.
Try this:
for (i = 0; i < pDoc->GetSize(); i++)
{
CMovieData* pMovie = pDoc->GetMovie(i);
LV_ITEM lvi;
lvi.mask = LVIF_TEXT | LVIF_PARAM;
lvi.iItem = i;
lvi.iSubItem = 0;
<font color=red> lvi.pszText = (LPCTSTR)pMovie->Name;</font>
lvi.iImage = i;
int pos = movList.InsertItem (&lvi);
movList.SetItem(pos, 1, (LPCTSTR)pMovie->GetGenre());
}
[EDIT]
This will eliminate the need to create unmanaged memory allocation which resulted in your memory leaks.
[/EDIT]
I Dream of Absolute Zero
|
|
|
|
|
for (i = 0; i < pDoc->GetSize(); i++)
{
CMovieData* pMovie = pDoc->GetMovie (i);
LV_ITEM lvi;
lvi.mask = LVIF_TEXT | LVIF_PARAM;
lvi.iItem = i;
lvi.iSubItem = 0;
lvi.pszText = (LPCTSTR) pMovie->Name;
//_tcscpy (lvi.pszText, pMovie->Name);
movList.InsertItem (&lvi);
}
d:\Temp\PROJECTS\Movies\MoviesView.cpp(63) : error C2440: '=' : cannot convert from 'ATL::CSimpleStringT::PCXSTR' to 'LPSTR'
with
[
BaseType=char,
t_bMFCDLL=true
]
Conversion loses qualifiers
|
|
|
|
|
In this case, you will need to get a pointer to the underlying string array.
One suggestion would be:
..
lvi.pszText = pMovie->Name.GetBuffer(0);
pMovie->Name.ReleaseBuffer();
..
I Dream of Absolute Zero
|
|
|
|
|
(LPTSTR) (LPCTSTR) pMovie ->Name
That also works well to get around the limitations of the structure definition.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
how do i add arabic language in menu? 
using vc++ 6.............
thanks ahead!
|
|
|
|
|
Just Enable UNICODE support in your application by using these macro
#ifndef UNICODE
#define UNICODE
#endif
these macro will enable the UNICODE SUPPORT In your application and with help of UNICODE charater set you can easily USE arabic in your APPLICATION.
"I Think this Will Help"
[Vote One Here,.....]
<h5
alok gupta="" <br=""> visit me at http://www.thisisalok.tk
|
|
|
|
|
I`m building a MDI application. I couldn`t iterate through the views. I use :
POSITION pos = CFileManDoc::GetFirstViewPosition();<br />
while (pos != NULL)<br />
{<br />
CFileManView* pView = (CFileManView*) CFileManDoc::GetNextView(pos);<br />
ASSERT_VALID(pView);<br />
pView->GetWindowText(strText);<br />
AfxMessageBox(strText);<br />
}
It only went to the active view. Any idea?
<italic>Work hard and a bit of luck is the key to success. You don`t need to be genius, to be rich.
|
|
|
|
|
Is it possible that an app is called MDI because it is a multiple DOCUMENT Interface 
However, I think that each of your documents only has one view associated with it, unless you are certain you opened up multiple VIEWS on each document.
You need nested loops to get all views in the program...
Firstly, use CWinApp::GetFirstDocTemplatePosition to get first document template position in the program, and iterate each of the found document templates.
Secondly, use CDocTemplate::GetFirstDocPosition to get first document of the currently iterated document template, and iterate all the documents associated with the currently iterated doeument template.
Thirdly, use CDocument::GetFirstViewPosition to begin iteration of each view associated with the currently iterated document.
In this way, you will get a pointer to each 'view' in your MDI program.
|
|
|
|
|
Blake Miller wrote:
unless you are certain you opened up multiple VIEWS on each document.
I`m certain. I really don`t know what went wrong.
<italic>Work hard and a bit of luck is the key to success. You don`t need to be genius, to be rich.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
