|
Working on an MDI program. There is a toolbar ,in which there is an CMFCToolBarComboBoxButton item, in one of the views. User need to open multiple views of the same type. The question is the combox item will change together when user changed it in one view, even through the combox is in different views.
What's wrong? Is it designed by Microsoft?  
|
|
|
|
|
Since the button will have the same ID in all views, and you probably have hooked up event handlers for it, they will behave as one. It's the same code running for all, and also, you have the same document.
To avoid this, you could change the control ID for each new view created. Takes a bit of house keeping to keep within allowed ranges and maybe managing reuse of ID's.
Are you really sure you have to display the same view more than once? It also sounds as instead of opening a new view, you should create a new document with the same view type.
|
|
|
|
|
Thanks for your reply.
Yes. It is same views of same document. In the program, I really need multiple views of same type in one document. Simply, the program is a Single Docment Multiple Views one. More than one view of same type are displayed to view different data from data controller with SQL query support.
But I find if I use normal CCombox control other than CMFCToolBarComboBoxButton, it works well. I guess it may be a question with CMFCToolBarComboBoxButton.
Any more inputs?
|
|
|
|
|
In case of the classic CComboBox implementation, the toolbar does not deal with the control at all. It just reserves some space and paints it in-place. You explicitly manipulate the control when some event is triggered in you program.
With the new MFC classes, this is done for you. I think the reason is the customization possibilities, where in theory you can put the same button/control more than once in a toolbar.
|
|
|
|
|
ooh...okey. Now it seems a problem for me.  Originally, I think the view instance is not the same one in spite of same type of view. So the CMFCToolBarComboBoxButton control object is also created onece for each view. Only the ID is the same. The click/change message for the control may be routed to different target view. I think only the control box which is clicked actually should changed.
Whatever, any way to make it happen? I really donot want to use CComboBox control to implement. it is not a easy way to do. In that case, you need to control the the box by yourself completely, including its possition and behave.
|
|
|
|
|
Hello,
Does anyone know how to register a dll or ocx file using c++ code (in particular I'm using vc++ 2008 standard)? I need it to work for Vista and Windows 7.
Thanks!
|
|
|
|
|
It's a three step process:
- LoadLibrary to get the DLL into memory
- GetProcAddress to get the address of the function DllRegisterServer
- Call DllRegisterServer through the pointer from GetProcAddress.
Or you can just link with the DLL normally and call DllRegisterServer by name.
Cheers,
Ash
|
|
|
|
|
Thanks Ash,
Will this work on Vista and Windows 7 with them having the extra security features?
|
|
|
|
|
I think so, I've done it successfully on both of them. There might have to be some fancy footwork on Vista but if there is my mind's a blank.
Oh, I was using it from a setup program which was running elevated under Vista and Windows 7 - which might be a problem.
Cheers,
Ash
|
|
|
|
|
Registering a DLL/OCX involves modifying the registry which means elevated privileges.
You can either always remember to run the registering application as administrator (Right click -> Run as administrator).
Or you can instruct the application to always run elevated - Project -> Properties -> Configuration Properties -> Linker -> Manifest File -> UAC Execution Level -> requireAdministrator.
|
|
|
|
|
You should initialise COM too, as the code here[^] shows.
Steve
|
|
|
|
|
You're partly right as the original poster mentioned ocxs, mea culpa!
However you don't have to initialise COM to load up a DLL and call an exported function on it. You can (conceptually) easily register most COM DLLs by writing to the registry directly - if you know all the details of the objects you're registering (GUIDs of the CoClasses and IIDs of the CoInterfaces). Have a look in "Essential COM" by Don Box for a script based DllRegisterServer that doesn't require COM to be initialised.
ActiveX controls may be an exception but they're out of my experience. If that's the case, as they implement OLE interfaces, you need OleInitialise() before registering and NOT CoInitialize().
Cheers,
Ash
|
|
|
|
|
I've read "Essential COM". In the case of the script bases registration code (I can't remember it explicitly) the script runtime almost certainly initialises COM (so it's already done). I understand that LoadLibrary and friends don't require COM, but that's hardly the point. The point is the runtime environment the registration code is allowed to assume.
Steve
|
|
|
|
|
Your memory's a bit faulty on that one, the code in the book doesn't initialise COM or assume that it's loaded by a process that's already initialised it.
|
|
|
|
|
See DLLRegisterServer()[^]
Workout progress:
Current arm size: 14.4in
Desired arm size: 18in
Next Target: 15.4in by Dec 2010
Current training method: HIT
|
|
|
|
|
Alternatively, can the .ocx file be embedded into the binary??
|
|
|
|
|
OCX can be embedded in a binary, but this is not an alternate solution.
To use the OCX you will have to extract it from the binary and register it.
|
|
|
|
|
|
ocx control can register with "regsvr32".
ther is 3 possiable solution
1. you can put command in command prompt
regsrvr32 OcxFilePath
or
2. Make batch file and open with c code. batch file contain data
regsrvr32 OcxFilePath
or
3. open a process with c code with command line argument
regsrvr32 OcxFilePath
|
|
|
|
|
Hi,
Many times I have seen :: followed by Windows API without a class name on the left does that mean that the API doesn't exist
e.g. Neither CWnd nor CDialog hass the following SDK memeber CreateToolbarEx
would I code ::CreateToolbarEx without HWND members if runs out CDialog derived method
|
|
|
|
|
If you see something like:
::DoSomethingGroovy( h, DSG_HELLO );
then that means that the programmer wants the compiler to use the function with the name DoSomethingGroovy from the global namespace. So if call is made in the member function of a class which also declares DoSomethingGroovy
class CGroovyThing
{
public:
void bleugh()
{
::DoSomethingGroovy( h_, cmd_ );
}
private:
void DoSomethingGroovy( HANDLE h, command cmd );
};
then the call will not use the class's version of the function.
Cheers,
Ash
Edited for a bit more clarity (I hope!)
|
|
|
|
|
It means the function is in the global anonymous namespace, i.e. not part of any namespace nor class.
|
|
|
|
|
Can it reference any of the members out of the method is running from
e.g.
Class A
{
public:
void mymethod();
private:
int private_data;
}
a::mymethod()
{
::mycall(private_data); // is this okay
|
|
|
|
|
ForNow wrote: Class A
{
public:
void mymethod();
private:
int private_data;
}
a::mymethod()
{
::mycall(private_data); // is this okay
Sorry, but that piece of code makes absolutely no sense.
Workout progress:
Current arm size: 14.4in
Desired arm size: 18in
Next Target: 15.4in by Dec 2010
Current training method: HIT
|
|
|
|
|
Is it because I have a small "a".
A::mymethod()
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
