|
|
I'm trying to derive from CMFCPropertyGridColorProperty and cannot override the virtual function because my derived class is not a friend of CMFCPropertyGridCtrl.
Here is a minimal representation of the problem.
class CMFCPropertyGridCtrl
{
friend class CMFCPropertyGridColorProperty;
protected:
CRect m_rectList; };
class CMFCPropertyGridColorProperty
{
friend class CMFCPropertyGridCtrl;
public:
virtual void AdjustInPlaceEditRect(CRect& rectEdit, CRect& rectSpin);
protected:
CMFCPropertyGridCtrl* m_pWndList;
};
void CMFCPropertyGridColorProperty::AdjustInPlaceEditRect(CRect& rectEdit, CRect& rectSpin)
{
m_pWndList->m_rectList.left += 20;
}
class MyPropertyGrid : public CMFCPropertyGridColorProperty
{
virtual void AdjustInPlaceEditRect(CRect& rectEdit, CRect& rectSpin);
};
void MyPropertyGrid::AdjustInPlaceEditRect(CRect& rectEdit, CRect& rectSpin)
{
m_pWndList->m_rectList.left += 40; }
trying to compile this, I get the following understandable error :
error C2248: 'CMFCPropertyGridCtrl::m_rectList' : cannot access protected member declared in class 'CMFCPropertyGridCtrl'
1> d:\projects\testfriend\testfriend\testfriend.cpp(21) : see declaration of 'CMFCPropertyGridCtrl::m_rectList'
1> d:\projects\testfriend\testfriend\testfriend.cpp(17) : see declaration of 'CMFCPropertyGridCtrl'
---
I'd like to be able to override the method
virtual void AdjustInPlaceEditRect(CRect& rectEdit, CRect& rectSpin);
void CMFCPropertyGridColorProperty::AdjustInPlaceEditRect(CRect& rectEdit, CRect& rectSpin)
{
ASSERT_VALID(this);
ASSERT_VALID(m_pWndList);
rectSpin.SetRectEmpty();
rectEdit = m_Rect;
rectEdit.DeflateRect(0, 2);
int nMargin = m_pWndList->m_bMarkModifiedProperties && m_bIsModified ? m_pWndList->m_nBoldEditLeftMargin : m_pWndList->m_nEditLeftMargin;
rectEdit.left = m_pWndList->m_rectList.left + m_pWndList->m_nLeftColumnWidth + m_Rect.Height() + AFX_TEXT_MARGIN - nMargin + 1;
AdjustButtonRect();
rectEdit.right = m_rectButton.left;
}
To change the edit box position in the CMFCPropertyGridColorProperty class; but since I do not have access to the CMFCPropertyGridCtrl class (via m_pWndList), I cannot really override it.
Any hints/tips or something else that I might have missed?
Thanks.
Max.
I'd rather be phishing!
|
|
|
|
|
Why don't you inherit from both classes?
Veni, vidi, vici.
|
|
|
|
|
YUCK!!!
A colleague offered the same suggestion.
I tried and it works... but I do not really like it.
I'd rather be phishing!
|
|
|
|
|
Maximilien wrote: I tried and it works... but I do not really like it.
You will love multiple inheritance. 
Veni, vidi, vici.
|
|
|
|
|
Yeah, but ultimately it does not work.
I cannot inherit from both CMFCPropertyGridColorProperty and CMFCPropertyGridCtrl.
The CMFCPropertyGridCtrl is a UI container class containing instances of CMFCPropertyGridProperty.
the CMFCPropertyGridCtrl is constructed before the CMFCPropertyGridProperty are constructed; and if I multiple inherit from CMFCPropertyGridCtrl , there will be 2 "instances" of the class and there should be only one.
I'm still working on something.
I'd rather be phishing!
|
|
|
|
|
You could make a class inheriting from CMFCPropertyGridCtrl, say MaximilenMFCPropertyGridCtrl which only purpose is being a good friend of MyPropertyGrid.
Veni, vidi, vici.
|
|
|
|
|
Hello. I am trying to write some wave data into pcm file. I pass this data and its length to the write function but it raises this exception An unknown error occurred while accessing file ..... file path + name ....
I am using following line code to open this file and write contents into it
CFile* pFile = new CFile;
pFile->Open("Output.pcm", CFile::modeCreate|modeReadWrite);
pFile->Write((void*)pData, dwLength);
pFile->Close();
What could be wrong here? Thanks for any input.
This world is going to explode due to international politics, SOON.
|
|
|
|
|
Why didn't you check Open return value (see, for instance, the documentation[^])?
Veni, vidi, vici.
|
|
|
|
|
File opens successfully. It is the Write() function that is raising this exception.
This world is going to explode due to international politics, SOON.
|
|
|
|
|
Since the exception is "An unknown error occurred while accessing file ",
Do you still get errors with the unicode syntax _T( ) , e.g CFile file (_T ("File.txt"), CFile::modeReadWrite) );
CFile file;
CFileException e;
if (file.Open (_T ("File.txt"), CFile::modeReadWrite, &e)) {
}
else {
e.ReportError ();
}
|
|
|
|
|
The file opens successfully. The problem occurs when I try to write something using it. Please see me code again, I have commented it there as well.
This world is going to explode due to international politics, SOON.
|
|
|
|
|
The error should be obvious, the inners of write look like this..
virtual void Write(
const void* lpBuf,
UINT nCount
);
Parameters
lpBuf - A pointer to the user-supplied buffer that contains the data to be written to the file.
nCount - The number of bytes to be transferred from the buffer. For text-mode files, carriage return–linefeed pairs are counted as single characters.
Official MSDN example:
CFile cfile;
cfile.Open(_T("Write_File.dat"), CFile::modeCreate | CFile::modeReadWrite);
char pbufWrite[100];
memset(pbufWrite, 'a', sizeof(pbufWrite));
cfile.Write(pbufWrite, 100);
cfile.Flush();
http://msdn.microsoft.com/en-us/library/esb6sz20.aspx[^]
|
|
|
|
|
AmbiguousName wrote: The file opens successfully.
How can you be sure of that, since you do not check the return status?
|
|
|
|
|
Supercoder has given you the most likely answer although I agree with Richard you haven't conclusively shown the file is open.
If the file doesn't exist you could have a problem because you probably need to open it with
CFile::modeCreate | CFile::modeReadWrite
Stick a debug point on the fail case and check.
For the write you have a single line
=> pFile->Write((void*)pData, dwLength);
Either
1.) pData is not a pointer to an actual array of data
2.) dwLength has not been set or exceeds the data in pData
So all you have to do is work out which of the three things you got wrong and fix it.
If you can't fix it we need to see how you defined pData and where you set dwLength probably.
In vino veritas
modified 15-May-14 10:36am.
|
|
|
|
|
include wchar.h and try
WCHAR* pData = L"Testing Data";
DWORD dwLength = wcslen(pData);
CFile* pFile = new CFile;
pFile->Open(L"Output.pcm, CFile::modeCreate | CFile::modeReadWrite);
pFile->Write((void*)pData, dwLength * sizeof(WCHAR)); // exception raised here
pFile->Close();
|
|
|
|
|
I am trying to use VTK library into an MFC project ... I had do everything to can compile my project, (add headers and library files to my project), but when I try to run the program, I get follow error:
The program can't start because vtkRenderingCore-1.6.dll is missing from your computer
but I alreay use vtkRenderingCore-1.6.lib file (and his header), why do I need dll file ?
I had used another library once upon a time(PDFlib), but then I had used just header file, and library file ...
So, the question is, do I need a dll file if I am using library (and header file) inside the project ?
|
|
|
|
|
Compiled libraries come in 2 flavors - static libraries and dynamic libraries.
Static libraries are in the form of a .LIB file and dynamic libraries are in the form of a .DLL file.
A .DLL file can also have an associated .LIB file. But this .LIB file only contains the exported function signatures and the name of the .DLL file.
It does not contain any code.
During runtime, the DLL file will be searched in specific folders as mentioned here - Dynamic-Link Library Search Order[^]
«_Superman_»
I love work. It gives me something to do between weekends.
Microsoft MVP (Visual C++) (October 2009 - September 2013) Polymorphism in C
|
|
|
|
|
I want to know the details of linker,do you have any suggestion?
|
|
|
|
|
Superman allready explained in his answer that in general there are two types of libaries (static and dynamic or also called shared libraries).
Now when using VTK you can choose if you would like to use the static libraries or the dynamic ones. Assuming you did build VTK yourself in the CMake configuration you'll have to set the option BUILD_SHARED_LIBS=OFF.
This way VTK will be build as static libraries.
|
|
|
|
|
Yes, that I already done it ... but still, I am not able to compile an MFC project with VTK, just console applications that had VTK inside ...  I am still digging ....
|
|
|
|
|
Do you have problems compiling or linking? Because before you were talking about libraries and they only come into play afer you successfully compiled your pogram and now your telling that you have problems compiling.
|
|
|
|
|
Regor, kindly thank you. I am trying to compile their SampleMFC project, that has following CMakeList.txt:
cmake_minimum_required(VERSION 2.8)
PROJECT(Win32SampleMFC)
FIND_PACKAGE(VTK)
IF(NOT VTK_DIR)
MESSAGE(FATAL_ERROR "Please set VTK_DIR.")
ENDIF(NOT VTK_DIR)
INCLUDE(${VTK_USE_FILE})
# This VTK_DIR usage only works in the VTK build tree...
# Make it work in the "make install" tree, too.
#
INCLUDE("${VTK_DIR}/GUISupport/MFC/VTKMFCSettings.cmake")
IF(VTK_MFC_DELAYLOAD_VTK_DLLS)
VTK_MFC_ADD_DELAYLOAD_FLAGS(CMAKE_EXE_LINKER_FLAGS
vtkRendering.dll
vtkIO.dll
vtkFiltering.dll
vtkCommon.dll
)
ENDIF(VTK_MFC_DELAYLOAD_VTK_DLLS)
SET(SRCS
ChildFrm.cpp
MainFrm.cpp
Sample.cpp
Sample.rc
SampleDoc.cpp
SampleView.cpp
StdAfx.cpp
vtkMFCDocument.cpp
vtkMFCRenderView.cpp
vtkMFCView.cpp
res/Sample.rc2
)
ADD_EXECUTABLE(Win32SampleMFC WIN32 ${SRCS})
IF(VTK_MFC_EXTRA_LIBS)
TARGET_LINK_LIBRARIES(Win32SampleMFC ${VTK_MFC_EXTRA_LIBS})
ENDIF(VTK_MFC_EXTRA_LIBS)
TARGET_LINK_LIBRARIES(Win32SampleMFC vtkRendering)
well, in VTK, version 6, I didn't have
<br />
vtkRendering.dll<br />
vtkIO.dll<br />
vtkFiltering.dll<br />
vtkCommon.dll<br />
and I don't know how to adapt CMakeList.txt in order to compile the project ...
and I got linking error:
fatal error LNK1104: cannot open file 'vtkRendering.lib'
Also, I didn't have any vtkRendering.lib, just vtkRenderingCore-6.1.lib
Any help that you give, will be very appreciated !
|
|
|
|
|
Yes in VTK version 6 the naming convention for the libraries was changed. It is now part of the lib name, that is why you have a vtkRenderingCore-6.1.lib instead of vtkRendering.lib. It seems those changes did not make it in the cmake files of the example you're trying to use. Anyway when using cmake you shouldnt care about the concrete names of the libs since this is handled by the cmake configuration. I can show you how I succesfully link VTK 6.1 to one of my projects:
# Try to automatically detect VTK.
find_package(VTK REQUIRED COMPONENTS vtkIOGeometry vtkIOLegacy vtkFiltersCore)
if(VTK_FOUND)
message(STATUS "Found package VTK. Using " ${VTK_USE_FILE})
include(${VTK_USE_FILE})
else(VTK_FOUND)
message(FATAL_ERROR "VTK not found. Please set VTK_DIR.")
endif(VTK_FOUND)
target_link_libraries(myTarget ${VTK_LIBRARIES})
In your place I would start trying to build a basic VTK project (Hello World etc.) at first to see if this works. If you got this you can start to add simple MFC functionality.
I did not use MFC with VTK myself so sadly I cannot share any experience about this combination.
|
|
|
|
|
Ok, thank you, right now I should leave the office, but tomorrow I will write you what I have done ... see you soon. 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
