|
You have to draw some graphics first.
|
|
|
|
|
Two questions:
Selecting “No scroll” ( vertical) removes the header – feature or bug?
Is there a way to show / hide just the Report? Right now both header and report are controlled by ShowWindow.
I did look at GetSelectedCount but the sub-items updates are controlled by CRecordset DoFieldExchange so I guess it would not work.
I do appreciate your time and any to the point comments, however, please refrain from any “update to X "suggestions. Not an option for retired hobbyist.
Cheers Vaclav
|
|
|
|
|
Is the header removed only when changing the scroll flag with the resource editor or always even when changing the flag by code? In the first case it seems to be a bug of VC 6. You can then handle it by using SetExtendedStyle() when initializing the list control.
To hide the list content but not the header you may resize the window to the height of the header (plus height of horizontal scrollbar if present).
|
|
|
|
|
My code is still in rough development stage and I do erase the entire record each time I am adding a new one - hence the scrol bar is always moving.
I will eventually do just add new record and that should clear things a little. I thing part of the "problem" is that the recorset is always sorted in descending order after each new add.(maybe I can add in front of recordset instead of in the end of it!)
This is no big deal in real application, I was just messing with how last I can update few views. And since I have three of them with CListCtrl the update redraws are very visible.
I'll try to adjust the report size exluding the header.
|
|
|
|
|
To avoid redrawing (flickering) while the list is changed, disable redraw using SetRedraw(0) and re-enable it after the changings has been applied.
|
|
|
|
|
Thanks Jochen,
SetRedraw solved the "problem". No more header redraw and the vertical slider stays put.
|
|
|
|
|
I'm trying to understand how the CMFCToolbar works when adding controls in it, in particular adding a CMFCToolBarComboBoxButton.
I can create the toobar and add the combo box button (in the handler of AFX_WM_RESETTOOLBAR) and add the message to handle it :
ON_COMMAND(ID_COMBOBOX, OnComboBox)
ON_CBN_SELENDOK(ID_COMBOBOX, OnComboBox)
In that case the messages are handled in the document class.
Now, I'd like to be able to handle the message in the toolbar class (to have less clutter in the document or main frame classes).
So, I create a new toolbar class derived from CMFCToolbar (still able to add the combobox and handle the message if in the document class)
Now, I'm not certain what message I need to handle, seems I tried everyone of them (I've read TN062 on msdn).
I tried enabling the reflection on the toolbar :
m_myToolbar.EnableReflections(TRUE);
documentation for the above says : "Call this method to enable command reflection for toolbar buttons that contain embedded controls, such as combo boxes."
I've also tried to use the method CMFCToolbar::SetRouteCommandsViaFrame, but it does not seems to do anything interesting.
googling and binging does not return useful hits.
Anyone able to use that as expected ? or am I completely clueless and I'm not reading/understanding the documentation ?
Thanks
Max.
Watched code never compiles.
|
|
|
|
|
Hi Max !
Please set a break-point into the
BOOL CMFCToolBarComboBoxButton::NotifyCommand(int iNotifyCode),
at its case of CBN_SELENDOK
and then observe the stack: the author of the notification is
BOOL CMFCToolBar::OnCommand(WPARAM wParam, LPARAM lParam)
and is virtual, so you could extend it at your derived level 
They sought it with thimbles, they sought it with care;
They pursued it with forks and hope;
They threatened its life with a railway-share;
They charmed it with smiles and soap.
|
|
|
|
|
Dear friends,
Why there is no virtual constructor in C++? Can anybody explain me....
Thanks and Regard,
S.Shanmugaraja
|
|
|
|
|
1) In C++ Virtual functions are resolved by V_PTR (virtual pointer) at run time.
2) V_PTR points to its V_TABLE.
3) When an object is created, V_PTR is initialized in constructor.
so if someone tries to define constructor as virtual, where and when V_PTR will be initialized?
|
|
|
|
|
Correct for C++, but I prefer the response of jschell as this is in fact an OO-conundrum rather than being specific to C++.
|
|
|
|
|
The fact that a constructor looks like a method doesn't make it one.
A Object in terms of Object Oriented Programming can have polymorphic behavior.
But an Object does not exist until it has been successfully created. Thus it follows there can be no polymorphic behavior until after creation (constructor) succeeds.
None of the common OO languages allow it. Additionally as per the other response on the technical issues there is also the concept that a parent class should be 'created' before a child. And with normal virtual semantics that would not be possible. With the current semantics it is.
|
|
|
|
|
jschell wrote: But an Object does not exist until it has been successfully created. Thus it follows there can be no polymorphic behavior until after creation (constructor) succeeds.
^ this! You nailed it.
|
|
|
|
|
what would/could such a thing accomplish?
|
|
|
|
|
See here.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
DavidCrow wrote: See here.
I don't think I believe that. It says
"In particular, "virtual" allows us to call a function knowing only an interfaces and not the exact type"
And that seems to suffer from the same problem of equating a constructor to a method.
With a virtual method I can do the following
MyBase* p = ...
p->myVirtualMethod()
But it isn't possible to semantically create statements that are similar to that using a constructor. So the type would still be known.
|
|
|
|
|
Consider the opposite, that it was possible.
Subclassing, can sometimes be viewed as specialization.
Dog is a specializations of an Animal.
If the Animal has private variables, these are initialized in the constructor.
If the constructor is virtual, it is replaced by a subclass' constructor.
According to the principles of data hiding (public, protected, private), a sub class cannot access private member variables of a parent type. So these member variables would be left uninitialized. You don't want that because the parent class would break.
If you by some reason need a virtual constructor there is a Design Pattern called the Template Method,
http://en.wikipedia.org/wiki/Template_method_pattern
In the example they have they define an algorithm in the parent class,
and let the subclass define the implementation.
It is of course possible to apply the same principle in constructors by creating a virtual method called "Initialize" which you call from the constructor. When this method is redefined in a subclass it will override the parent's definition.
But I have never came across the need for a virtual constructor. Why do you need one?
|
|
|
|
|
You started on a good idea, i. e. posing the question 'what if?'. You raised the wrong question though, since initialization is not really a problem: C++ implicitly calls the constructors of its parent classes!
Instead you should have asked this:
What if ...
1. I had a class called Animal
2. two subclasses called cat and mouse
3. a virtual constructor for Animal.
--> what would that constructor create?
There is no answer to this question: in order to decide what subclass to create, you'd need to decide what type the object is of. But to decide the type, you'd need to create the object first! It is a typical hen-and-egg problem. It cannot be solved. Therefore there is no sense in a virtual constructor.
There is a mechanism for methods that do not require an actual instance of an object: static. But you cannot override a static method, exactly because it is not tied to an instance, and therefore there is no way to resolve a virtual call!
|
|
|
|
|
Yes the default behavior is that all constructors execute,
the subclass and all its parents constructors, so initialization isn't a problem.
Overriding is generally done by declaring methods virtual.
I thought he meant how to "override" the constructor,
but that doesn't make much sense.
That was my point I was trying to get to.
You were asking on the other hand asking:
What would a virtual constructor create?
But what is actually common is to have virtual methods
that create subclass objects.
This is how the factory pattern works.
The parent class provides a CreateInstance Method.
specialized factory implementations(subclasses), create related objects of the same family.
An SqlServerConnection object provides a CreateCommand method that returns a SqlServerCommand, whereas the OracleConnection object's CreateCommand would return an OracleCommand. The Create methods are not class constructors, but they are constructing objects. It is probably not safe to call virtual methods from a constructor, because the parent constructors execute before the constructors of the subclasses have finished.
|
|
|
|
|
Mattias Högström wrote: You were asking on the other hand asking:
What would a virtual constructor create?
But what is actually common is to have virtual methods that create subclass objects.
That is not a valid answer to my question. There is in fact no valid answer. And that is the point of the question!
Of course using factories or similar is a reasonable solution in such a situation - but that was not my question, nor the OPs'.
|
|
|
|
|
I didn't try to answer your question
The original question was "why no virtual constructor" (I suppose he is asking because there are virtual destructors)
You are confusing me.... talking about valid answers.
There is probably a reason why there is no virtual constructor in C++
If the language designer would have wanted one, it could have been added regardless if it was useful or not.
|
|
|
|
|
What came first, the chicken or the pure virtual CAnimal?
|
|
|
|
|
Mattias Högström wrote: It is of course possible to apply the same principle in constructors by creating a virtual method called "Initialize" which you call from the constructor. When this method is redefined in a subclass it will override the parent's definition.
I don't think so.
http://www2.research.att.com/~bs/bs_faq2.html#vcall[^]
And even if it is now possible (or possible in other OO languages) it is something that should be used with a great deal of care. The reason for that is that because it is virtual then intent would be that it interacts both with the parent and child. And not understanding exactly how the parent and child are designed to work and not understanding in detail how the child parent are implemented can lead to problems. Especially when one considers maintenance.
And often when people want to do this it is because they do not understand the above or even understand what constructors are. So probably best to just say - don't do it.
|
|
|
|
|
you're right. I remember reading that before. It is unsafe or undefined to call a virtual method from the constructor. I was mearly trying to show the usage of virtual methods that can create objects by delegating the exact type to a subclass to define it. This is how some factories are implemented. But I should have stopped there. I went too far. Calling them from constructors are of course not possible due to how parents an children are created. I have never found any need for a virtual constructor, but virtual methods that create objects often.
|
|
|
|
|
Mattias Högström wrote: It is unsafe or undefined to call a virtual method from the constructor.
It is defined behavior.
Mattias Högström wrote: Calling them from constructors are of course not possible due to how parents an children are created
Not sure what that means. It not possible because the language definition doesn't allow it. Perhaps your reason is a restatement of why that rule exists.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
