|
I have written 2 articles that cover this. One just does what you want, the other if a big extension of it:
Doc/View from dll[^]
Plug-In Architecture[^]
The first covers your immediate problem. The seconds allows future expansion to yuo application as well.
Roger Allen
Sonork 100.10016
In case you're worried about what's going to become of the younger generation, it's going to grow up and start worrying about the younger generation. - Roger Allen, but not me!
|
|
|
|
|
I would suggest that you rename your DLL's CChildFrm derived class to something different so that you can check that it is creating the type from the DLL. In all the projects I have done using this method, I have never had a specialised child frame in a DLL so far, but I wouldn't expect it to be a problem, as the document / view class's are being created correctly form the RUNTIME_CLASS information.
Sorry, I can't be of any more help in this one.
Roger Allen
Sonork 100.10016
In case you're worried about what's going to become of the younger generation, it's going to grow up and start worrying about the younger generation. - Roger Allen, but not me!
|
|
|
|
|
hi everyone,
i'm working on a sdi application with window's explorer style(i.e. a
sdi application with a vertical splitter, dividing the windows into 2
panes, left and right pane).
i added a command, named 'add info', to the main menu and added the event handler to 'add info'. the coding of the event handler of 'add info'
command is done in left pane class. what 'add info' command do is creating a dialog that collects inputs from users then store these user inputs into a database. i modified the contructor of the dialog for 'add info' to accept a database object pointer(get past from the left pane class, when the dialog object is created).
when i start the program, if the windows focus in on left pane, i was able to run 'add info' command, display the dialog, save the inputs from the dialog and store in the database without any problem.
the problem occurs when my window focus is on right pane, if i run
'add info', i get error 'Unhandled exception at 0x005832ba in myapp.exe: 0xC0000005: Access violation reading location 0x61636f4c.'
and the debugger points out that the program crashes at line 44 in objcore.cpp, within the function iskindof(.....)..
here is the function..
BOOL CObject::IsKindOf(const CRuntimeClass* pClass) const
{
ASSERT(this != NULL);
// it better be in valid memory, at least for CObject size
ASSERT(AfxIsValidAddress(this, sizeof(CObject)));
// simple SI case
CRuntimeClass* pClassThis = GetRuntimeClass();
return pClassThis->IsDerivedFrom(pClass);
}
after doing several tests, i found out that it was the database pointer, that get past from the left pane class to the dialog class, causing the problem.. strangely, the pointer doesn't cause any problem with left pane, but causing problems with right pane.. does anyone have any suggestion on fixing this?
thx in advance.
|
|
|
|
|
I have a question about how UNICODE relates to BSTR.
Are each character in a BSTR a UNICODE character code or are they Microsoft specific mappings against UNICODE?
--
This space for rent.
|
|
|
|
|
With WIN32 BSTR and UNICODE are MOSTLY the same thing. BSTR has the length stored with it and must be allocated and freed using a special routine. But the actual characters in the two strings can be treated the same.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
I knew about the length field in BSTRs and all the other stuff that comes with it. The docs claim that BSTR supports UNICODE, but it never claims that it truly *is* UNICODE. Knowing Microsoft, I wouldn't be surprised if characters between 0x7FFF and 0x10000 are treated in a "very special way".
Do you know how UTF-8 is related to UNICODE? I see that most XML-documents are encoded using UTF-8 which to me looks like ordinary ASCII. I've also seen UTF-8 mentioned together with UNICODE. Do you know a good reference (preferably online) on character encoding? I've tried to ignore all this, but we're getting closer to a reality where wchar_t is the character type of choice and char is just a legacy character type, mainly used for 8 bit integers...
--
This space for rent.
|
|
|
|
|
In Win32, a BSTR contains UCS-2 (also called UTF-16 or just plain Unicode) characters, nothing else.
UTF-8 is an encoding scheme to encode UCS-2 values into multi-byte characters so that the most common chars, 0-127, still only take up one byte each. That's why UTF-8 looks like ASCII in most cases. 
--Mike--
"Adventure. Excitement. A Jedi craves not these things."
-- Silent Bob
1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
As Michael already said, BSTRs contain straight UTF-16; no tricks and not UTF-8. However, it is possible to fill a BSTR with any binary data, and there is even SysAllocStringByteLen() to do just that (I've seen and used it in COM programming), and SysStringByteLen() to determine the size in bytes. Nevertheless, it is rare that this is done anymore, and if a BSTR is expected to contain a string, especially if documented, it will be UTF-16.
Cheers
|
|
|
|
|
After beginning my job of code-review, I have noticed an almost equal number of people on my team using each one.
Does anyone have any good arguments one way or the other?
When creating a class do you use enums like CFile::modeWrite...
or #defined values #define WRITE 3?
Thanks
Brad Bruce
|
|
|
|
|
Both But I use enums more and more. #defines polute the global namespace whereas enums are typically declared within a class. const int blah is another valid and more politically correct way of doing #def's.
Neville Franks, Author of ED for Windows. www.getsoft.com
Make money with our new Affilate program
|
|
|
|
|
Neville Franks wrote:
#defines polute the global namespace
Do they really ? I don't think so, they are replaced by the preprocessor, before the C++ compilation.
const int do pollute the namespace when they are defined outside classes scope.
Max.
|
|
|
|
|
Well, technically no. But effectively, yes, sort of.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Maximilien wrote:
Do they really ? I don't think so, they are replaced by the preprocessor, before the C++ compilation.
What I meant was if you have #define FRED 123 in one header and someone else has #define FRED 456 in another header you are in trouble.
Neville Franks, Author of ED for Windows. www.getsoft.com
Make money with our new Affilate program
|
|
|
|
|
yep! if it's your code, you need to fix it ...
you'll get a compilation warning :
c:\documents and settings\lincourt\my documents\testanotherthing\panel2.h(15) : warning C4005: 'TATA' : macro redefinition
c:\documents and settings\lincourt\my documents\testanotherthing\panel1.h(9) : see previous definition of 'TATA'
Max
|
|
|
|
|
Maximilien wrote:
yep! if it's your code, you need to fix it ...
This can be easier said than done. It gets even worse if you have third party code/libraries which happen to use the same #define name.
Very good reasons not to use #define's.
Neville Franks, Author of ED for Windows. www.getsoft.com
Make money with our new Affilate program
|
|
|
|
|
that's another place where namespace come in handy ...
Max.
|
|
|
|
|
Maximilien wrote:
that's another place where namespace come in handy ...
I didn't think namespace effected #define's. Even if it did, I can't change the namespace used by third party code.
Just admit it #define's are bad.
Neville Franks, Author of ED for Windows. www.getsoft.com
Make money with our new Affilate program
|
|
|
|
|
Even though I wouldn't ban #define from the language, I can think of no place where I would use them when I could use an "enum". Even in the case of bit mask enums, I would still use them instead of #define.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
In our current projects, we have relegated #define to handling conditional compilation only. We've not found any cases where we couldn't handle things better using const's, enum's, or templates.
Software Zen: delete this;
|
|
|
|
|
I prefer enum because, #define XXXXXX never be seen by compilers. Removed by the preprocessor before the source code ever gets to a compiler. So, XXXXXX not entered into compiler symbol table.
Ahmet Orkun GEDiK
Technical Consultant
ASTRON Project Office
|
|
|
|
|
using enums in class or in another namespace should removes all semantic conflict of a symbol. Enum should be used for symbolic values, where the numerical value has no importance.
Using const <some type=""> ( or #define ) is better when the value is important and significant.
enum eAttachment
{
ATTACH_LEFT,
ATTACH_RIGHT,
};
const int iNudgeFactor;
const float fPI = 3.14;
...
Max.
|
|
|
|
|
As has been said, const int should be used rather than #define. An enum is a good idea where a number of values are logically grouped together, const *type* should be used where a value is unique. A #define does not pollute any namespace, it does not exist, the preprocessor replaces it with the value. Macros are generally evil, although I once lost a job at least in part because I knew this. I would also wrap any constants I create into a namespace, so the global namespace is unpolluted.
Christian
No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002
Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002
|
|
|
|
|
Christian Graus wrote:
Macros are generally evil, although I once lost a job at least in part because I knew this.
You gotta elaborate on this!
|
|
|
|
|
It's kind of a long story. The short version is I did some distance work, and one of my cow-workers, whom the boss held in high esteem ( and rightly so, may I add ) decided to give me a programming pop quiz. Being aware of the reasons not to use macros, I really had never used them and so failed the test (which involved macros ). I believe this was a pivotal moment in that person involved deciding that he did not support me having the position, which I was struggling with due to lack of guidance/information until AFTER I delivered things, at which point I was told I was doing it wrong. So they sacked me. I am still in awe of the whole process, to be honest, but I made enough money to buy a video camera, so that was better than nothing.
Christian
No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002
Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002
|
|
|
|
|
Christian Graus wrote:
but I made enough money to buy a video camera, so that was better than nothing.
<Entering Nick's Weird Memory>Was this when you did some work for CodeJock?</Enter Nick's Weird Memory>
Nick Parker
Not everything that can be counted counts, and not everything that counts can be counted. - Albert Einstein
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
