|
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()
|
|
|
|
|
The line a:mymethod() would be ok IF you'd actually created an instance of class A named a which you've not shown so in the context we have it's not ok.
Using a call like A::mymethod() can only be done if mymethod is declared as a static member function, you need an instance of the class to call regular member functions.
Your ::mycall(private_data) won't work if you're expecting private_data from class A because, again, you'd need to have an instance of class A for the member private_data to exist. Now if mycall is a standalone function at global scope, you could call it as long as you have a variable named private_data defined in an accessible scope to the call.
I'd recommend you spend some time with a good introductory book to C++.
Once you agree to clans, tribes, governments...you've opted for socialism. The rest is just details.
|
|
|
|
|
Tim Craig wrote: I'd recommend you spend some time with a good introductory book to C++.
Seconded. I'm not against people asking noob questions - after all we've worked our ways up from there.
But what irritates me is the fact that people don't even want to learn the VERY FUNDAMENTALS of programming (I'm sure a book would clear things up enough for them to ask meaningful questions).
Workout progress:
Current arm size: 14.4in
Desired arm size: 18in
Next Target: 15.4in by Dec 2010
Current training method: HIT
|
|
|
|