|
How can I disable [X] button on right-top corner of the sub-window? What I mean here is a MDI application. I want to disable [X] button of childwindow. However I'm not sure whether the [X] button belongs to childwindow or not.
I like show my knowledge with others
|
|
|
|
|
Try using this code
UINT menuf = bEnable ? (MF_BYCOMMAND) : (MF_BYCOMMAND | MF_GRAYED | MF_DISABLED);
CMenu* pSM = GetSystemMenu(FALSE);
if(pSM)
{
pSM->EnableMenuItem(SC_CLOSE, menuf);
}
This will work
|
|
|
|
|
> CMenu* pSM = GetSystemMenu(FALSE);
Thank you for you reply. But I have a question, how can you confirm its ChildWindow's menu or something else?
I have try the following method, but it doesn't take effect:
CMDIChildWnd *pCMDIChildWnd = MDIGetActive();
CMenu *pMenu = pCMDIChildWnd->GetSystemMenu(FALSE);
pMenu->EnableMenuItem(ID_xxx, MF_BYCOMMAND | MF_GRAYED);
|
|
|
|
|
Use GetActiveView / GetParentFrame to get the address and use it along with GetSystemMenu.
|
|
|
|
|
I want to open a pipe to the usb port and write some data. Can someone point me in the right direction?
Thanks,
Jill
|
|
|
|
|
Hi,
i'd like to put some objects to a std::vector. These objects contain different data but are derived from one abstract base class. To keep them in one vector this vector is instantiated with a pointer to the baseclass and therefore the derived objects could be put in... This seems to be kinda problematic since the implicite cast to the baseclass obviously destroys some information?! Is there a conveniant workaround?
best regards
|
|
|
|
|
yahp wrote:
Is there a conveniant workaround?
Not really.
This is a general design issue which isn't generally a hassle to get around, but it depends on the size of the inheritance heirarchy. It's generally caused by the abstract base class not being truly representative of the contract that the subclasses should fulfill.
1. Change the abstract base class. Changes should allow any operations of the subclasses to be called through the base class. Although this is a hassle it promotes the best design and IMHO provides the best support for maintainability
2. Store pointers to the base class and the objects themselves in separate collections. This works well if the problem is fairly small - but it gets ugly because you need to keep many collections in sync (problematic for objects on the stack).
3. Use a type field. Supposedly an OO No-No - keep track of which type the object is inside a value within each object. You can then cast to the appropriate object. Probably not a good idea unless you know that this part of your design won't get much larger.
4. Use a dynamic_cast. Similar idea to 3, but the compiler keeps track of the information for you. If the dynamic_cast fails you get a null pointer back.
If you can keep you head when all about you
Are losing theirs and blaming it on you;
If you can dream - and not make dreams your master;
If you can think - and not make thoughts your aim;
Yours is the Earth and everything that's in it.
Rudyard Kipling
|
|
|
|
|
Hi,
of course can the baseclass not fulfill the contract to the subclasses, if it could what would be the use of inherited classes 
1) I don't see how this could work. The baseclass cannot know about the features of the children?! So how can it allow access to unknown members?
2) Huu. The whole inheritance-thing was just about to avoid such an situation.
3/4) Mmmh. I'm not sure what this "no-no" would be 
The problem I see is the fact, that when you drop an item of the inherited class in the vector of the baseclass there will be an implicite upcast which will eventually destroy any information about the objects. BTW there was no warning from the compiler while doing so...
Thanx for your help and please don't be upset: I simply do not understand how your ideas could work... (well I understand (2))
|
|
|
|
|
I should have explained more carefully and read your post a second time
Polymorphism isn't about extending a class so you can add extra fields in the subclasses, it's about refining the operations that the class can perform.
When you hold a pointer to an abstract base class you are throwing information away. The trick is to make sure that the base class defines all the operations that you could ever need to call on any of the subclasses, via the base class pointer. 'All the operations you could need to call' is very vague, thus what I implied in item 1 of my previous post - sometimes it's a matter of tweaking the base class if you can see operations missing.
The key concept here is that two subclasses of a common base class should be fully substitutable for one another - they fulfill a common 'contract', which is defined by the operations of the base class. There are lots of things you can do with inheritance, but this is the only thing which correctly models the inheritance IS-A relationship.
I Strongly recommend you do some research on the Liskov Substitution Principle which I've tried to explain (very briefly and not very well). For me this material was a real revalation - it shed light on almost 18 months of lectures.
The Liskov Substitution Principle
Don't just believe me about this though, the current C++ standards committee and many influential people working with them are using LSP as the starting point for all teaching. Herb Sutter, Scott Meyers, Andrei Alexandrescu, Bjarne Stroustrup just to name a few are all advocates of this principle.
If you can keep you head when all about you
Are losing theirs and blaming it on you;
If you can dream - and not make dreams your master;
If you can think - and not make thoughts your aim;
Yours is the Earth and everything that's in it.
Rudyard Kipling
|
|
|
|
|
Hi,
mmh, I see, but this LSP seems to me just *one* approach to inheritance or to speak with Bruce Eckel's tounge: "it is nice if your design works out that way". Allmost every classical example on inheritance will be a set of classes with derived subclasses that extend the interface of the baseclass and do not only override base-class functions. This is exactly what the c++ RTTI is about. Ok, in a sense this breaks the IS-A relationship to an IS-LIKE-A.
I will have a deeper look to this article and hopefully I will understand the whole truth I just don't understand why they did not enforce this rule in cpp if it is that important.
But for now I need to think of an easy and shortterm solution of my problem.
|
|
|
|
|
Can someone show me how to write a C++ dll that would connect and fetch data from an ODBC connection. I have an IVR application that calls this dll named, LibUserFct. This dll is customizable and I want to add to this dll three functions, DBConnect(DSN,UID,UPW),DBDisconnect(),DBfetch(SQLstring).
|
|
|
|
|
Can someone tell me the source code to draw x and y co-ordinates given on the console in the form of fuction, in VC++ using openGL(GLUT)?
i need it urgent.please
|
|
|
|
|
|
I use the attached snippet to retrieve List Box control dimensions from resource build dialog. Works as advertised, but I need to create ( in program, dynamically) another control in same dialog and overlay the List Box with bitmap.
How do I get the resource created List Box location in the dialog?
I tryied wndListBox.CalcWindowRect(&rect), but got same results - just the control rectangle dimensions.
...
wndListBox.SubclassDlgItem (IDC_LIST, GetPage (0));
wndListBox.GetClientRect(&rect);
...
Any suggestions are appreciated.
Thanks Vaclav
|
|
|
|
|
Try this:
wndListBox.GetWindowRect(rect);
dlg.ScreenToClient(rect);
|
|
|
|
|
Andrzej,
well, it did not work - the resulting coordinates are exactly same as when I just use .GetClientRec!
Maybe my problem is in the rendering the bitmap - which is what I am trying to put on the dialog using the following code:
CDC *pDC = this->GetDC();
CPictureHolder * picture = new CPictureHolder();
picture->CreateFromBitmap(IDB_HISTOGRAM);
picture->Render(pDC,&rect,&rect);
If I use .GetClientRect the bitmap ends up in the client area - upper left corner, with correct dimensions.
If I use .GetWindowRect ( as suggested, but without ScreenToClient operation)- it does not show up at all. But the dimensions are pretty close what the coordinates shoul be. Acually,I think the width and height should "match", but they do not!
And if I make the 3rd parameter using just Wnd::GetClientRect, the client area dimensions are as expected, but still no display of bitmap.
I just do not understand what is the 3rd parameter used for in this case, because the MSDN talks about OLE when it comes to this 3rd parameter.
I'll thry to "render" the bitmap using BitBlt - since I have the coordinates.
Thanks for your help.
Vaclav
|
|
|
|
|
Vaclav,
Could you post your source code?
|
|
|
|
|
If wndListBox is placed on CPropertyPage change the code like shown below:
wndListBox.GetWindowRect(&rect);
GetPage(0)->ScreenToClient(&rect);
Now rect keeps the position of wndListBox in CPropertyPage (page 0 of your CPropertySheet) client coordinates.
|
|
|
|
|
can someone please the name of any winamp or windows media player function and in what of their dll's are to play an mp3 file.
gabby
|
|
|
|
|
DirectX can do this really easily - you might want to consider researching that. Theres some DirectX C++ examples at msdn.com.
|
|
|
|
|
Hi All
I've just started with MFC and need some help.
My application is a SDI with a splitter. The controls side is derived from CFormView (called CControlsView) the other side is an output. In the controls part I added a tab control and when a tab is pressed I display the mattching dialog in the tab client area. The tab dialogs have contols on them too.
This is my problem: the controls on the tab dialogs are not getting any messages. Only the CControlsView and the tab control on it are getting OnLButtonDown. So in the CControlsView::PreTranslateMessage I check for a WM_LBUTTONDOWN and if it is found I use "SendMessage" to pass it to the dialog that coresponds to the tab selected. The dialog gets the message but the controls on the dialog don't get any messages.
Any Ideas why? I'd also be glad if someone could explain or refer me to some explenation on how this messageing works (who gets the messages and so on). Also am I going at this the right way at all? Should I use a PropertyPage for the dialogs? Couldn't find a way to use a PropertyPage as a view (the way I use the CFormView).
Thanks.
|
|
|
|
|
Check / search for "DemoTab" ( sorry, I can't remember where I got it).
It has CTabView class which works fine for me. Nothing fancy, but I like KISS concept.
There are articles on this board using tree control to select items in the associated pane if you want something fancy.
BTW I tried to do similar thing using splitter and found it to "convoluted" to pass messages between panes.
Right now I am strugling with putting controls into the "tabs" dynamically.
Vaclav
|
|
|
|
|
Thanks, actually I found a nice demo called "Property Sheet View" on this site (don't know how I managed to miss it all this time). Does exactly what I wanted
About the splitter, its going to have to be like that  . I need to see the output in one window while playing with the controls in the other.
|
|
|
|
|
Vaclav wrote:
Right now I am strugling with putting controls into the "tabs" dynamically.
Why would you need such a capability? In what context could one possibly use it? I am curious to know.
|
|
|
|
|
Vivic wrote:
Why would you need such a capability? In what context could one possibly use it? I am curious to know.
Currently I'm working on a terrain editor, but I'd think being able to see the results in one window while playing with controls in the other is common functionality. You can think of it as a standart menu, just spread out.
I wouldn't mind being corrected, since this is my first MFC program
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
