|
You can always get the underlying CToolbarCtrl and call its member functions.
|
|
|
|
|
Is there a way i can check the items without mixing classes?
-- Steve
|
|
|
|
|
Err..
Have you actually read the MSDN docs?
Get it, it's worth it, or go on the net to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcmfc98/html/_mfcnotes_tn031.asp
Anyway, you won't be mixing classes. Here's a quote from those documentations:
CToolBar::GetToolBarCtrl, a member function new to MFC 4.0, allows you to take advantage of the Windows common control's support for toolbar customization and additional functionality. CToolBar member functions give you most of the functionality of the Windows common controls; however, when you call GetToolBarCtrl, you can give your toolbars even more of the characteristics of Windows 95 toolbars. When you call GetToolBarCtrl, it will return a reference to a CToolBarCtrl object. See CToolBarCtrl for more information about designing toolbars using Windows common controls. For more general information about common controls, seeCommon Controls in the Windows 95 SDK Programmer’s Reference.
Hope that helps. Essentially, there's no harm, as CToolBar are made from (or using) the CToolBarCtrl.
I suggest you go to the docs... you'll learn a heck lot more.
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
|
|
|
|
|
The link is out of date. I found the page with Google by enter "TN031 Control Bars".
|
|
|
|
|
Hi,
I need to know how to create an SDI within a MFC DLL so that another MFC Application can open it. Has anyone ever done something like this?
Thanks,
Melanie
|
|
|
|
|
I recommend a dialog box. Here are some useful articles on MFC DLLs.
http://www.mindcracker.com/mindcracker/c_cafe/dll.asp
Kuphryn
|
|
|
|
|
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;
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
